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 -- and enables our clients to orchestrate real-time data pipelines to modularize and digitize their domain operations for repeatability, scalability, and collaboration.
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 vertical 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.
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 $sessionTime
and $session
because $sessionTime
identifies the $session
.
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.
$session
is overloaded as word to describe the object, we need to pick a new word that organically occurs with use, one that, ideally, reduces the multi-syllabic word salad problem that often occurs when trying to describe the things in the system.$session
and $sessionTime
need to re-named and/or re-architected for clarity. Words are important in that our sales and sales engineering team will repeatedly use them to describe what is happening, and a poorly chosen name impedes learnability. Further, it will show up in documentation and a poorly chosen name becomes obvious in technical writing. $workflow
.$workflow
is in production. Enabling users to resolve issues quickly is synonymous with good navigation.$workflow
are hierarchical with multiple levels of states across different objects. These were structured to understand the direction of state inheritance.$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 $workflow
s, but they have no communicative state properties that could be surfaced. $workflow
s 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 $workflow
s 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 $workflow
s inside, creating an entry point for rapid drill-down.$project
was later re-named to $group
to be more agnostic about the intent for the collection of items.$group
was chosen as the top-level object on the root screen given the number of existing $workflow
s. A filter was introduced to navigate across $workflowState
s. Tags were introduced for bottom-up navigation to provide a mechanism to organize similar $workflow
s across $group
s.$workflow
surfaces all its $session
s in an overlay. Terminology was carefully calibrated on the overlay to shape the concepts associated with a $workflow
. Through columnar adjacencies, the user is able to understand a $workflow
has a $session
history with $run
s. Two date-time parameters are shown to reinforce that there is a difference between the data scoped to $sessionTime
and the data processing kick-off of $runTime
. The $workflow
definition is shown at the same level of the $workflow
$session
history to indicate that the definition is shared across $session
s.$session
as a data management middle layer. $workflow
on the timeline would maintain monitoring mode on-click to show the progression its latest $run
at a $task
and $subTask
level. With the $run
as the lowest-level object and site of failure investigations, the user is able to bypass selecting intermediary $session
s to target specific $run
s.$run
page reflects a $session
in the header component to simplify the mental model further. The $runId
and $attempt
are treated as details instead of first-class objects.$session
's $workflow
to surface the same $session
history overlay that displays a list of all $run
s.