Stardog
Designing a visual GUI for a data unification software
Stardog is a company based in Virginia that uses a technology called ‘knowledge graphs’ (KG) to enable enterprises like NASA, Dow Jones, Capital One, Morgan Stanley etc. to unify and transform their data into ‘knowledge’ that can be used to find answers to complex business and technical questions.
​
As part of the iConsultancy at the University of Maryland, I led a team of 6 designers, researchers and developers to design a code-free visual workspace for their flagship product - Stardog Studio - for its less technically proficient users.
-25%
Time Needed to Build KG
Product Roadmap
Influenced with Research
+1000
New Users
My Responsibilities
• Collaborated with stakeholders and customers, and led the concept validation and user research.
• Worked on interaction and visual design, and drove ideas from concepts to high-fi and interactive visual GUI features.
• Developed an end-to-end high-fi prototype.
Timeline
Aug ’19 - May ’20
9 months
Teammates
Modassir, Aravind JR, Jashan Gupta, Monikka R, Natalie TY, Yirang Choe
Tools
Adobe XD, Figma, Google Suite, Miro board, Notion, Zoom
Knowledge Graph
A knowledge graph (KG) is a flexible graphical representation of data derived from a variety of sources that are connected together to create machine-understandable knowledge.
Enterprise data in large companies is stored in silos and fails to provide the insights required to make better decisions. KGs allow users to build flexible models and connect data from different silos.
The process of creating and using KGs (detailed workflow) requires a number of large, complex steps which are simplified and illustrated below -
Problem
The current process of creating KGs requires expertise in multiple coding languages, and is difficult to collaborate on.
We realized the need for a simpler alternative from customer feedback after hitting an inflection point in sales. We conducted user research to dig deeper into these pain points and explore possible directions, finally settling on creating an interactive visual GUI for the data mapping and modeling phases of the KG creation process.
Users
Lead ontologists, data architects etc. with 5+ years of experience in the KG domain.
Needs ability to code & has many advanced use cases.
Junior data architects, software engrs. etc. with <5 years of experience with KGs.
They need to be able to create and modify data models & mappings easily.
Domain experts, business analysts, managers etc. with some or no understanding of KGs.
Wants to query & find answers to business questions.
Scope
User Research
Domain Training + Tool & Competitor Analysis
Screener Survey
Semi-structured Interviews, A/B Tests
8 High techies,
3 Low techies
Contextual Inquiry
5 Participants
Key Insights & Design Implications
01. Modeling and mapping are very closely tied
When users work on mapping, they need to edit/add new nodes or properties as needs arise. So we treated each project as a virtual graph where users can create data models and do the mapping on the same canvas.
02. A subset of data is selected before mapping
Users select some data columns to work with when they start mapping the data to the model. So we created a data-field selection user flow.
03. High-techies prefer coding
High-techies prefer coding because they are more comfortable with writing code than using a visual interface. So we decided to provide the flexibility to switch between synced visual and code modes.
04. Properties of nodes are defined separately
Users may define properties and classes separately and later assign the properties to the classes and map them. So we created a new place for defining properties separately.
05. "Auto-mapping" is a common starting point
The majority of current users use "auto-mapping" as a starting point. So we highlighted that path when users create a new virtual graph project.
06. Users like both mapping by clicking into nodes and dragging data items to the nodes
In A/B tests, users found both 'click to map' and 'drag and drop' mapping functionalities to be useful in different contexts. So we supported both the interaction-flows.
Affinity map containing detailed findings. Explore Affinity Map on Miro
Current Stardog Studio Interface
Current Stardog Customer Workflow
Final Solution
Getting Started with a Project
To get started, current users of the platform preferred to use the ‘auto-mapping’ feature that auto-builds a model based on user selected data-columns, which can then be modified and shaved off as required. So we designed it to be the ‘primary button’ on the screen with the flexibility to create a model from scratch or open an existing model or select a source first instead.
Data Mapping and Modeling
I contributed largely towards designing the core data modeling and mapping interactions. I was involved in thinking through a number of use cases for creating and modifying entities like classes, relationships and properties and selecting relevant data-columns from a source and then mapping it to them. We envisioned a close-sync between code and visual modes to provide a scalable and flexible design, especially for high-techies.
My Responsibilities
I owned the design for 4 features and led user research and prototyping
​
From conceptualizing workflows, wireframing different concepts, testing, and iterating to designing the high-fis. I also assisted my team by establishing a relevant design system using Blueprint.js, helped with project management, design documentation, and hand-off using Zeplin, and prototyped the critical mapping and modeling of user flows.
Modified Style Guide using Blueprint.js Design System by Palantir
Feedback & iterations
Getting Started with a New Project
Before: The information on the card was not sufficient because users may recognize model or data source used instead of project name.
After: The iteration was easier & faster to scan & provided additional useful info like data sources & models used.
Before: Users were required to name their project when they create a new one.
After: Users will be taken to an empty canvas with options on how to get started with a project named "Untitled".
Before: The data selection view was too small for users to view all the data that they need to select from.
After: ER diagram is shown as it is conventional for users to view when they decide which parts of the database to work with
Reduce the efforts of the data selection and mapping process
Before: Users were required to select the data they want by dragging data columns from the bottom of the screen that showed all the data, then drag and drop selected columns from the left panel to the main canvas to map it to the data model - which had a high interaction cost.
After: We moved the data panel to the left side to reduce the simplify the interaction flow, and added tabs to differentiate 'all' from 'selected' data-columns
Before
1. The select checkbox showed only when users hovered over, which was not prominent
2. Users could not figure out they could drag & drop the data columns onto the model to map them
After
1. We changed the "selected" tab to the "pinned tab". Users could toggle the selection/pin mode off but it was 'on' by default
2. We added the "6 dots" indicator to indicate the data columns were draggable
3. We also added a tutorial gif on initial hover to the data columns to inform users of the drag & drop action
A flexible way to add properties and support different use cases.
Before
1. Users can only add properties in each class/relationship by using the "property popover" which was launched on clicking the model entity which users failed to recognize. This also did not fit the current users' mental models
2. Important information such as 'datatype' of thee property was missing
After
1. We added a "property drawer" that enables users to define all the properties first and assign them to different classes at their own will
2. The improved "property pop-over" showed important info. such as datatype & description
After
"Add property" launched a modal that allows users to add multiple info here, such as assign class, select mapping field & edit descriptions & it was also accessible from the property drawer
Evaluation
A/B Testing
8 Participants, guerrilla recruitment for concept testing
User Testing
5 Participants, Likert questionnaire
1. List of features to explore next: Class hierarchies, Data manipulation & filtering, Versioning, Expanding for different data source types, Multiple relational data source
2. Use of color in the class-nodes did not adequately reflect user’s mental models of mapping
3. Relationship mapping needs additional constraints
User Test Notes
User Testing Session on Zoom
User Feedback
Reflection
It was challenging to work on a desktop software, in the complex domain of knowledge graphs that I encountered in this project for the very first time.
I got the chance to briefly manage a team in this role and was involved hands-on with the entire UX cycle to churn out viable designs for a major product decision taken by the company.
I also used some new, awesome collaborative tools like Notion, Miro, Zeplin and Zoom that greatly improved collaboration and the efficiency of the team.