Process-First or Screen-First?
When someone starts building a business application, they usually start with screens. What does the contact list look like? What fields should the deal form have? How should the invoice detail page be organized?
This is a natural starting point — you can see it, you can show it to stakeholders, you can make decisions about it based on what it looks like.
But we think starting with screens is often the wrong starting point.
The Screen-First Problem
Screens are a presentation of data. They answer the question: how do users look at and interact with records? That's an important question, but it's not the most important one.
The more important question is: how does work actually move? What triggers the creation of a record? What determines who sees it? What has to happen before it can advance to the next stage? Who needs to take action, in what sequence, for the process to complete?
When you start with screens and work backward to process, you often end up with screens that expose data well but don't guide work effectively. Users see the information they need, but the platform doesn't help them understand what to do with it.
Process-First Design
Process-first design starts with the workflow. What is this record trying to accomplish? What are the stages it moves through? What triggers each transition? What actions should the system take automatically vs. what requires human input?
Once the process is defined, the screens become almost obvious — they're the surfaces through which users interact with the process. The list view shows where everything is in the workflow. The detail view exposes the information relevant to the current stage. The action buttons correspond to the transitions available.
Where Workflows Drive UI
The most satisfying applications to use are ones where the interface reflects the process. The actions you can take are the ones that make sense right now. The information visible is the information relevant to the current stage. The notifications you receive tell you when it's your turn to act.
This coherence between process and interface is hard to achieve when you start with screens and retrofit the process. It comes naturally when you start with the process and let it define the interface.
In Practice
We've designed Swifty's workflow and screen systems to work together this way. Workflows define transitions, which drive what action buttons appear. Record status drives what fields are visible and editable. The process definition shapes the interface automatically.
Start with the process. The screens will make more sense.