Where work used to wait

Most studios accept handoff friction as the price of running a creative team. We rebuilt the studio's work system around flows instead of tasks. Each step belongs to someone, the next person gets notified automatically, and the work moves whether or not anyone remembers to push it. The system holds the handoff. People hold the craft.

Not a task notification. Not a system alert. A person pinging another person to say: hey, I think that thing you were waiting on is done. Or: did anyone pick this up after the design was signed off? Or the quieter version, no message at all, just a deliverable sitting completed while the next step waited for someone to notice.

The studio was working. Projects were shipping. But there was friction everyone had quietly accepted as the cost of running a small creative team. It lived in the spaces between people, between design and development, development and review, any step and the next. The system was built around individuals finishing their part. It was not built around the work moving forward.

The handoff was entirely human-managed. The alignment meetings existed to cover it. When we looked at what those meetings actually contained, almost all of it was information that already existed somewhere. The design was done. The files were there. What was missing was the signal: the automatic passing of context from one step to the next, and the notification that said now it is your turn.

We noticed the pattern. We built a different system.

A task is no longer a single thing assigned to a single person. It is a flow, an ordered pipeline of steps, each with its own assignee, its own department, and its own deliverables. Design, development, story, motion, review. Each step belongs to someone. The flow itself belongs to the objective.

When a step is completed, the next person is notified automatically. There is no empty space. The work does not wait to be discovered. It moves.

But the notification is only part of it. The more important change is visibility. Everyone in a flow can see every step, regardless of which step they are responsible for. The developer can see what the designer did, what was decided, what the deliverables were. The reviewer can see the full sequence of work that preceded their review. Someone joining a project mid-way can open the flow and understand exactly where things stand, without a briefing call and without asking anyone to catch them up.

The flow holds the context. The system holds the handoff. The people hold the craft.

Our first instinct was strict linear blocking. Step two cannot start until step one is done. Step three waits on step two. It felt logical, and for certain types of work it was.

Then we ran into the natural exception. Two developers working on two independent parts of the same build. No functional reason to make one wait for the other. The system was creating friction where none existed in the actual work.

So we flipped the default. Steps in a flow are free to begin in parallel unless a dependency is set. Dependencies are added manually, where they actually exist. The result is a system that mirrors how creative work actually moves: sometimes sequential, sometimes simultaneous, never artificially blocked.

The one exception is review. Review steps are automatically blocked by everything that comes before them. This is the only place the system is opinionated about order, and the reason is obvious: reviewing work before the work exists is not review, it is guessing. We made the system hold that one constraint firmly so no one has to remember to set it.

Review used to be a badge. You would attach it to an existing task, mark it for review, hand it to someone, and call it done. The work was the same task. The review was metadata on top of it.

That model broke in practice for several reasons. Reviewers had no dedicated space for their own deliverables. The original assignee's context bled into the reviewer's, or got lost entirely. And critically, you could not plan reviews when creating the work. They happened reactively, which meant they could be forgotten, delayed, or skipped.

Now a review is a step in the flow. It is planned when the flow is created, alongside every other step. It carries its own deliverables, defined in advance, so the reviewer knows exactly what they are assessing. It sits in sequence with design and development, with the same notification behavior and the same visibility.

We initially tried giving review its own dedicated department, a designated reviewer role that only certain people could hold. It was too rigid. The right reviewer for a piece of work is not always the same person, or the same type of person. Sometimes it is the founder. Sometimes it is a peer in a different discipline. Sometimes it is the person who wrote the brief. Opening review to everyone made it a function of the work, not the org chart.

Each step in a flow belongs to a department. Design, Development, Story, Motion. This is not administrative categorization. It is how the studio understands and communicates the nature of each piece of work.

When you look at a flow, you can see at a glance which disciplines are involved, in what order, and who from each discipline is responsible. You can see whether a project is design-heavy or development-heavy. You can see where the handoffs are. You can see whether motion or story is part of the deliverable at all.

Departments make it possible to scale this model without manually managing who needs to know what. The structure carries that information automatically.

