Designing workflow experiences for humans, not systems
Why traditional workflow systems fail outside technical-first domains
If you’ve been building software for the last 20 years, you’ve definitely heard about workflows.
They’re usually described as a way to move from a set of inputs to an outcome: trigger something, evaluate conditions, execute actions.
With AI, workflows are having a comeback moment. They reduce hallucinations by constraining models into deterministic paths.
But this post isn’t about AI workflows. I’ll leave that for another time.
Because the truth is this: workflows have existed for decades, and we still struggle to design them well.
The classic workflow abstraction
From a system point of view, workflows are built from three blocks:
Triggers: the event that starts the workflow
Conditions: rules that split logic into different paths
Actions: what happens as a result
This abstraction has spread everywhere: CRMs like HubSpot or Attio, automation tools like n8n or Retool, and internal platforms like Intercom.
And for good reason.
Workflows are flexible, powerful, and let users customize software without engineering help. You expose a few building blocks and let users assemble what they need.
So why do they feel so painful in practice?
The hidden cost of workflows
After working with workflows across multiple products, the downsides repeat themselves.
Maintenance debt: As platforms evolve, workflows silently break. Only the creator knows why something exists or what it depends on.
In this example from HubSpot, there’s no way to understand at a glance what those 60 workflows are doing. Conflicts: Multiple workflows can react to the same trigger and undo each other’s actions. Powerful, but dangerous.
Learning and sharing: Once you have dozens of workflows, understanding the system becomes nearly impossible without heavy documentation.
Experience: Large diagrams don’t scale. Navigation becomes harder than reasoning about logic.
Despite this, if you look for references, the main experience is more or less the same.
Our first workflow system at Factorial (2020)
At Factorial, we shipped our first workflow system in 2020.
The goal was simple: allow companies to customize the platform, starting with notifications.
If we could nail this, we believed we could later extend it to any company process.
The flow was standard:
Choose a trigger
Set conditions
Select a notification
We validated the idea with a Figma prototype.
The prototype showed a very straightforward scenario:
Create a notification for a recruiter when a new candidate enters the ATS.
The validation felt smooth, and users completed the task. We moved forward.
We were excited, and so were our investors. There was a strong belief that if this system worked for notifications, it could become the foundation for the entire HR platform.
We shipped.
And almost immediately, we realized we had failed.
Where the mental model broke
HR users knew exactly what they wanted:
I want to notify Legal when a contract is signed.
But the system forced them to think like this:
Trigger: document signed
Condition: document is a contract
Action: notify Legal
Their mental model was the inverse:
Send notification
to Legal
when a contract is signed
Same logic. Completely different experience.
What looked obvious in a guided prototype became confusing in a real, unprotected environment.
The feature worked, but only with training and onboarding.
We shipped the system in 2020, and we stopped developing it shortly after.
Five years later: procurement
In 2025, workflows resurfaced when we started building our Procurement product.
Procurement defines how companies structure their purchase processes.
When the word “workflows” appeared again, I was concerned. Our 2020 experience was still very present.
But after discovery work, we reached a different conclusion: the traditional diagram-based system was the industry standard in Finance. Big players were already using this approach.
This time, we validated differently.
Instead of a narrow task, we built a fully clickable prototype where users could recreate one of their real purchase processes.
No scripts. No happy paths. Just their reality.
Surprisingly, users had very few problems navigating the interface and building their flows.
That’s when the insight landed: Finance users have a different mental model.
They are used to thinking in processes, steps, and diagrams. Many finance tools already expose similar visualizations.
Same abstraction. Different audience. Completely different outcome.
Designing the procurement workflows with restraint
Even knowing diagrams worked better here, we avoided building a fully generic system.
We simplified aggressively in two ways:
Trigger and first step as defaults: When creating a workflow, users start by selecting the purchase category. The first step is always configuring a form, a predefined template with mandatory data.
Linear vs. parallel tasks: Instead of branching diagrams endlessly, parallel tasks live inside a single step.
The system stayed powerful without turning into a visual maze.
Onboarding: the same abstraction fails again
A few months later, we started a new product: employee onboarding.
We had already invested heavily in procurement, so we reused the same workflow engine and interface.
History repeated itself: HR users struggled again and the experience didn’t scale.
The same issues surfaced:
Hard to understand what’s happening
Hard to manage conflicts
Massive horizontal and vertical scrolling
The abstraction was solid. The experience wasn’t.
Changing the model, not the engine
This time, we didn’t touch the technical foundation.
We changed the mental model.
The trigger was hidden; it never changed
Date conditions were embedded into navigation
Users built actions as a simple timeline
But what about conditions?
Conditions didn’t behave like in Procurement. Most onboarding flows are identical, with small variations depending on the employee’s location, role, or contract type, but the main structure stays the same.
So instead of letting conditions split the workflow, we embedded them inside tasks.
A task could say:
Execute only if role = Engineer
Skip if workplace = Remote
Change owner if contract = Freelancer
The workflow stayed linear, and the variability became local.
For HR users, it became a no-brainer.
Builder ≠ runtime
One last lesson.
The interface for building workflows should not be the same as the interface for following them.
Admins need structure.
Employees and requesters need clarity.
We separated the two experiences:
Kanban-style overviews for owners
Simple task timelines for participants
No triggers. No conditions. Just what’s next.
Conclusions
After five years, three products, and a few expensive mistakes, these principles held:
Abstractions are never neutral: Triggers, conditions, and actions encode a way of thinking. When it doesn’t match your users’, friction is inevitable.
Mental models beat industry standards: Diagrams worked for Finance and failed for HR. Copying the market is easy. Designing for how people think is harder and far more effective.
Localize complexity: If variation is local, keep it local. Global branching is often a design smell.
One engine doesn’t mean one interface
Reuse foundations, not experiences.
Restraint is a design skill
Power doesn’t come from exposing everything. It comes from hiding the right things.
Workflows won’t disappear, and we should stop pretending that one abstraction fits everyone.