Designing for AI Means Designing for Cognitive Load
In my previous article, I wrote about the risk of mistaking AI activity for progress, and asked where the saved time actually goes.
There is a related question that I think matters just as much: where does the cognitive load go? In many cases, AI clearly reduces effort in a task. The question is where the effort moves when that task becomes easier.
A developer may spend less time writing the first version of the code, but more time reviewing, verifying, integrating and explaining it. A product manager may spend less time drafting a document but more time deciding whether it clarifies the problem or simply makes uncertainty look more polished. A team may generate more options but still needs to work out which option is safe, valuable, and aligned with the user's need.
AI adoption needs to be designed with cognitive load in mind.
Local Load and Structural Load
One of the problems with the AI productivity conversation is that it often focuses on the local task. Can this person write faster? Can this team produce more? Can this document, test, feature, analysis or prototype be created in less time?
Those are reasonable questions, but they are not enough. Organisations do not deliver value through isolated acts of personal productivity; they deliver value through connected systems of work.
A local reduction in cognitive load can still create a structural increase elsewhere.
If code is easier to generate, review may become more demanding. If analysis is easier to produce, decision-making may become more overloaded. If documentation is easier to create, alignment may become harder because there is more material to interpret. If an AI agent can execute more of the work, someone still needs to understand what it did, why it did it, and whether the result is good enough.
The load has not necessarily gone away. It may have moved to the boundary between teams, to the review process, to the people with the most context, or to the points in the system where judgement is hardest to automate.
That is why I think we need to distinguish between reducing cognitive load locally and globally.
The first makes a task feel easier. The second makes the system easier to work in.
From Felt Overwhelm to Visible Load
Shifted cognitive load is often hard to see. It doesn’t always appear as a single obvious bottleneck. It appears as slower decisions, heavier reviews, duplicate checks, more conversations needed to build confidence, or a growing reliance on a small number of people who understand enough of the system to determine whether the AI-assisted output is safe to use.
Teams may describe this as overwhelm.
“There’s a lot going on.”
“Everything depends on everything else.”
“We’re spread too thin.”
That language is understandable, but it is not very actionable. The team can feel the load, but they cannot always point to where it is coming from.
This is where mapping becomes useful, as a way of turning intuition into shared evidence.
When you make the work visible, you can start to see where cognitive load is accumulating. Dense dependency clusters. Long value chains. Capabilities touched by several teams. Boundaries that require constant negotiation. Areas where no one is clearly stewarding the whole, but everyone is carrying part of it.
AI adoption can make those patterns more important because the work now moves more quickly into parts of the system that were already difficult to reason about.
Where AI Tends to Move the Load
It is useful to look at AI adoption and ask where it changes the amount of context someone needs to carry, because that is where cognitive load often shows up.
If a team uses AI to generate code within a well-understood service, with good tests, clear ownership, and fast feedback, the load may genuinely decrease. The work is contained, the boundaries are clear, and the team can judge the output with confidence.
But if the same AI-generated code spans several services, touches on an unclear capability, relies on undocumented assumptions, and needs review from people in three different teams, local speed may not help much. The cognitive load has shifted to coordination, verification, and integration.
This is the distinction that matters.
AI adoption is lower risk where the surrounding system is easy to reason about. It becomes harder where the surrounding system is already fragmented.
That might mean a dense dependency cluster where small changes require multiple teams to coordinate. It might mean scattered stewardship, where several teams touch the same capability but no one is clearly accountable for its coherence. It might mean a long, fragile value chain in which a user outcome depends on many steps, systems, and decisions. It might mean overlapping responsibilities, where different teams make different assumptions about who should review, approve, maintain or operate the result.
These are already sources of cognitive load. AI can make them more visible, but it can also make them more costly if organisations scale usage without understanding where the load is likely to move.
Designing AI Adoption Around Cognitive Load
If we treat AI adoption as a cognitive load design challenge, the conversation changes.
It is no longer just:
Where could AI make people faster?
It becomes:
Where can AI reduce cognitive load without increasing it elsewhere, in more fragile areas?
That leads to different design choices.
In some areas, the right move may be to create clearer guardrails so teams can use AI safely without needing to understand every underlying concern. In others, it may be to improve tests, feedback loops and observability before increasing AI-assisted change. Sometimes the priority is clarifying who stewards a capability, because generated work is only useful if someone can judge whether it is coherent. Sometimes it is reshaping a boundary because too many teams currently need to understand too much of the system to make a safe change.
This is also where team interactions matter.
If AI introduces uncertainty, teams may need to collaborate as they learn what good looks like. If the path becomes repeatable, they may need something closer to X-as-a-service so others can move with less coordination. If teams need to build judgement and confidence, they may need enabling support rather than another dependency.
The point is not to force AI adoption into a particular model. The point is to notice what kind of interaction the work is asking for. If anything, AI makes these design choices more urgent because it lowers the cost of producing work before the organisation has necessarily improved its ability to absorb it.
Make the Load Visible Before Trying to Lower it
There is a temptation to jump straight to the question: how do we reduce cognitive load?
But a better starting point is: where is cognitive load highest, and why?
That is the question that turns a vague feeling of overwhelm into something teams can reason about together.
Where does a change require too much surrounding context? Where do people need too many conversations to build confidence? Where does AI-assisted work create more review burden than expected? Where are the same people repeatedly pulled in because they hold knowledge the system depends on? Where does a team need to understand more of the value chain than it reasonably should?
Once that is visible, the design conversation improves.
You can decide whether to simplify a dependency, clarify stewardship, improve the feedback path, create enabling support, invest in platform capability, reshape a boundary, or slow down adoption in an area where the organisation cannot yet safely verify the work.
This approach treats AI adoption as part of the wider system of work, not as a layer of productivity tooling placed on top of it.
From AI Activity to Flow Decisions
AI can amplify good engineering practices, clear boundaries, strong feedback loops and well-understood team interactions. It can also amplify ambiguity, dependency, review burden and unclear decision-making.
That is why the question is not simply whether people are using AI enough. The question is whether AI is making the system easier or harder to work in.
This is the space I am exploring with Fast Flow Toolkit: helping teams and leaders make these shifts visible enough to act on. Where is work getting stuck? Where is cognitive load accumulating? Where has AI changed the shape of the work? What decision would make the system easier to change?
Not every AI adoption effort needs a redesign. Most do not. But if AI changes how work gets done, we need a way to see where the workload has shifted before assuming the system has improved.
Because the real opportunity is not just to make tasks faster. It is to design the work so teams can deliver value with less unnecessary cognitive load in the system.
DM me if you’d like to be involved with the Fast Flow Toolkit beta. www.fastflowtoolkit.com
