I work upstream — structure, scope, and design direction before the team executes.
Technical systems I could read structurally — patterns in complex data, structural failures in workflows, the hidden load beneath a clean interface. The harder problems were never in the system. They were in the gap between what the system did and what humans needed it to do.
I/O Psychology gave me a second diagnostic lens. It taught me to read human and organisational systems the way engineering taught me to read technical ones — structurally, not symptomatically.
Twelve years later: GlobalLogic, Experion Technologies, Folka, McKinsey. Environments where the cost of misalignment between human intent and system behaviour is high, and where intuition-based design breaks fast.
I get called in when the usual approach has already failed.
Most organisations track design capacity by hours. This model fails because cognitive work is not uniform in weight, a large portion of design work never appears in any project tool, and coordination overhead in distributed teams is invisible to every burndown chart.
Leadership made resourcing decisions on visible deliverables. Designers experienced workload as cognitive, emotional, and coordination weight. The two never matched.
I identified this as a translation problem, not a productivity problem. I built WDCF: a five-dimension weighted scoring system that gives every design task a Weighted Capacity Score — a language leadership can read and designers can use without it sounding like complaint.
The same problem exists in AI product design. When a system's behaviour is invisible to the people depending on it, trust breaks. Making invisible behaviour legible is the design problem in both cases.
The instinct when capacity feels broken is to ask for more headcount or a better process. I went one step back and asked why every existing measurement method was failing.
Story points are engineering-native — they don't transfer to design work. Hours logged capture input time but nothing about quality of attention or context-switching cost. Deliverable count rewards volume without accounting for revision cycles or upstream ambiguity. Headcount ratios ignore skill specialisation and cross-team reach. Self-reported load suffers from anchoring bias and systematic under-reporting in low-trust environments.
The reframe: this was not a resourcing problem. It was a translation problem. The cognitive cost of design work existed — generating burnout, missed commitments, and failed headcount cases. It had no number attached to it. And without a number, it had no voice in an enterprise decision room.
| Method | What it measures | What it misses |
|---|---|---|
| Story Points | Relative effort (engineering-native) | Cognitive load, invisible work, coordination cost |
| Hours Logged | Time spent on tracked tasks | Quality of attention, context-switching, async work |
| Deliverable Count | Quantity of outputs | Revision cycles, upstream ambiguity, strategic weight |
| Headcount Ratio | Designer-to-engineer ratio | Skill specialisation, project complexity, cross-team reach |
| Self-Reported Load | Subjective sense of busyness | Anchoring bias, imposter syndrome under-reporting |
Cognitive Load (30%) — Sweller's theory distinguishes intrinsic load from extraneous load added by coordination and process. Miller and Cowan's working memory research establishes a ~4-chunk capacity limit. Tasks exceeding this threshold degrade output quality regardless of reported effort.
Collaboration Complexity (25%) — Wegner's Transactive Memory Systems research shows coordination cost scales non-linearly with team size in distributed environments. Never appears in any task tracker.
Iteration Depth (20%) — Each revision cycle involves re-engagement with prior decisions, stakeholder re-explanation, and sunk-effort re-anchoring. The psychological cost compounds across cycles.
Invisible Work (15%) — Hochschild's emotional labour theory: stakeholder management, conflict absorption, and ambiguity facilitation are psychological work with a measurable cost. They do not appear in Jira.
Strategic Weight (10%) — Carries lowest share because its psychological pressure is partially captured in Cognitive Load through Prospect Theory's loss-aversion effect.
The formula: WCS = (CL × 0.30) + (CC × 0.25) + (ID × 0.20) + (IW × 0.15) + (SW × 0.10). Scale 1.0–5.0. Each dimension scored 1–5 against explicit behavioural anchors to prevent inter-rater drift and allow longitudinal comparison.
Four operational states. The Optimal Zone (2.5–3.4) is grounded in the Yerkes-Dodson performance curve: too low is disengagement, too high is degraded output quality.
The deliberate constraint: the entire system runs in Google Sheets. Zero procurement. Zero onboarding friction. Any manager opens the live dashboard in a browser today. The constraint is a feature. A tool that requires an approval process to adopt would die in that process.
| Designer | Mon | Tue | Wed | Thu | Fri | Avg | State |
|---|---|---|---|---|---|---|---|
| Designer A | 3.2 | 3.8 | 4.1 | 4.3 | 3.9 | 3.86 | Caution |
| Designer B | 2.1 | 2.4 | 2.8 | 3.1 | 2.9 | 2.66 | Optimal |
| Designer C | 4.2 | 4.5 | 4.4 | 3.9 | 4.1 | 4.22 | Overload |
| Designer D | 1.8 | 2.1 | 1.9 | 2.3 | 2.0 | 2.02 | Underutil. |
WDCF is a trust calibration system. It exists because there was a structural mismatch between the true state of a system — actual designer capacity — and the signals available to the people making decisions about it.
That mismatch is the central design problem in human-AI products. When an AI system takes an action without making its reasoning visible, when its confidence is uncalibrated, when its failure modes are undisclosed — the person depending on it is making decisions based on incomplete signals.
The design question is identical in both cases: what needs to be made legible, to whom, in what form, so that trust is earned through transparency rather than assumed through absence of failure.
"WDCF is not an AI product. It is a proof of concept that I think in this structure."
The brief described a capability: an AI assistant that could run technical programs — generate status, update Jira, draft stakeholder comms, pull from Workspace. It read as a feature list. Underneath it there was no user model, and no agreement on the one word the whole product turned on: agentic.
Three groups used that word to mean three different things. To engineering it meant autonomous execution. To the program managers it meant a faster first draft they still controlled. To leadership it meant headcount leverage. All three would have approved the same screen and expected a different product.
This was not an interface problem wearing the word "AI". It was a trust-and-scope problem. The design question was never what does the assistant look like — it was what the agent is allowed to do without asking, and what it must never do without a human in the loop. I did not design a screen until that line was drawn.
An agent acting inside someone's program is making decisions under their name. The moment its authority is ambiguous, the PM either rubber-stamps it or stops trusting it — automation bias in one direction, abandonment in the other. The boundary is the product; the interface is only where it becomes visible. Making invisible authority legible is the problem WDCF solved for invisible capacity — one layer up.
The instinct in the room was to build the assistant and react to feedback. That ships the disagreement — everyone projects their own definition onto the same demo, and the conflict resurfaces in production, where it is expensive. I ran a definition exercise before any UI existed.
I enumerated every action the tool could theoretically take and asked one question of each, across all three groups: should the agent do this on its own, propose it for approval, or never do it. The disagreements were not random. They clustered exactly where the stakes were highest — anything that touched a commitment, a deadline, or a written message carrying the PM's name.
The reframe: "agentic" is not a capability level to dial up. It is a permission structure to negotiate. I killed the framing of "how autonomous should it be" — that question assumes a single axis, and there isn't one. Autonomy is per-action, and it is governed by consequence, not by how capable the model is.
| Stakeholder | Their definition | The risk it ignored |
|---|---|---|
| Engineering | Autonomous execution, end to end | Who is accountable when the agent is wrong under the PM's name |
| Program Managers | A faster draft they still approve | Silent scope creep — the agent committing more than intended |
| Leadership | Headcount leverage, throughput | Erosion of the human judgment the role exists to provide |
I sorted every agent action into three tiers. Autonomous: the agent acts and writes it to a log. Proposed: the agent drafts, the human commits. Prohibited: the agent never acts — it escalates to a person.
The placement rule was behavioural, not technical. An action moves to Proposed or stricter when the cost of being wrong is borne by someone who can no longer inspect it — the PM absorbs the relational damage when a wrong message goes out under their name. I anchored each tier to consequence and reversibility, never to model confidence — because confidence is precisely the signal users over-trust. Tie the boundary to confidence and you have automated the bias instead of designing against it.
Automation bias is the mechanism: under load, people accept system output without verifying it. The boundary does not ask the PM to be more vigilant — vigilance is not a design. It moves verification to the few points where being wrong is expensive and hard to undo, and removes it everywhere else.
Once the boundary was agreed, the interface followed almost mechanically. Autonomous actions surface as a reviewable log — present, never interruptive. Proposed actions stop at a commit step the PM owns: the draft is the agent's, the decision is the human's. Prohibited actions have no button. The absence is the design.
I killed the concept engineering most wanted — the ambient assistant that quietly acts in the background. It tested as anxiety, not assistance. A program manager cannot be accountable for a program whose state is being changed by something they can't watch. Background autonomy over accountable work is a trust leak, not a feature.
The governing principle is legibility: at any moment the PM must be able to reconstruct what the agent did and why. An agent you cannot audit is an agent you cannot trust — and an assistant nobody trusts gets switched off, regardless of how capable it is.
The deliverable was a boundary, not a layout. Engineering received a permission spec. Leadership received a scope they could not quietly widen. The PMs received an assistant whose authority they could name — which is the precondition for trusting it at all.
This is the same structure as WDCF. There, I made invisible human capacity legible to leadership so resourcing decisions matched reality. Here, I made invisible agent authority legible to its user so delegation decisions matched risk. Both are trust-calibration problems: a system acting on signals its decision-maker cannot fully see.
Get the boundary too loose and the PM rubber-stamps — the agent's mistakes become theirs. Too tight and they abandon it — you have shipped expensive autocomplete. The calibrated middle is not a confidence threshold. It is a named, auditable line between what the agent owns and what the human owns.
"An agent's intelligence is not the design problem. Its authority is. Get the boundary wrong and capability becomes liability."
I joined mid-crisis. Autonomous Figma AI agents had been deployed to audit and update content across live canvas frames — no human verification gate before their output reached production. Main component overrides were breaking. Auto-layouts were collapsing. Text was silently reverting to library defaults. Developers were inspecting frames while agents were still editing them, asynchronously, underneath.
The instinct in the room was to slow the agents down or turn them off. That treats the symptom. The agents weren't malfunctioning — they were doing exactly what they were told, at a speed nothing else in the workflow was built to match. The real problem was structural: no one had defined the line between what an AI agent could touch alone and what required a human to sign off before it shipped. That's not a tooling gap. It's a missing permission model — the same shape of problem I'd solved twice before, one layer down.
I didn't propose a new tool. I proposed a boundary.
Override Resets — Agents ran direct frame actions that altered layer trees, stripping text overrides and detaching component instances back to library defaults. Missing Verification — no human-in-the-loop gate was enforced before agent output merged, so broken canvas states reached live inspect views. Silent Handoff Shift — developers inspected frames while agents modified copy asynchronously, so the frame a developer opened was never the frame that had been reviewed.
The pattern underneath all three: agents were operating with the same level of trust in every context — exploratory drafts and production-locked canvases treated identically. Capability and authority had never been separated. I refused to write agent usage guidelines until that separation existed, because a guideline layered on an undefined boundary just documents the chaos more neatly.
| Failure Mode | What Happened | Structural Cause |
|---|---|---|
| Override Resets | Layer trees altered, text overrides stripped, instances detached to library defaults | Same trust level applied to exploratory and production-locked canvases |
| Missing Verification | No human-in-the-loop gate enforced before agent output merged | No checkpoint separated "agent has acted" from "output is safe" |
| Silent Handoff Shift | Developers inspected frames while agents edited them asynchronously underneath | Capability and authority were never separated |
The logic mirrors the autonomy-tier model from the TPM agent work: placement isn't about what the agent is capable of — it's about how expensive and how reversible a mistake is at that layer. Exploration is cheap to undo, so agents run free. A production component library is expensive to undo and invisible until a developer hits it downstream — so it's forbidden outright, no matter how good the agent's output looks in isolation.
| Task Category | Status | Execution Environment | Verification |
|---|---|---|---|
| Exploration & Generative Copy | Allowed | Separate file / branch | Self-review by designer |
| Bulk Content & Translation Audit | Restricted | Draft staging page | HITL verification checklist |
| Main Component Updates | Forbidden | Design system library | Strictly manual / DS maintainer |
| Live Dev Handoff Pages | Forbidden | Dev-ready locked canvas | Read-only / human signed-off |
1. Agent Sandbox — content audits run only on isolated draft pages or branches, never live frames. 2. HITL Review — a designer audits component overrides, text, and auto-layout integrity before anything moves forward. 3. Handoff Lock — reviewed screens promote to a locked "Ready for Dev" canvas; agents are never run against it again. 4. Sync & Log — an automated changelog notification fires to engineering the moment handoff status changes, so nobody is inspecting a frame that's still being edited underneath them.
Rollout was phased deliberately, not big-banged: Week 1 locked current dev-ready pages, ran a component health audit, and published the guidelines. Weeks 2–3 connected agent logs to track error rate and token efficiency, shipped standardized handoff-header components (IN DRAFT / AI AUDITED / DEV READY — LOCKED), and closed with a joint Design–Engineering retro to surface remaining friction before it calcified into distrust.
Every version of this problem has the same anatomy: a system is acting on incomplete signals, and the person depending on it doesn't know it. In WDCF, leadership couldn't see real cognitive load. In the TPM product, a program manager couldn't see what the agent had just committed under their name. Here, a developer couldn't tell whether the frame in front of them was finished or still being rewritten by something else.
The fix is never "more oversight" — vigilance doesn't scale and isn't a design. The fix is a named, auditable line, placed by consequence and reversibility, that tells every party — human or agent — exactly what they're allowed to touch without asking. Get that line right and speed comes back, because nobody's double-checking work they can already see is safe.
"The agents weren't the incident. The missing gate was."
I work best when the brief is incomplete, the scope is contested, or the previous approach has already failed. That's not a constraint — that's the job.