Before

After

Use the slider to see the before and after versions of the product

Knowledge graph simplified

To simply put, a knowledge graph is a graphical representation of all the databases connected together (which was previously segregated) to transform information into useful knowledge to make an informed decision. Knowledge graph uses machine learning and semantic networks to gather and interlink information from a variety of sources.

Primary audience

Low Techies (Junior Data Architects, SMEs and Business Analysts)

Little to no experience in KG domain

Existing audience

High Techies (Ontologies, Data Architects)

5+ years of experience in the KG domain

Contextual Design Process

Research Phase - Fall 2019

Contextual Inquiry

Journey Map

Workflow Model

Affinity Map

Interview guides

We were aware that we cannot have one size fits all interview guide when it comes to interviewing various user groups. Hence we created seperate interview guides. Our interview guide focused on understanding the following

• Technical competencies
• Tools used in their workflow
• Relationship between various teams in the company
• Workflow process
• Limitations, painpoints while using Stardog studio
• Opportunities for GUI interfaces
• Opportunities for better UX
• Communicating findings to stakeholders

Affinity diagram

Our team gathered more than 500 data points from the contextual interviews. Assimilating the massive data points gathered by the research process is a very complex process. We externalized our raw research data onto sticky notes to create affinity diagrams. Affinity diagrams helped us to see the bigger themes and patterns in user needs and behaviour. 

Journey Maps

Based on the interviews, we captured our user's workflow models, various tools used along every stage of the Knowledge Graph process. To illustrate the process, the various players involved and their paint points, we created a Jouney map and shared with the stakeholders for validation and feedback.

Research findings

1. Modeling is highly collaborative (and requires communication over different platforms) whereas mapping is mostly done by one expert. 
2. Modeling and mapping are very closely tied. When users work on mapping, usually they need to edit/ add new nodes or properties as needs arise.
3. Users want to select smaller datasets before mapping. They select a few fields that they need to work on before mapping. 
4. High-techies prefer coding. They are more comfortable with writing codes rather than using a graphical interface.
5. Auto-mapping is the default starting point for techies. The system auto-generates the data model and mapping for them which is editable.

Design Phase - Spring 2020

Co-design Sessions

Storyboarding

Whiteboarding

User Environment Design

Low-fidelity Designs

Usability testing

Design Language

High-fidelity Designs

Co-design session

Designing a new interface to capture newer audiences and to cater to their needs requires us to understand the mental models. Co-design sessions helped us to understand how various frameworks would help the users to be more productive and efficient. 

We invited 5 participants to sketch out an interface that would help their workflow easier and much more productive. We prompted them with various use cases and tasks to elicit more design ideas and validate some research hypotheses.

Sketching and whiteboarding

Storyboarding helped us envision our user's various workflows as each company used Stardog for different purposes. However, we were able to capture the common workflow and simplified it using a storyboard. 

We also sketched out various workflows based on our co-design and contextual inquiries to better inform our design rationale. This helped us design the nuances in the user's mental models of mapping and modeling process.

Based on the UED, we were able to build a task flow to create and map a data model.

Onboarding

Before starting a new project, there are a lot of data configurations that have to be done like connecting it with Database, selecting various sources, selecting a model to work with, and sometimes, to select a smaller set of data fields. 

Version 1

We realized that it was prudent to have these questions upfront so that our users can quickly configure these settings.

Version 2

Some of our users mentioned that they wanted more information about the databases they import into Stardog. The database type and the last accessed were important to our users. Hence we included those information in a form of a list.

Version 3 - Selected

On probing deep into the mental models of the users, we uncovered that, in order to start modeling, the users did not have to connect to any data source. Thus, the process of configuration of data sources was unnecessary. Hence we directly let the user to the canvas to start modeling their KG.

Data modeling

Building a data model is an important step that lays the foundation of a knowledge graph. A data model consists of "Nodes" which may have many "Properties". Each node is linked with one or many nodes by "Relationships" After several iterations of data modeling approaches based on user and stakeholders feedback, settled with an intuitive WYSIWYG approach. We settled with our final approach based on the design inspirations where we drew parallels from similar and dissimilar domains. 

We wanted to cover all the basic operations (add a new node, properties, and relationships) in modeling while coding and also provide the flexibility (copy, paste, and delete) that could help users be more effective. 

Allowing users a way-in to edit and change the data modeling saves a lot of time. For example, flipping the direction of a relationship using a simple toggle button would have a lot of time since it mimics the user's intuition. Alternatively, having dragging and dropping the anchor points of a relationship to different nodes would help the user to link different nodes.

There are two ways to rename a node or a relationship.

1. Double click the node name.
2. Right-click on a node to trigger the context-aware menu and click on rename.
   

On hovering over a node, two icons appear - creating a new node and creating a relationship. These are the most frequently performed operation. Having them on hover helps the users to quickly create and build a data model.

