What to Design Before You Build an AI Workflow
Before you build AI into delivery, design the work: knowledge, roles, AI assist points, human judgement, quality checks, and ownership.
Published
An AI workflow is not only a tool setup. Before you build, design how the work should run: what people need to know, who does what, where AI helps, which decisions stay with a person, how quality is checked, and who maintains the system when something breaks.
Teams that skip this step often still ship something. The trouble shows up later: uneven output, unclear responsibility, and instructions nobody owns. That is a risk to watch for, not a claim that every build-first project fails.
What goes wrong when teams build first
A tool gets chosen because it is impressive in a demo. Prompts live in a few private chats. Review is “looks fine.” When the person who set it up is away, colleagues improvise. When the work changes, nobody updates the instructions. When something goes wrong for a client, it is hard to say who was responsible for the result.
None of that means the team lacked skill. It means the work was never designed as a shared way of operating. The build locked in whatever habits happened to exist on day one.
You can improve work you already do, or design something new. Both need the same kind of clarity before you invest in systems. The checklist does not care whether the work is old or new. It cares whether another person could run it without guessing.
The design checklist
Answer these in writing for the workflow you have in mind. Short answers are enough. Vague answers are a signal to stop and clarify before you connect tools.
- What people need to know – The facts, examples, constraints, and context the model and the person need for this kind of task.
- Who does what – Who prepares inputs, who runs the assist, who reviews, who delivers, who is allowed to change the approach.
- Where AI can help – Be specific: drafting, summarizing, structuring, checking against a list. Name what AI should not do.
- Where human judgement matters – Choices that affect clients, quality, risk, or reputation stay with a person who is responsible for the result.
- How the work moves forward – How a request becomes a finished piece: handoffs, waiting points, and what “done” means.
- Who handles upkeep and problems – Who updates prompts, instructions, and examples; who is called when the output is not good enough.
| Step | Person or AI | Where judgement matters | Who is responsible for the result |
|---|---|---|---|
| Prepare inputs | |||
| AI assist | |||
| Review | |||
| Deliver | |||
| Improve instructions |
If you cannot fill the last two columns, you are not ready to treat the workflow as everyday work.
The Design Council’s Framework for Innovation explains problem definition and iterative testing. This checklist applies our own workflow perspective.
Prototype vs ready for everyday work
A prototype answers: can this approach work on a real task with real inputs?
Everyday-ready work answers: can another person run it this week, with review where judgement matters, and with someone responsible for keeping it useful?
Those are different bars. A clever prototype can still be the wrong thing to put into daily delivery. Everyday use needs agreed inputs, a named review step, a definition of done, and an owner for the workflow itself – not only for a single task.
Stages, in plain order:
Idea → designed checklist → prototype on real tasks → everyday use with an owner.
Read the diagram as text
Idea, design the work, test a prototype on real tasks, then everyday use with review and an owner. A working demo and readiness for everyday use are different tests. Design clarity does not require buying a separate Design engagement.
Skipping from idea to everyday use is how responsibility gets blurry.
Human responsibility stays explicit
AI can speed drafting and structuring. It does not remove the need for a person who is responsible for the result.
Say who that person is for this workflow. Say where they must review. Say what happens when the output is not good enough. If those lines are missing, the team will invent them under pressure, and clients will feel the improvisation.
What a working demo leaves unanswered
A working demo shows that an approach can produce something useful on the task you tried. It does not establish who prepares inputs every week, who is allowed to send the work, or who will update the instructions when the offer changes.
Rework, uneven quality, and unclear responsibility are costs to consider alongside software. Use the checklist to expose those gaps before treating the workflow as finished.
Design without buying Design
Having enough design clarity is not the same as buying a separate Design engagement.
If the checklist above is already clear, roles are named, judgement points are agreed, and someone owns upkeep, you may be ready to move toward Implementation directly. Mode Lab can help build and put the approach into practice when that clarity exists.
If the checklist is still thin – especially on who does what, where judgement matters, or who maintains the system – Design work is how you establish that clarity. Sometimes Design stands alone as a plan, prototype, or decision. Sometimes it pairs with Implementation once the work is clear enough to build.
Neither path is a package menu in this article. They are ways to match the help to how clear the work already is.
Two labeled examples
Improving existing work (hypothetical)
Labeled hypothetical, not a client result.
A delivery team wants AI help on weekly client updates. Before any new tool is connected, they write the checklist: inputs from the shared tracker; project lead prepares; AI drafts; lead reviews facts and commitments; update sends; one delivery lead owns the instruction note. Only then do they build the shared instruction and the light tooling around it. The design made the build small and the responsibility clear.
A new service that combines expertise with AI (hypothetical)
Labeled hypothetical, not a client result.
A specialist firm wants to offer a new advisory product: a structured diagnostic that blends their method with AI-assisted analysis. Before they sell it, they design what the service should deliver, which client inputs are required, where AI helps with synthesis, what a senior person must review, how a prototype will be tested on a small set of real cases, and who maintains the method as it learns. That is still Mode Lab’s kind of work. It is not “automate an existing status update.” It is a new capability, designed before it is built or sold.
Keep both possibilities in view: improving work the business already does, and helping it do something new.
If you have not chosen the first improvement yet
If you are still deciding which existing workflow to improve first, start with selection criteria for a bounded first bet – business value, AI suitability, available information, ownership, testability, and the consequences of mistakes.
If people already have useful individual practices for a workflow you want the whole team to run, you will also need a shared way of working, not only a private prompt.
Start a conversation about the work
Mode Lab helps teams improve how their business works – and build new capabilities – with AI. We bring your team’s expertise and AI together to rethink how the work gets done, and help you put it into practice. You can engage us for Design, Implementation, or both, depending on how clear the work already is.
If you want to build capabilities yourself through learning and practice, Mighty AI Lab is a separate learning and community pathway for individuals and teams.
When you want help, start a conversation about work you want to improve or something new you want to build. Bring the checklist answers you already have, even if they are incomplete. That is enough to decide whether Design, Implementation, or both would be useful next.