Designing validation for complex workflows
A scalable error and warning experience that helps workflow authors detect, understand, and resolve issues across iWorkflow.
I designed the validation and error-resolution experience for iWorkflow conditions, focusing on how users discover, understand, and resolve errors and warnings across fields, code blocks, conditions, and functions.
Role
UX Designer
Timeline
3 Months
Product
Digitate Studio
Platform
Enterprise SaaS
My Responsibilities
Research, IA, Journey Mapping, Interaction Design, Wireframes, High-Fidelity UI
Scroll to explore ↓
Quick Project Overview
Role
UX Designer
Team
Cross Functional
Timeline
3 Months
Platform
Enterprise SaaS
Tools
Figma, XD, Miro, Jira
Contribution
Research, IA, UI
Screens Designed
145+
Screens & interaction states
Product
Digitate Studio
01 — Context
About Studio
Studio is Digitate's knowledge modeling platform that enables organizations to build enterprise workflows through modular automation. Within Studio, iWorkflow acts as a visual workflow editor that combines graphical workflow creation with scripting, making workflow development faster for both developers and business analysts.
Visual workflow
Function configuration
Conditions
Script logic
02 — THE ACTUAL PROBLEM
The validation problem
How might we help workflow authors identify and resolve issues without losing context?
As workflows became more complex, validation feedback could exist at multiple levels of the experience—from required fields and conditions to function-level states and individual lines of code.
The challenge was not simply showing an error. It was helping users understand where the issue originated, how severe it was, and what action they could take next.
03 — THE ACTUAL ISSUES
What made validation difficult?
1
Issues existed at different levels
A problem could belong to a field, condition, function, or specific line of code.
2
Errors and warnings behaved differently
Errors could block progression, while warnings could still allow users to continue.
3
Issues could multiply
A function could contain multiple conditions, creating multiple validation states that needed to remain understandable.
4
One line could have multiple states
A single line of code could contain both an error and a warning, requiring a representation that communicated both without ambiguity.
04 — Problem Statement
How I got to know the problem
How might we make validation understandable at scale?
As workflows become more complex, validation feedback could exist at multiple levels of the experience from required fields and conditions to function-level states and individual line of code
Workflow authors needed a way quickly answer 4 question
1
Discover
Where is the issue ?
Locate the exact node, field or line of code with an issue.
2
Understand
What is wrong ?
See clear details & context about the issue.
3
Prioritize
Error or warning ?
Understand the severity or execution.
4
Resolve
What action should I take ?
Locate the exact node, field or line of code with an issue.
5
Revalidate
Is the issue resolved ?
Re - run validate to confirmall issues are fixed.
05 — The Challenge
Defining Success
Before jumping into design, I worked with product managers, architects, and developers to understand what success would look like—not only for users, but also for the business.
1
Surface issues early
Users should understand validation status before committing changes.
2
Preserve context
An issue should remain connected to the function, condition, field, or code where it originated.
3
Differentiate severity
Errors and warnings should communicate different levels of urgency and behavior.
4
Make resolution actionable
Users should be able to move from an issue summary directly to the relevant place to fix it.
5
Scale with complexity
The validation model should remain understandable as functions contain more conditions and issues.
06 — User and Context
Understanding who creates workflow and what there needs from validation
Studio iworkflow is used by different users with different levels of technical expertise. I spoke with business analyst, operation users and developers to understand how they configure workflows, where they face challenges, and what they expect from validation feedback.
Primary user
Primary workflow author
Business Analyst / Operations user
Configure and maintain logic without needing to understand every underlying implementation detail
Primary goal
Configure and maintain workflow logic without needing to understand every underlying implementation detail
Needs
Clear workflow structure
Understandable Validation
Actionable errors
Minimal developers dependency
Confidence before saving
Pain points
Unclear issue location
Technical error messages
Repeated Navigation
Difficulty Distinguishing warning from blocking errors
Limited visibility into code level issues
Secondary user
Developer / Technical User
Need deeper code-level validation and precise issue details when troubleshooting
Primary goal
Identify debug and resolve code-level issues with accurate validation details
Needs
Precise error details with line numbers
Context of code and function
Clear severity (error and warning)
Quick navigation to the issue
Ability to revalidate after fixing
07 — Information Architecture
Understanding the structure of iWorkflow
iWorkflow sits within Studio's Code Body and gives users two complementary ways to work: a visual workflow builder for configuring functions and conditions, and a Code Editor for working directly with the underlying script.
Product navigation hierarchy
iWorkflow - Configure functions, conditions, and navigation through a visual interface.
Code Editor - Work directly with Pre, Main, and Post blocks when deeper script-level control is required.
Validation architecture
Context : Adding a Catlog function in iworkflow
Validation feedback can exist at multiple levels in catlog function - from function details, to conditions, navigation, fields & scripts.
08 — WHAT WASN'T WORKING before
What made validation difficult?
The existing experience surfaced errors and warnings, but did not clearly communicate where they originated or how many issues existed at each level. Users had to repeatedly navigate through function, condition, and script areas to identify and resolve issues.
Function-level ambiguity
Mixed issue sources
Function, condition, field, and script issues appeared together.
High navigation cost
Users had to click Resolve and determine where the issue belonged.
No clear hierarchy
The interface didn't distinguish between function-level and condition-level problems.
Hidden code-level validation
Issues hidden behind hover
Users couldn't immediately see the complete validation state.
Multiple severities were difficult to scan
Error + warning combinations were visually ambiguous.
No issue count
Users couldn't quickly understand the total number of errors/warnings in the script.
The problem wasn't a lack of validation. It was a lack of validation hierarchy.
09 — EXPLORING THE SOLUTION
Designing a scalable validation experience for complex workflows
I translated the requirements into wireframes to explore how validation feedback could work across different parts of the iWorkflow experience. The goal was to create a consistent system that helped users identify, understand, and resolve issues without overwhelming the workflow interface.
Before validation, I first mapped the condition structure.
A condition combines several pieces of workflow logic: a caption, executable script, and the destination when the condition evaluates to true.
Before deciding how validation should behave, I first looked at where users were making these decisions and how those different parts of the configuration related to one another.
Condition identity
Caption defines what the condition represents in the workflow
Logic
Scripts contain the executives logic for the condition and can have line level issues.
Workflow path
Defines the next node when the condition evaluates to true
DESIGN DECISION:
The important design decision here is not a visual redesign.
It's the recognition that validation has to understand the structure of the configuration.
A problem in the Caption is fundamentally different from a problem inside the Script. And a problem in the script itself may exist at an even deeper level — eventually down to a particular line or column.
This becomes the foundation for the validation hierarchy later in the case study:
Condition → Script → Line → Issue
The condition editor brings together identity, logic, and workflow navigation in one configuration surface.
Some issues had to block the user from continuing.
Missing mandatory information is different from something that simply needs attention.
For these cases, the validation experience had to clearly communicate that the save action could not proceed, while also identifying the fields that required action.
The goal was to turn a generic blocking state into a clear next step: find what is missing, fix it, and continue.
Blocking state
Clearly communicates that user cannot procced until the required information is provided
Actionable field references
Scripts contain the executives logic for the condition and can have line level issues.
DESIGN DECISION:
The important decision is severity before detail.
At this stage, the user doesn't need a complicated error-management interface. They first need to know:
Can I continue or not?
The modal establishes that boundary.
Then, rather than hiding the reason behind a generic “Required field” message, the validation identifies the affected configuration areas — Script and If True, go to.
That creates the first level of the hierarchy:
Save → Blocking validation → Affected field
Blocking validation establishes whether the user can safely continue.
Not every issue should stop the workflow.
I separated validation into two levels of severity.
Errors represent issues that prevent successful completion. Warnings highlight something that should be reviewed, while still allowing the user to continue when appropriate.
This distinction became important because treating every issue as blocking would make the workflow unnecessarily rigid. The interface needed to communicate severity without overwhelming the user.
Feedback at the field
Warnings are shown directly at the field level, so users know exactly where to take action
Error (Blocking)
Prevents successful completion. Use must fix the issue to continue.
Warning (Non blocking)
Needs attention but does not prevent continuing. User can still save.
Review required
Clearly communicates that some fields needs additional information
Non-blocking
Informs the user that you can still save, while recommending a review
DESIGN DECISION:
The design is not simply changing red to yellow.
The system is communicating a difference in consequence.
An error answers: “You cannot complete this yet.”
A warning answers: “You should review this before proceeding.”
That distinction allows validation to scale beyond a single form. The same severity language can later appear at the function, condition, code, and save-review levels.
Warnings communicate risk without turning every issue into a blocker.
Validation had to move closer to the code itself.
As the workflow became more complex, a field-level message was no longer precise enough.
A single script could contain multiple issues across different lines, with errors and warnings occurring at the same time. Users needed to see not only that the condition had a problem, but where the problem existed inside the code.
This pushed the validation model one level deeper: from the condition, into the script, and finally toward the specific line containing the issue.
Line-level issue
Shows the exact line in the script where the errors exists.
Warning
Highlights non blocking issues that needs attentions.
Issue count
Display the total number of errors and warnings in the scripts
DESIGN DECISION:
Instead of forcing users to leave the editor and search elsewhere for what is wrong, the validation feedback appears in the same context where the problem exists.
The user can now move from:
Condition → Script → specific line
without losing context.
This is the beginning of the scalable validation model that you will reveal in the next section.
Inline indicators connect validation feedback directly to the code that requires attention.
From isolated messages to a validation hierarchy
The exploration shifted my thinking from designing individual error states to designing a connected validation system.
Function
What part of the workflow has an issue ?
Identifies the function where the validation issue exists (e.g.. Catalog fn, OnProxy).
Condition
Which condition is affected ?
identify the specific condition within the function that has an issue.
Code
Where in the code is the issue ?
Pinpoints the script and the exact line/column where the issue occurs
Issue
What is the issue ?
Shows the type and the severity of issue (error and warning) with clear details.
Resolve
What can i do about it ?
Provides clear guidance to fix the issue and successfully save the workflow
A connected validation system.
10 — Final Validation Experience
The function became the first layer of the validation hierarchy.
Instead of exposing every issue at once, I introduced a function-level summary that tells users whether the configuration contains errors or warnings.
The summary gives users an immediate sense of the function's state without forcing them into the details.
From here, users can choose whether they need to investigate errors, warnings, or move deeper into a specific condition.
Error count
Dropdown shows the total number of errors in the function area
Warning
Dropdown shows the total number of warnings in the function area.
Issue count
Display the total number of errors and warnings in details, conditions, navigation tabs.
DESIGN DECISION:
The key decision was summarize before exposing detail.
In a complex enterprise workflow, showing every issue immediately can make the interface feel overwhelming. The function-level summary creates an initial information boundary.
The user first learns: “There are problems here.”
Then they decide: “I want to inspect them.”
This is the first implementation of the principle:
Progressive disclosure should follow the user's need for detail.
A function-level summary provides a quick health check before users investigate individual issues.
Details appear only when the user asks for them.
The summary became the entry point, not the destination.
Expanding an issue group reveals the individual problems and provides a direct Resolve action. This keeps the default state compact while still giving users a clear path into the details when they need them.
The same interaction pattern could then be applied consistently to errors and warnings.
Error count
Dropdown shows the total number of errors in the function area
Individual issues
shows each specific error with clear descriptions
Resolve
Provides a direct action to fix the issue
DESIGN DECISION:
The system separates:
Awareness
There are 2 errors.
Investigation
Here are the 2 errors.
Action
Resolve this one.
That reduces visual density while preserving access to the information needed for debugging.
Progressive disclosure moves the user from awareness to investigation without overwhelming the default view.
The summary became actionable at the condition level.
Function-level counts tell users that something needs attention. The next step was connecting that information to the specific condition responsible for it.
Each affected condition can surface its own validation state, with a direct Review now path into the relevant details.
This reduces the search space: users don't have to inspect every condition to find the one containing the issue.
Affected condition
Clearly identifies which conditions contains the issues
Validation count
Shows the total number of errors and warnings for particular conditions
Review now
Provides a direct path to view and resolve the script issues and warnings
DESIGN DECISION:
This is where the validation system becomes genuinely useful in a complex workflow.
A count alone is not actionable.
The interface therefore creates a chain:
Function has issues → this condition has issues → review this condition
The Review now action is particularly important because it reduces navigation cost.
Condition-level feedback narrows the user's search from the entire function to the configuration that needs attention.
At the code level, validation becomes contextual.
Once users entered the condition, validation became more precise.
Errors and warnings were attached directly to the relevant lines inside the script, allowing users to see the relationship between the issue and the code that produced it.
The validation model was no longer simply telling users that something was wrong. It was helping them locate where to investigate.
Error indicator
Highlights the exact line where the error exist.
Warning indicator
Shows the line that needs attentions but does not block saving.
Review now
Displays the total number of error and warnings count of script area.
DESIGN DECISION:
The key principle here is contextual feedback.
Moving the feedback into the editor means users don't have to remember an error from another screen and then search through the code to find it.
The issue appears alongside the thing being edited.
This creates a tighter loop: See → Locate → Investigate
Inline validation keeps the issue connected to the code where the user needs to investigate it.
Severity had to remain distinguishable, even when issues overlapped.
Real validation is rarely one issue at a time.
A code line could carry more than one type of feedback, so the visual language needed to preserve the distinction between errors and warnings without obscuring the underlying code.
This reinforced the need for a consistent severity system rather than relying on color alone.
Error + Warning on the same line
A single line can have both errors and warning simultaneously
DESIGN DECISION:
This is an important accessibility and information-hierarchy point.
The user should not have to interpret an ambiguous visual marker.
The indicator communicates:
There are multiple validation states associated with this code context.
The detailed resolution layer can then separate those issues into actionable records.
This creates a clear distinction between: Detection and Resolution.
Overlapping validation states required the severity model to remain clear at the point of detection.
Detection was only useful if users could act on it.
Once an issue was identified, users needed more than an icon or a highlighted line.
I structured the details view around the information required to investigate and resolve the problem: line, column, issue details, and action.
This created a direct path from the validation signal to the resolution step, while keeping the code context visible above.
Where
Line number shows the exact line in the script .
Exact Location
Column number helps users quickly identify the position of the issue
What happend
Clear error descriptions. Explains the issue in simple actionable language.
What next
Resolve action. provides a direct way to navigate to the issue and fix it.
DESIGN DECISION:
The hierarchy now reaches its most actionable level:
Function tells users there is a problem.
Condition tells them which configuration is affected.
Code shows where to look.
Issue details explain what is wrong.
Resolve provides the next action.
This is the complete validation chain you established earlier:
FUNCTION → CONDITION → CODE → ISSUE → RESOLVE
The key design decision is that these aren't separate validation features. They are connected levels of the same system.
Issue details turn validation from a signal into an actionable resolution path.
The interface could shift between broad context and focused resolution.
Validation does not always happen at the same level of attention.
The full-script view gives users the broader context needed to inspect a longer piece of logic, while the focused view brings the relevant code and issue details together when the goal is resolution.
The underlying validation model remains consistent across both views; only the amount of context changes.
Same validation model
The validation language and behavior remain consistent across both views
Partial script view
Full script view
DESIGN DECISION:
The design separates information hierarchy from information availability.
The information remains available, but the interface can change the amount of context presented according to the user's task.
That makes the experience more usable for complex scripts without removing the ability to inspect the complete workflow logic.
Different levels of context support different stages of investigation without changing the underlying validation language.
The final checkpoints turns validations into save decision
When the user attempts to save, the system first performs a final validations pass.
Once the validations is complete, a consolidated review is shown with the critical errors, warnings, and fields that may require additional information, so the user can make an informed descision.
Validations in progress
After the user clicks save, the system validates the node details and checks the code errors and warnings
Review before saving
Once the validation is complete a consolidated summary is shown so the user can review the findings before committing the change
DESIGN DECISION:
A deliberate save flow.
Introducing a validations step and a final review before saving prevents users from committing changes with unresolved issues and builds confidence in the system.
Users can review and resolve issues before saving, reducing network and improving overall configurations accuracy.
From interaction patterns to a consistent system
The solution was built within Studio's existing design language, using established visual, semantic, and interaction patterns to keep validation consistent across the product.
11 — Design System
12 - Beyond this case study
The validation experience was one part of a much larger Studio iWorkflow design effort.
Working collaboratively with another designer, I contributed to a broader product experience spanning 145+ screens across workflow creation, configuration, scripting, navigation, validation, and supporting states.
145+ screens across the broader Studio iWorkflow experience.
This case study focuses on validation as one representative problem where I could show the design process and interaction decisions in depth.
Next Case Study