Data mappping - Click to Map vs Drag and Drop

Before starting a new project, there are a lot of data configurations that have to be done like connecting it with Database, selecting various sources, selecting a model to work with, and sometimes, to select a smaller set of data fields. 

Instead of coding the relationship between a "node" and a "data field", we wanted to mimic the natural human gesture of dragging and dropping. We did consider the implication of drag and drop action in a crowded knowledge graph.

An alternate to drag and drop is the click-to-map approach. This will definitely come handy while mapping nodes in a highly-populated knowledge graph.

We did A/B testing to understand which approach was easier and intuitive for the users during the mapping process. During the testing we found out all our participant's first touch interaction was to drag and drop. Some of the participants did anticipate that the drag and drop approach would be cumbersome while interacting with a highly populated knowledge graph. Participants preferred to have both and saw use cases where both approaches can work in tandem.   

USABILITY TESTING

As mentioned earlier, we constantly tested and validated our design assumptions with real users. We performed 4 rounds of UT with 11 participants.  We documented each and every feedback we got from our participants categorizing the "Focus Area" where there can be an improvement. We documented the data in an excel sheet along with the design decision we took.

Design Framework

Based on our User Environment Design (UED), we created a framework for our design which consists of 5 sections.

• The Navigation Panel
• The Data Drawer
• The Property Panel
• The Toolbar
• The Workspace Canvas

1. Navigation Panel

Over time, our navigation panel evolved from mimicking the existing design to rethinking how projects live in Stardog Studio. Below is the evolution from low-fi to hi-fidelity design

We wanted the users to easily switch between various stages in creating a knowledge graph. This way, the flow is in line with the users' mental models. 

2. Data Drawer

All the data required to perform data mapping from various data sources is populated here. Here, the users can sort, filter, and search data fields.

Needs

1. Users often spent time trying to identify mapped and unmapped data fields.
2. Users, usually, select a subset of data to start mapping. Once they complete the mapping the small dataset, they validate it by running quick queries. 
3. Often times, the name of the data field would not necessarily convey the context of the data. Users felt that sample data of the field could be useful.

Solution

1. Having a "Mapped" tab to filter all the mapped fields helps users keep track of all the mapped fields.
2. Using colors and icons also aid users visually to identify if the data field is mapped to a Node, or a relationship or a property. This was very useful to help users skim through the list of unmapped data fields.
3. Each data field will have the datatype listed next to it. Instead of having the sample data, we decided to stick with the datatype since it gives a better context of the data field.
4. Having a "Pinned" tab helps users to select a small subset of the data and work on mapping instead of getting distracted by huge unrelated data fields.

3. Property Panel

Properties are nothing but attributes of a node. The property panel lists all the properties that were created by the user.

Needs

1. From our research, we found out that users, oftentimes create various properties, before mapping them to a node. 
2. An easy way to distinguish between assigned and unassigned properties.
3. A property can be mapped to multiple nodes. Naturally, our users wanted to know which properties are mapped to multiple nodes and the names of the nodes mapped.

Solution

1. Having an "Unassigned" tab to filter all the unassigned properties helps users keep track of all the unassigned properties. This also helps users to quickly get started to assign properties.
2. Property icons that are red in color indicate that the property is either not mapped to a data filed or not assigned to any nodes. This helps the user to easily distinguish between assigned and unassigned properties.
3. Each data field will have the datatype listed next to it. This helps the data mapping process easier as the user can match the data type of the fields in the data drawer.
   

4. Toolbar

A toolbar harbors all the most frequently used functions that we identified in the user environment design. The objective of a toolbar is to have quick and easy access to functionalities related to data modeling and mapping to help users be more efficient and productive. 

The toolbar lets users switch between the visual and code mode. This is to accommodate advanced users who prefer coding but use visual mode as a form of validation.

5. Workspace Canvas

The workspace canvas is the main focus area where the users could build data models and map data fields to those models. All the other sections above work in unison with the canvas. 

The nodes are color-coded to indicate to the users if the nodes are not mapped at all (Gray), partially mapped (Orange), and completely mapped (Green). 

On clicking on a node, the user can trigger a pop-up box that lets the users edit the node, map data fields to the node and properties, add properties etc. 

On right-clicking a node, a user can trigger a context menu where the user can perform vital data modeling functions like adding a Class, Relationships, and Properties. Likewise, the user can also use keyboard shortcuts like

[⌘ + C] -> Add a new Class

[⌘ + R] -> Establish new Relationship

[⌘ + P] -> Add a new Property  

Do you think I can thrive in your complex problem space? Let's talk!

Apart from work, I am fiddling around with Google Assistant actions to create a Bot that helps me be more productive. Ask me about that when we talk.

Email: hello@aravindjr.com
LinkedIn: Aravind Jembu Rajkumar

© Aravind 2021
Designer | Researcher | Product?