2016 - 2018
About
Advanced data orchestration functionality needed to be migrated from a command line prototype and unified with our GUI-based product ecosystem. However, the original architecture was designed for a highly technical user while our new market demanded a tool that would fit less technical users. Data objects had to be audited and re-calibrated to bridge operations between roles involved in interacting with different parts of the same data infrastructure.
Data Management
Data Management
Data Science
Data Science
Start-Up
Start-Up
World Assemblies
World Assemblies
Data Management Platform
Workflows is a net-new data orchestration solution to be introduced into our platform. It stitches and scales existing capabilities across our technical suite, including integrations that would repeatedly push / pull data to query for marketing segmentation, analytics, and syndication.
Platform Components
Workflows is an engine that allows our clients to orchestrate real-time data pipelines to modularize and digitize their domain operations for repeatability, scalability, and collaboration.
Users Matrix
The entire data operations team would rely on Workflows and therefore objects need to be designed with a suite of users in mind. These users had varying levels of data savviness a defined through their native tools.
Data Management Platform
Data Management Platform
Global & Local System Audit
Our open source prototype was audited at both a global and local scale to understand what problems needed to be solved in order for our business priorities to be enabled.
Global Scale: Power & Simplicity Trade-Offs
Working in B2B SaaS, our enterprise clients had complex configuration needs as defined by IT. Our product is able to flex with these needs with custom configurations, but the consequences of such power is increasing complexity in sane information management, a proliferation of edge cases, and the challenge of needing to work at a higher level of abstraction from the underlying raw data sources which incurs cognitive costs and can be unpredictable.
Requirements 1
Given the complexity allowed by workflows, maintenance can become challenging, especially as employees turnover and take their knowledge with them. The system needed to maintain its flexibility for us to meet our enterprise business goals, but we also needed to provide an experience to help users reduce the number of edge cases by helping users understand the orchestration system they were designing so that they could get ahead of and manage existing and introduced complexity.
Requirements 2
Information needs to be architected for navigation that would passively onboard users into the system and help them understand its components.
Requirements 3
Information needs to be chunked to give users relevant context at the point in which they are executing on a task.
Local Scale: System & User Trade-Offs
A quick information architecture audit gives a view of problem at the local scale of the user. While great attention was paid to the system architecture to ensure the robustness and performance of our client's data operations, little attention was given to how a user would navigate it.
User Interviews Insights
A series of user interviews were performed with beta testers to capture feedback on the prototype.
User feedback indicated that data analysts frequently misunderstood the concept of a ‘$session’ -- a far more dangerous
problem than simply not understanding what a concept is.
User feedback indicated that data analysts frequently misunderstood the concept of a ‘$session’ -- a far more dangerous
problem than simply not understanding what a concept is.
1
$session already has a meaning outside the product.
Users had pre-defined ideas of a workflow $session as being like a $userSession and/or $browserSession which, while similar, is still significantly different in purpose.
2
$session is incompletely understood within the product.
When a new $session is created, users relates $session to processing logic (workflow), but not to data being processed ($sessionTime). Concept of $session includes both because a $sessionTime parameter determines the $session’s individuality.
3
The purpose of a $session is especially unclear with less technical users who do not understand how to operationalize data.
$session’s usefulness is indeterminable until contextualized in error handling because it was designed to prevent data duplications and data drops. However, users need to define the $session in order to run the workflow.
Requirements 4
Users need to understand the purpose of a session when creating a workflow.
Global & Local System Audit
Global & Local System Audit
Session Object Re-Architecture
Session Object Re-Architecture
Even if information architecture was resolved and complexity was visualized for greater intuition, there was a root problem with the ecosystem of terminologies themselves.
To ensure workflows made sense to users, the temporally dependent objects were structured and defined in relation to each other. Each component was assigned a purpose bounded for explainability to users and in documentation.
To ensure workflows made sense to users, the temporally dependent objects were structured and defined in relation to each other. Each component was assigned a purpose bounded for explainability to users and in documentation.
Object Ecosystem Changes
The $sessionTime parameter was explicitly separated from $session object as a part of the re-architecture.
Session Object Re-Architecture
Workflow Object Lifecycle Analysis
Workflow Object Lifecycle Analysis
Once the system components were re-factored for learnability, a task analysis was performed on the workflow object to identify user and product gaps.
Gap Analysis for Tasks
Questions were identified for each user task associated with a
$workflow.
Workflow Object Lifecycle Analysis
Requirements 5
The design of information architecture needs to be structured around monitoring because it was the stage in which failures can occur once a
$workflow is in production. Enabling users to resolve issues quickly is synonymous with good navigation.Generated Questions
• What do users what to confirm?
• What do they want to be notified of?
• Are there spectrums of severity?
• What are the action steps to resolve a problem?
• Who does it and why?
• What do they want to be notified of?
• Are there spectrums of severity?
• What are the action steps to resolve a problem?
• Who does it and why?
Error State Design
Error State Design
Error State Design
The state of objects in the platform communicate errors in the system to users.
Object-Relationship & Error State Inheritance Analysis
The system components tied to a
Through this exercise it became clear that a
$workflow are hierarchical with multiple levels of states across different objects. These were structured to understand the direction of state inheritance.Through this exercise it became clear that a
$workflow is an unideal object to communicate child states-- there are too many of them for each client based on a quick query of the average number of workflows created per account. At the same time, $project were created to organize $workflows, but they have no communicative state properties that could be surfaced.
Requirements 6
Since users need to understand at what layer an error occurred to resolve an issue, we needed to design for effective system communications. Since
$workflows was too proliferate to be meaningful, I designed a new property to the higher level $project that would communicate the state of a set of $workflows to the user, so that they could have a bird’s eye view of how they were operating. Adding a summative state property to the $project object would also make the purpose of the $project object more immediately clear to users by providing more context to the $workflows inside, creating an entry point for rapid drill-down.Information Architecture
The information architecture that would support navigation was rapidly prototyped according to the major phases and tasks of working with data to help develop a clear mental model of the system. This progressive disclosure of steps that was organized in object-oriented manner would help users passively learn how to use our system for data analysis and engineering.
Generative Design Workshops
Interface ideas were generated in workshops across the organization to assess for potential user / product needs from internal stakeholders.
Product Design
With the architectural problems identified and resolved, the backend could meaningfully support a front-end experience that meets user needs.
UI Iterations
The top-level page for workflows was designed for monitoring, and iterations focused on structuring complex information for drill-down given the re-architecture. Early versions focused on an object-oriented (projects / workflows / tasks) vs. process-oriented (workflows / sessions / runs) display.
Workflow Monitor
The final UI combined the process-oriented timeline and object-oriented directory view into a toggle. States are persistent across both views to aide in error handling and can be filtered to only show error states. Tags were introduced for bottom-up navigation given the large number of workflows per customer.
Product Design
Workflow Details
Clicking into an individual workflow would surface the tasks and subtasks for the workflow, with the timeline showing its latest run. Timeline UI details changes subtly to indicate a shift in scale.
Workflow Runs
To aid in facilitation between technical and non-technical users, a visualization of the task dependencies as well as the raw YAML files are surfaced in the GUI. A history of edits to the workflow is also shown to provide additional human-centered context. Run attempts surface logs needed for de-bugging.
Product Design
