A lot of workflows begin the same way.
Someone opens a project-management tool and creates a few columns:
To Do → In Progress → Review → Done
The board immediately feels more organized.
I have done versions of this too.
But after building workflows across creative, marketing, product, development, recruitment, and production, I have become much less interested in the columns themselves.
The more important questions are usually hiding between them.
What has to be known before work can start? Who decides that it is worth doing? What is someone waiting on? Who has the next action?
What makes something ready for review? Who can approve it? What happens when something changes?
Those questions changed how I think about workflow design.
A status tells you where the work is. A workflow defines what makes the work move.
Most teams design states. The real work is designing transitions.
A status is a state.
A task can be requested, in progress, under review, or complete.
Those states are useful because they give a team visibility.
But the workflow lives in the transition from one state to another.
Consider:
Requested → In Progress
What caused that transition?
Did someone decide the request was important enough to work on? Was the brief complete? Was the deadline realistic? Were the required assets available? Was someone assigned?
If none of those things are defined, moving a card into In Progress does not make the work ready to begin.
The same problem appears later.
In Progress → Review
What does “ready for review” mean?
And then:
Review → Done
Whose approval matters?
Does “done” mean approved? Delivered? Published? Archived?
The board can look perfectly clean while all of those decisions are still happening through conversations, messages, memory, and assumptions.
That is why adding more statuses rarely fixes a weak workflow.
You can have fifteen columns and still have no clarity about how the work moves between them.
You can also have four columns and a very strong workflow.
The difference is not the number of states.
It is whether the transition logic is clear.
I stopped starting with the board
This became especially clear while building creative workflows at DIGU.
It would have been easy to begin by deciding what statuses we wanted.
Instead, the more useful place to start was earlier:
How does work become work?
Creative requests can arrive almost anywhere—email, chat, meetings, conversations.
The problem is not simply getting those requests onto a board.
The problem is making sure enough context enters with them for someone else to make a good decision.
What are we creating? Why is it needed? Who is it for? When is it actually needed?
What information or assets already exist? Who should own it? Who eventually needs to review or approve it?
At DIGU, I built a creative-request workflow that connected intake with ownership, production, review, approval, scheduling, and completion rather than treating the request as simply another task entering a queue.
The useful lesson wasn't that a form is better than an email.
It was this:
Before designing where a task should go, define what must be true for it to move.
Sometimes the workflow problem is an information problem
The work is already moving. The question is whether that movement has been intentionally designed.
I encountered a different version of that at SCAD, where I work as a Photographer.
Model availability was recurring production information, but there was no structured system around it. Producers would send emails and receive individual responses in different formats.
The problem was not where to move those responses next.
The problem was that someone still had to interpret the information, compare schedules, and turn inconsistent responses into something useful for production planning.
So I introduced a structured form-based availability process that collected the information consistently and made it easier to review. The broader model-management workflow also moved model information from a static list into a structured, searchable ClickUp system.
That experience gave me another way to think about workflow problems:
A workflow is only as useful as the information it hands to the next person.
In that situation, the answer may not be another stage or another status.
Sometimes the better intervention happens earlier: structure the input so less work is required downstream.
It may be a better input, a required field, a clearer source of truth, a standardized format, or a searchable system.
That changes the question from:
“Where should this task go?”
to:
“What does the next person need in order to act?”
The board may only be one view of the workflow
The distinction became even clearer when I worked on DIGU's recruitment workflow.
Recruitment did not happen inside one project-management board.
The process crossed multiple systems.
A job needed to be managed internally in ClickUp and published to the DIGU website. Applicants needed a way to enter the process, their information needed to connect with HubSpot, and internal teams needed visibility into what was happening.
I defined the operational workflow connecting those pieces, with developers implementing the API integrations between systems.
At that point, thinking about the workflow as a set of columns would have been actively limiting.
The board was useful.
But it was only one interface into the system.
The actual workflow was the movement of information, responsibility, and decisions across several tools and people.
That led me to a principle I now find useful:
The tool is not the workflow. The workflow is how information, decisions, and responsibility move between people and systems.
That distinction matters because teams often try to force everything into one platform in the name of organization.
Sometimes that works. But sometimes the better system is a connected set of specialized tools with clearly defined handoffs between them.
The goal is not to make everything live in one place. It is to make the movement between places understandable.
Five questions I now ask before building a workflow
The specific stages change depending on the work, but I keep coming back to five questions:
How does the work enter?
What triggers it, who can request it, and what information needs to arrive with it?
What must be true before it moves?
Does it need approval, complete information, an asset, a dependency, or a decision?
Who has the next action?
Not simply who owns the task overall, but who is responsible for moving it forward now?
What happens when the expected path breaks?
What if something is blocked, requirements change, feedback reopens the work, or priorities shift?
What should happen automatically, and what still requires judgment?
Which movements are predictable enough to automate, and which decisions still need context?
If I cannot answer those questions, adding statuses usually just gives the uncertainty somewhere prettier to sit.
Automation becomes easier once the logic is clear
This is also why I prefer defining the workflow before thinking about automation.
When the transition rules are clear, the repetitive parts become easier to identify.
If something predictable happens:
A form is submitted → create the record.
A task becomes ready → notify the next owner.
A known condition is met → move information into another system.
Those are good candidates for automation.
But other transitions contain judgment.
Is this request actually worth prioritizing? Is this creative work strong enough?
Does this solution answer the original problem? Has the context changed enough that the plan should change?
Those decisions may ultimately change a status too, but the status change is only the consequence.
The decision is the important part.
Automation should remove coordination work, not replace judgment.
The goal is not maximum automation.
It is removing repetitive operational effort so people can spend more time on the decisions that actually require them.
Simple on the surface does not mean simple underneath
I still prefer simple boards.
The sophistication of a workflow should not be measured by how many columns it has.
I would rather have four statuses with clear inputs, decision points, ownership, transition rules, and exception handling than fifteen statuses that simply describe increasingly specific places for work to wait.
The question is not:
What statuses do we need?
It is:
What has to happen for this work to move?
Once that is understood, the statuses become much easier to design.
And sometimes there are only four of them.
Most workflow problems are not really status problems.
They are transition problems—unclear information, unclear decisions, unclear ownership, or unclear conditions for moving forward.
Design those first.
The board is only the visible layer. The workflow is the logic underneath it.