Open a flow and you see the whole picture at once. The name of the flow at the top. The client and milestone it belongs to. A row of steps laid out in order, each one showing the assigned person, the department, and the current status. Below that, a status row with priority, duration, and a progress bar. And below that, a deliverables block for the current step, where each item is checked off as the work gets done. We wanted it to feel less like a ticket system and more like a shared understanding of what the work actually is.

The progress bar is not an estimate. It is the percentage of deliverables completed across the active step. One out of three checked means thirty percent. The number is factual, not projected.

Revisions are built into the same structure. If a design step needs a second pass after review, a revision step is added to the flow. The flow extends. The history stays intact. The work continues from exactly where it is, not from a clean-slate assumption that the first version was final.

A flow and a task list look similar at first. Both are collections of items. The difference is what they represent. A task list is linear and static. It exists to be completed. A flow is dynamic. It represents movement, collaboration, and progression across stages.

Translating that difference visually was the harder problem.

The flow had to feel alive. Not like a checklist. That meant moving away from the patterns task lists rely on, rows, checkmarks, rigid structures, and pulling ownership, progress, and status directly into the component. The visual carries the meaning. It does not describe it.

Space was the biggest constraint. Each flow item needed to show ownership, progress, state, and priority inside a small footprint. The job was to increase information density without increasing visual weight.

Responsiveness pushed the same problem further. On smaller screens the space shrinks again, but the flow still has to read as a flow. We designed the component in two states: a default state with richer context, and a compact state where the avatar becomes the central element and progress wraps around it as a visual container. The behavior and the identity hold at every size.

The challenge was less about fitting UI into small spaces and more about building a visual system that communicates progression and collaboration, and stays distinct from the familiar pattern of a task list.

There were two things we built and then rebuilt, and both of them taught us something.

The first was linear blocking. We started by making every flow strictly sequential: you cannot begin step two until step one is complete, no exceptions. In practice it created unnecessary waiting in situations where two steps had no real dependency. We removed the default and made dependencies opt-in. The system got out of the way.

The second was the review department. We created a dedicated department for review, which meant only certain people could be assigned to review steps. But it made review a bottleneck and a title rather than a behavior. Opening review to everyone preserved the structure while removing the gate.

Both changes came from the same observation: the system works best when it handles the things that should always be true, and stays out of the way on everything else.

The alignment meetings changed first. The ones that existed purely to relay status shrank significantly. The system was answering those questions continuously. The meetings that remained were the ones that should have been meetings all along: creative decisions, client strategy, things that genuinely require a conversation.

People started having a more complete picture of the work they were contributing to. A developer working on one step could see what the designer had done before them and what the reviewer would be checking after them. That context changed how they worked. Not because they were told to think about those steps, but because they could now see them.

And when someone is unavailable, the flow does not lose its context. The next person steps in and sees everything: what was done, what was decided, what is next. The knowledge stopped living exclusively in people and started living in the work itself.

The reason we are writing about this is not that we built a tool. The reason is that the tool came from noticing a pattern, and the pattern is the part that matters.

We look for places where work depends on memory or manual coordination or individual heroics, and ask what it would look like if the system handled that instead. We do this with the studio's own operations. We do it for every client we work with. The website where the team has to remember to update three places when the price changes. The brand that drifts the moment the person who designed it leaves the room. The product whose architecture assumes the team will stay the same size forever. Every project, somewhere in it, has an empty space where the system isn't doing its share of the thinking.

The throughline is the same: reduce dependence on heroics, increase dependence on structure. Not because people are unreliable, but because structure scales and people have limits. The goal is a system where the work can move, even when the people are busy.

The flow system in this article is part of the Hooman Dashboard, the studio's tool for managing work, clients, communication, and team coordination. We built it because every external tool we tried got us partway there and stopped. The full picture, client communication, milestone tracking, file management, internal workflows, could not be handled in one place without us maintaining bridges between systems.

We wrote about a related instance of this thinking in our case study on Maisōn Harry George, a build where the right technical decision was the one that anticipated how the client's team would manage the product after launch, not just how it would perform at launch. Same principle. Structure that works without heroics.

The dashboard is opening to studios and teams outside Hooman over the coming months.

The flow is not a feature. It is a way of thinking about how work moves through people. Once you see the empty space, you cannot unsee it.