Design Thinking for Human–AI Operating Design
Use Observe, Reflect and Make to design how people and AI share work, with clear judgement, responsibility and one bounded trial.
Published
A useful AI experiment can leave a team with several unanswered questions. Who prepares the information? Who checks the result? What happens when the request is unusual? And who changes the instructions when the work changes?
Those questions become easier to answer when you work through a real task together. Watch how it runs, discuss what needs to change, then try a small change that the team can evaluate. Design thinking gives that practice a useful shape.
Design the way the work runs
Operating Design shapes how people and AI work together to improve business performance and build new capabilities. It defines how expertise guides the work, who does what, who decides what, and how the work gets done.
That means looking beyond what an AI tool can produce. A good draft still needs the right sources, someone who can judge it, and a clear next step. When those parts are unclear, adding AI can leave the team with more material to review and the same unresolved decisions.
The design needs to be something people can try. A shared instruction note, a different handoff, or a clear review point can give the team enough to learn from before committing to a larger build.
A useful starting point: IBM’s Loop
IBM Enterprise Design Thinking describes the Loop through three activities: Observe, Reflect and Make. They repeat as a team learns, rather than forming a sequence to complete once. IBM explains the practice in its Enterprise Design Thinking framework.
The application below is Mode Lab’s interpretation for work shared by people and AI. IBM provides the Loop terminology; the roles, review decisions and workflow examples here are our own application of it.
When making a trial gets easier
AI can reduce the effort of preparing a draft, sketch or small prototype. That makes it possible to try an idea earlier, before committing to a larger build. The time saved does not remove the need to understand the work or decide whether the result is useful.
Read the diagram as text
Before AI-assisted prototyping, making may take most of the effort. With AI assistance, making may take less effort while observation and reflection remain necessary. This is a possible pattern, not measured costs.
This is a pattern to look for in your own work, not a claim that every build is now cheap. Integrations, data preparation and reliable operation can still take substantial effort. When a trial becomes easier to make, protect time to compare it with the old way: what improved, what became harder, and what would the team have to maintain?
Observe, Reflect and Make in everyday work
You can enter the loop wherever you have a useful question. Include all three activities so that what you learn leads to something the team can try, and what you try gives you something new to learn.
Observe: watch a real task
Choose a piece of work that matters to the business and follow it from request to delivery. Include the people who do the work and those who receive it. Notice where they wait, repeat an explanation, look for missing information, or ask someone else to make a decision.
Look at where AI already helps. Someone may use it to summarize notes or prepare a first draft, but the rest of the team may not know which sources or instructions they used. Ask what makes the output useful and what the person still has to check before passing it on.
The aim is to understand the work well enough to choose a change worth testing. If the problem is a missing client decision, faster drafting may not help.
Reflect: agree what needs to change
Compare what people noticed. Where does avoidable effort accumulate? Which decisions require experience? Where are people working from different assumptions about what is ready to use?
Be clear about what AI can handle, which decisions need a person’s judgement, and who is responsible for the result. For a client recommendation, for example, AI might organize agreed source material while an experienced team member decides what the evidence supports.
Agree on the business improvement you want to test. That could be fewer corrections at handoff, a more useful client discussion, or less time spent rebuilding context. Decide how you will recognize an improvement without treating more generated output as success.
Make: try the change
Give the team something concrete to use: shared instructions, a sketch of the workflow, a sample deliverable, or a small prototype. Include who supplies the information, what AI may do, where a person reviews the work, and what happens when something is missing or wrong.
Keep the trial small enough to inspect. Name the person who will run it and the person who will maintain the instructions; they may be the same person. Agree when to review what happened and when to stop if the trial creates problems.
Then return to observation. A working prototype shows that an approach may be useful. Everyday use also needs reliable checks, clear responsibility and a way to handle exceptions. The design-before-you-build checklist helps make those details explicit.
Run a short loop on one stage
You do not need to redesign the whole business to learn something useful. Pick one stage of a workflow, describe how it runs today, and choose a change small enough to test. Write down what would make it better before seeing the new version.
Read the diagram as text
Choose one stage. Name the old way, ask what is now possible, and test the smallest version with AI assistance where useful. A person asks: better, or just new? Stop and record the learning if it is not useful. If useful, prepare it for reuse and further checks.
The last decision belongs to a person: is it better for the people doing the work and those relying on it? If the trial is not useful, record why and stop or change it. If it is useful, capture the method and its limits, then test whether someone else can use it. A promising trial is a starting point for implementation.
One specialist-team walkthrough
This is a hypothetical example, not a client case study.
Imagine a twelve-person research and strategy team preparing a research pack for a client presentation. A few people use AI for summaries and outlines. Each has a different approach, and the strategist receiving the pack has to work out what was checked before using it.
Observe. The team follows one pack from researcher to strategist to creative lead. They look at how sources are selected, how uncertain findings are described, and how a finding becomes a recommendation. They also examine where AI summaries enter the work and whether anyone can trace them back to the original material.
Reflect. The team identifies a question to test: would agreed sources and a clear review point reduce the corrections needed before the presentation? They decide that AI may organize those sources and prepare draft summaries. A named strategist will check the evidence, judge uncertainty and take responsibility for recommendations to the client.
Make. They try this on one research pack over the following week. A short instruction note defines the sources and expected structure. The strategist reviews every summary before it enters the presentation. AI cannot send anything to the client. A delivery lead maintains the note and records missing information, errors and changes needed during the trial.
At the next review, the team can examine those records alongside the finished pack. Did the handoff become clearer? What did the strategist still have to correct? Was the preparation effort worthwhile? The answers determine what they change or test next. The trial itself is not evidence that the business has improved.
Keep what makes the result repeatable
A useful experiment is easy to lose when its sources, instructions and corrections stay in one person’s session. Record what went into it, the steps that mattered, what needed checking, and where it failed.
Read the diagram as text
Each square represents a test. Without captured instructions the work is hard to repeat. Capture useful methods and checks during the trials, then prepare and test them for reuse. Recording alone does not establish reliability.
That record might become shared instructions, a checklist, a reusable skill or a small tool. Choose the form that helps the next person run and check the work. Writing it down does not make it reliable by itself; try the captured method on another real task and give someone responsibility for keeping it current.
Let someone outside the trial try it
The person who built the trial knows things the instructions may never explain. Ask a teammate or intended user to try it with appropriate information and access. Watch where they hesitate, what they misunderstand, and what they need to ask you.
Read the diagram as text
Inside the loop, you test and judge the method. Show it to a teammate, client or person who will use it. Ask them to try it; bring what breaks for them back into your loop and revise.
Bring those difficulties into the next version. If the method only works while you are explaining it, there is more design work to do before handing it to the team. This check helps reveal whether you have made the work easier for someone else, as well as for yourself.
When part of the loop is missing
IBM calls out two risks: analysis paralysis when observation and reflection never lead to making, and blind faith when making and reflection happen without observation. The cautions below apply that idea to work involving AI; “blind automation” is our description, not IBM’s term.
Planning without a trial. The team keeps refining its workflow map but never tests whether anyone can use it. Choose one task, one owner and a change small enough to try. The trial can reveal what another planning session cannot.
Building without watching the work. An automation follows the normal steps but misses the exceptions people handle every day. Watch those decisions before expanding the build. A successful demo does not tell you whether the workflow fits the business.
Rolling out before agreeing responsibility. People disagree about which decisions AI can make or assume someone else is checking its output. Pause the affected work and resolve those decisions. Keep AI’s actions within limits the team understands and can review.
Where to begin
Choose the starting point that fits the question in front of you:
- Work takes too much effort. Observe the task where effort builds up. Find out whether the cause is missing information, repeated work, a difficult judgement or an unclear handoff.
- Useful AI habits are still personal. Compare how people use AI, then try a shared method that another team member can follow and check.
- You want to offer something new. Describe what the customer should receive, examine the expertise and information it needs, and test a small version of the service.
- You are deciding whether to hire or invest. Examine the work the additional person or tool would take on. A short trial may help clarify the role or the investment; it does not make that decision for you.
Start one short loop
Pick one workflow and bring together the people who do it and depend on it. Agree what you will observe this week, what you need to decide together, and what small change you will try. Name who will review the result and when.
Mode Lab designs how people and AI work together, then helps your team put that design into practice. If you need help working out what to change or how to test it, start a conversation about the work you have in mind.