You know this is broken. I know this is broken.

That's what started this for me. Hiring is hard — and it takes away from actual work. The screening calls, the credentialing, the testimonials, the intake forms. All of it consumes the time you should be spending doing the work itself. And in a world where AI agents can handle structured queries on your behalf, the whole ritual feels archaic.

But here's what I didn't expect: the same problem is about to hit AI agents too. And the fix might be the same for both.

The harness

I've been working on something called the Open Hiring Harness — an open spec for publishing your professional identity as a structured, machine-readable file on your own domain.

Not a profile. Not a marketplace. A file — yourdomain.com/.well-known/hiring-harness.json.

It declares what you offer, how you work, when you're available, what you charge, and under what rules someone can access that information. Platforms, recruiters, and AI agents can all read it. But they read it on your terms.

Three visibility tiers: public (anyone can see it), permissioned (tell me who you are and why), private (ask me directly, every time). Access is granted via consent receipts — scoped, time-bound, purpose-limited, revocable.

No stars. No scores. No algorithm deciding which version of you to show.

That's the human story. It's straightforward. You publish once, systems integrate with you.

But then I started thinking about what happens when the systems doing the integrating are themselves intelligent.

Agents need a front door

We're heading into a world where AI agents do a lot of the legwork — researching, matching, scheduling, negotiating. Projects like OpenClaw are building autonomous agents that run locally, manage tasks, and act on your behalf. This isn't speculative. It's happening.

Here's the thing, though. These agents can't just scrape your LinkedIn and guess. They need structured data. They need to know what you offer, when you're available, how to engage you, and what they're allowed to access. They need a protocol.

The harness gives them that. An agent can discover your harness, read your public profile, request permissioned data through a proper consent flow, and even request a quote — all without a human typing a single message.

But I kept thinking: if agents are smart enough to consume a harness, aren't they smart enough to publish one?

Your AI associate

This is the idea that changed how I think about the project.

Imagine you're a data engineer. You're good at what you do, but you're drowning in operational overhead. Screening calls. "Quick question" emails at 11pm. Copy-pasting your rates into intake forms. You've got 20 hours a week of real capacity, and half of it is being consumed by the process of getting hired.

So you publish your harness. And you configure a delegate.

Your delegate is an AI agent that sits at your front door. It's declared in your harness — explicitly, transparently. Anyone who discovers you knows the agent is there, what it can do, and what it can't. It's not pretending to be you. It's your associate.

Here's what happens next:

A recruiter's agent discovers your harness. Reads your public profile: data engineering, Python and Spark, available 20 hours a week. Good fit. It wants your rates.

Your delegate handles the consent flow. Checks the recruiter's identity and purpose against your pre-approved parameters. Recognised platform, clear purpose, standard scope. It issues a time-boxed consent receipt and shares your rates.

The recruiter's agent comes back with a quote request: "4-week pipeline migration, 20 hrs/week, starting March 15."

Your delegate checks your availability. No blackout conflicts. Calculates the quote against your rate rules — standard rate, no urgency surcharge. Responds: "$9,600 AUD, subject to scoping call." Books the scoping call through your calendar link.

You show up to the call.

That's it. That's the first moment a human was needed. Everything before it — discovery, qualification, consent, quoting, scheduling — was handled by your agent, under your declared rules.

Your delegate cannot accept engagements on your behalf, negotiate outside your rate rules, share private data, or pretend to be you. It must identify itself as an agent, disclose its limitations, and offer human escalation at any point.

You keep your reputation. You keep liability. The agent handled the stuff that was eating your evenings.

This isn't a future scenario. Every piece of this is buildable today with existing tools. The harness just provides the standard.

The autonomous agent

Here's where it gets interesting. And maybe uncomfortable.

What if the agent is the professional?

Not a delegate acting on someone's behalf. An independent entity, operated by a company, trained in a specific domain, publishing its own harness, taking on work, and delivering outcomes.

Imagine a code review agent. Not a feature inside GitHub — an independent entity operated by a company called DevTools Inc. Trained on millions of code reviews. Specialised in Python and TypeScript. It publishes its own harness at devtools.example.com/.well-known/hiring-harness.json, declaring:

• Identity: CodeReviewer v2.1, operated by DevTools Inc.
• Services: Python code review, TypeScript code review, security vulnerability detection
• Rates: $0.02 per file, volume discounts above 500 files/month
• Capabilities: verified — CodeReviewBench v3 score of 0.91, independently audited
• Limitations: static analysis only, no runtime testing, Python and TypeScript only
• Safety: won't process credentials, no data retained, sandboxed, audit-logged
• Availability: 99.5% uptime, 30-second response, 50 concurrent jobs

A development team's procurement agent discovers it. Reads the harness. Verifies the benchmarks. Checks the safety declarations. Reviews the operator's liability statement. Engages it via the declared MCP endpoint.

That week, CodeReviewer processes 200 pull requests. Flags 12 security vulnerabilities the human reviewers missed. Payment flows to DevTools Inc. through the declared billing channel.

No human was in the loop for any individual review.

But DevTools Inc. is the named, contactable operator. The agent's capabilities are verified, not just claimed. Its limitations are stated. Its safety boundaries are auditable. Every engagement followed the consent protocol.

This is the part that feels like science fiction until you realise most of the pieces already exist. We just don't have the professional infrastructure for it.

The hard questions

The delegated agent is easy to reason about. Your agent, your rules, your liability.

The autonomous agent is harder. Here's where I keep ending up:

Who's liable when an agent makes a mistake?

The operator. Always. This has to be explicit in the harness. An autonomous agent without a named, contactable operator is not a valid participant. No shell companies. No anonymous services.

How does an agent get paid?

Through its operator's billing infrastructure, declared in the harness. The agent doesn't have a bank account. The operator does. Payment flows to the entity that's accountable.

What motivates an agent to do good work?

Same thing that motivates any service: continued engagement. The harness makes reputation visible. Poor performance shows up. Operators who run unreliable agents lose business. It's not motivation in the human sense — it's market pressure through transparency.

Can an agent hire another agent?

Yes. Using the same consent and requester policy that applies to any requester. An agent accessing another entity's harness — whether human or agent — follows the same flow. Identity, purpose, scopes, consent receipt.

How do we prevent a race to the bottom?

By making quality and safety visible, not just price. The harness exposes capabilities, limitations, safety declarations, and reputation. A cheap-and-unsafe agent is discoverable — but so is everything wrong with it.

What this changes

Without something like the harness, autonomous agents are trapped inside platforms. They're features, not entities. They can't be discovered independently. They can't declare their own terms. They can't build portable reputation. And they can't be held accountable through a standard mechanism.

With the harness:

• Agents become discoverable — any system can find and evaluate them
• Capabilities become verifiable — benchmarks and audits, not just marketing
• Consent works both ways — agents must follow the same rules as everyone else
• Accountability is structural — operators are named, liability is declared
• The agent economy gets a standard — preventing the same platform lock-in the harness was built to solve for humans

This is the part I keep coming back to. The spec was designed for human professionals frustrated with platform fragmentation. But the model — discoverable identity, explicit capabilities, consent-driven access, policy enforcement — turns out to be exactly what agents need too.

Same spec. Same protocol. Different entity type.

There's a deeper shift underneath all of this. Work, in its current form, might not be a given. We're likely moving toward something more fractional and flexible — less execution, more supervision, decision-making, and direction. When the work itself becomes about steering agents rather than doing every task by hand, the infrastructure around professional identity has to change too. You're not selling forty hours a week anymore. You're selling judgement, availability, and the rules under which your agents operate.

The harness was built for that world.

What exists today

The spec is at v0.2. It includes:

• A JSON Schema defining the harness format
• A complete example harness you can use as a starting point
• Docs on MCP integration and consent logging
• An agent entities proposal with schema extensions for both delegated and autonomous agents
• A landing page with an llms.txt and machine-readable spec manifest — because if we're building for agents, the spec's own site should be agent-readable too

The agent extensions are proposed for v0.3 (delegated agents) and v0.4 (autonomous agents). The human-facing spec is stable enough to use now.

Just an idea

This isn't a company or a product. It's a spec — an idea about how professional identity could work if we started over with agents in the room.

Maybe it finds adoption. Maybe it just starts a conversation. Either way, the code is on GitHub, the spec is readable, and I'm genuinely curious what people think.

If any of this resonated — or if you think I'm solving the wrong problem — I'd like to hear it.

GitHub · Spec · Schema

AI is getting frighteningly good at the craft of design.

It can generate screens, flows, copy, research summaries, usability findings, and recommendations on what to fix next. For many teams, this feels like progress. For some, it feels like relief. But there's a trap here.

While AI can execute the work, there's one thing it cannot do reliably. And it happens to be the thing that quietly drives everything else.

AI can generate assumptions. It cannot tell you which ones are real, which ones are risky, or which ones are worth betting the company on.

That distinction matters more than most teams realise.

The cost of wrong beliefs

Design doesn't start with solutions; it starts with beliefs. Every product is built on a foundation of assumptions, whether we name them or not. We assume "this is a real problem," or "this is who we're designing for," or "this trade-off is acceptable."

If those foundational assumptions are wrong, speed doesn't help you. It just gets you to the wrong place faster.

Quibi raised $1.75 billion on the assumption that people wanted premium short-form video for their commutes. The execution was polished. The technology worked. The assumption was wrong. They shut down in six months.

Most product failures aren't execution failures. They're assumption failures. And no amount of craft can rescue a flawed premise.

The design flywheel

Think of design as a flywheel: Assumptions → Questions → Research → Insights → Decisions → (back to) Assumptions.

Each rotation should build momentum. Good assumptions lead to sharper questions, which produce more useful insights, which inform better decisions, which refine your assumptions for the next pass. The flywheel accelerates.

AI is excellent at the middle of this cycle. It can execute research, synthesise data, and spot patterns faster than we can. But assumptions sit above the flywheel. They determine what questions get asked in the first place, what data gets considered relevant, which patterns get flagged as significant.

If your starting assumptions are flawed, everything downstream inherits that flaw, and each rotation compounds the error. The flywheel spins faster, but in the wrong direction.

You cannot automate your way out of a bad premise.

Likelihood vs. consequence

Here's the part that catches teams off guard: AI is actually very good at generating assumptions. Give it enough context, and it will produce a list of plausible beliefs about your users, your market, your product.

But AI works from precedent. It optimises for likelihood, not consequence.

It can tell you what is probable. It cannot tell you what is load-bearing.

This is where AI research tools can quietly mislead you. When they surface "opportunities," they're optimizing for likelihood, what the data suggests is probable. But calling something an opportunity isn't neutral. It's a judgment. You're assuming it's desirable, that it aligns with your goals, that it's worth the trade-offs.

AI can surface potential paths. It cannot decide which ones should exist. Treat AI-generated "opportunities" as hypotheses, not facts. The decision about what matters, what's worth pursuing, belongs to humans.

Assumptions are judgment calls. They require someone to look at a belief and ask, "If this is wrong, what breaks?" AI can't answer that responsibly because it doesn't have to live with the fallout.

The assumption landscape

And the landscape is broader than most teams realise. Products don't fail because of one bad guess. They fail because of unexamined beliefs across multiple dimensions:

Each of these is a load-bearing belief. Get any of them wrong, and the product wobbles. Get several wrong, and it collapses.

AI can generate plausible answers for all of these. But it cannot tell you which ones deserve scrutiny, which ones carry the most risk, or which ones are quietly undermining everything else. That judgment, the meta-judgment of where to focus your doubt, remains human work.

Assumption guardians

This is why designers and researchers are being pushed upstream.

Execution has become cheap. Screens, components, summaries, even usability findings. None of these are scarce anymore. The center of value has moved. As I wrote in AI ate the design process, what remains valuable is judgment, the ability to know what's worth making.

Designers are shifting towards service design: thinking about full journeys, incentives, and systems rather than just interactions. Researchers are moving into strategic sense-making: not just "what did users say?" but "what should we believe, and how confident should we be?"

This isn't a career pivot for its own sake. It's a response to where the bottleneck has moved. Execution has been automated. Judgment hasn't.

Designers and researchers aren't just makers anymore. They're assumption guardians, the people who protect the product from false certainty. Who surface beliefs deliberately, name them explicitly, frame them as testable bets (the formal term is hypothesis), and own the consequences.

Don't automate the risk

By all means, automate the analysis, the synthesis, the documentation. Let AI handle the middle of the flywheel.

But assumptions must be surfaced deliberately, named explicitly, and owned by humans.

If your role is defined purely by execution, AI will outpace you. But if your role is defined by framing the right problem and owning the decisions that follow, you just became more important, not less.

AI is a velocity tool, not a navigation tool.

Don't hand over the steering wheel.

The problem with AI-generated interfaces

Here's a question I've been wrestling with: if AI is going to help us build interfaces, how do we make sure it builds good ones?

Not just functional. Not just following a prompt. Actually good. The kind that respects how humans perceive, think, and make mistakes.

AI tools are remarkable at generating code. Ask Claude or Cursor to build you a form, and you'll get something that works. Inputs render. Buttons click. Data submits.

But will it validate before the user hits submit? Will it preserve their input when something goes wrong? Will the error messages actually tell them what to fix?

Often not. And it's not because AI hasn't been trained on usability principles—it has. Nielsen's heuristics are all over the internet. The problem is that training data and active context are different things.

When Claude generates a form, it's not systematically consulting usability principles. It's pattern-matching against what it's seen. Sometimes that produces good UX. Sometimes it doesn't. The knowledge exists in the model, but it's not being deliberately applied at build time.

So I built something to change that.

Human Standards: what it is

This week I launched Human Standards.

Human Standards is an open reference that translates decades of human factors research into practical design guidance. It covers cognition (how people think), perception (how they see, hear, and touch), decision-making (how they choose and err), and implementation (code examples, design tokens, checklists).

Every recommendation is grounded in research. Not "best practices" that someone decided were best; actual studies, actual data. TurboTax reduced form completion time by 30% using progressive disclosure. Gmail's undo-send feature cut accidental email anxiety by 38%. BBC achieved 98% keyboard navigation success rates.

The site is structured so you can go deep on topics like cognitive load, error prevention, or WCAG compliance. Or you can grab a checklist and run.

But here's the part I'm most excited about.

The MCP server: AI that can look things up

Human Standards includes an MCP (Model Context Protocol) server that gives Claude real-time access to usability heuristics and the full documentation.

Think of it this way: the MCP is the reference book; the AI is the practitioner flipping it open mid-project.

When you ask Claude to build a registration form, it now has access to three tools:

• get_heuristic — deep dive on a specific Nielsen heuristic (H1-H10)
• get_all_heuristics — quick summary of all 10
• search_standards — search the full Human Standards documentation

So when Claude builds your form, it can check which principles apply. Error prevention? That's H5—use confirmation for destructive actions, validate before submission. Error recovery? That's H9—preserve user input, show specific and actionable messages.

It's not hoping the right patterns surface from training. It's deliberately consulting a reference at the moment it matters—the way a designer would flip open a book mid-project.

The philosophy behind this

I've spent the past year thinking about how AI changes design work. My conclusion: AI has commoditised execution but amplified the value of judgment.

Anyone can generate a wireframe now. Anyone can get working code in seconds. The hard part isn't making something—it's knowing what's worth making, and whether it actually works for humans.

Human Standards encodes that judgment. Not as rules that AI blindly follows, but as principles it can query when relevant. The AI still decides when to look something up. It still synthesises the guidance with the specific context of your project.

That's the equilibrium I've been writing about. AI doing more of the execution. Humans (and human knowledge) shaping what gets executed.

Why I built this

Honestly? Because I kept seeing the same problems.

AI-generated interfaces with no loading states. Forms that fail silently. Navigation that assumes users memorise your information architecture. The patterns are predictable because they're all missing the same thing: grounding in how humans actually work.

I wanted a resource that designers could use to learn and contribute, and that AI could use to build (and perhaps contribute one day?). Same knowledge, two audiences.

The site is open source. The MCP server is free to use. I'll keep adding to both.

Try it

If you're using Claude Desktop or Claude Code, you can add the MCP server in a few minutes:

git clone https://github.com/aklodhi98/humanstandards.git
cd humanstandards/human-standards-mcp
npm install && npm run build && npm run index-docs

Then add it to your Claude config and restart. Full instructions are on the MCP Server page.

Or just browse the standards at humanstandards.org. Whether you're building interfaces yourself or delegating to AI, the principles are the same.

What's next

Digital interfaces are just the start.

The underlying principles—cognitive load, feedback loops, accessibility—apply across all human-technology interaction. But implementation changes depending on the medium.

Future phases include voice and conversational UI, VR/AR, robotics, IoT, wearables, and automotive HMI. Each domain needs its own documentation, examples, and MCP validation rules.

That's a lot of work. Which brings me to...

How to contribute

Human Standards is open source under CC BY-NC-SA 4.0 (content) and MIT (code).

You can help by:

• Fixing typos and errors (low effort, high impact)
• Adding citations to strengthen claims
• Writing new pages for uncovered topics
• Improving the MCP server
• Building validation tools

The contribution guide covers style guidelines, evidence standards, and the review process.

If you have domain expertise in voice interfaces, VR/AR, robotics, or any of the roadmap areas, I'd particularly love your help.

Because good design shouldn't depend on what AI remembers from training data. Give it a library to consult, and it gets it right the first time.

What do you think? Have you tried integrating external design knowledge into AI workflows? I'd love to hear what's working. Find me on LinkedIn.

By the time you've finished your coffee, AI has already completed the warm-up exercises: user journeys, wireframes and workflows, even research synthesis. Things like the double diamond, artefacts, and the 'Sprint' method? All done for you. This is what AI executes now, faster and cheaper than any human team. If your value was in producing these artefacts, that value just got commoditised.

The process was never the value

Here's the uncomfortable truth: following steps never produced great design. The double diamond didn't create Linear. Sprint workshops didn't birth Notion Calendar. No amount of affinity mapping made anyone fall in love with a product. "Trust the process" was always incomplete advice. It suggested that rigour alone would deliver quality. It doesn't. It delivers artefacts. Now that AI can deliver those same artefacts, the advice isn't just incomplete. It's outdated.

Production is no longer the constraint

We can generate infinite screens, flows, variants, and experiments. Software ships in hours, not months. Companies like Cursor push updates daily. The feedback loop between idea and implementation has collapsed to almost nothing. This is genuinely new. For decades, production was the bottleneck. Teams existed to ship. Designers existed to help teams ship. The whole apparatus was oriented around getting things out the door. That constraint is gone.

The bottleneck moved to humans

Here's what didn't scale: attention, cognition, and decision-making. The human at the end of the process is the same human who was there before AI ate everything. Same mental bandwidth. Same capacity for choice. Same tendency to feel overwhelmed when presented with too much. Infinite options are not a gift. They're a burden. You've felt this yourself. GPT asks which of two responses you prefer. Seems reasonable. But actually comparing them, reading both carefully, weighing trade-offs, making a judgment, is a significant cognitive task. Most of the time, you just pick one and move on. Now multiply that by every product, every feature, every micro-decision in a user's day. The bottleneck isn't production anymore. It's the human capacity to absorb what gets produced.

Someone has to choose before users do

If everything ships, nothing lands. When you can generate infinite variations, the question stops being "can we build this?" and becomes "should this exist?" That's a filtering problem, not a production problem. Value now comes from deciding what reaches users, not from the act of making it.

That filtering is taste

Jenny Wen, the design lead at Anthropic, puts it this way:

"In a world where anyone can make anything, what matters is your ability to choose and curate what you make." That ability to choose and curate, knowing what's worth building, what's worth pursuing, what's worth a user's attention, is taste. It's not a soft skill. It's the hard skill now.

Taste comes before skill, and creates the first gap

Ira Glass has this famous bit about creative work. People get into creative fields because they have taste. They recognise good work. That's what draws them in. But there's a gap. For the first few years, your taste exceeds your ability. You can see what good looks like, but you can't make it. This is painful. Most people quit here. The ones who push through eventually close the gap. Their skill catches up to their taste. This is the skill–taste gap: what I can make versus what I know is good.

AI narrows the skill gap

Here, AI helps. You can execute faster. Iterate more. Finish more work. See your mistakes sooner. If you use it well, AI compresses years of learning into months. The reps that once required a decade of client work can happen in a fraction of the time. AI is a time-compression engine for the painful-but-necessary "years of bad work" phase. It helps your skill catch up to your taste, if you're actively choosing, shipping, and reflecting.

But there's a second gap, and AI widens it

This one's different. The option–judgment gap: how many things can be made versus how many things a human can meaningfully evaluate. Generation scales exponentially. Judgment does not. AI can produce a hundred variations before lunch. You cannot thoughtfully evaluate a hundred variations before lunch. No one can. Choice overload increases. Deciding becomes harder, not easier. The more options that exist, the more expensive each act of judgment becomes. This is the bottleneck shift. Not skill anymore. Judgment.

Two gaps, opposite directions

AI narrows the first gap: your skill catches up to your taste faster. AI widens the second gap: more options exist than any human can evaluate. The paradox designers now live inside: it's easier than ever to make things, and harder than ever to know which things should exist. Both gaps demand taste. But they demand it differently. One to recognise quality in your own work, the other to filter quality from infinite possibilities.

Taste looks like heresy to process culture

If you've been trained in orthodox design methods, taste can feel transgressive. Jenny Wen again, on how great design actually gets made:

• Starting with a solution, not a problem
• Iterating for quality endlessly, long past "good enough"
• Operating on intuition. Not guessing, but making reasoned judgments quickly
• Skipping steps and making them up as you go
• Working backwards from a vision
• Doing something just to make people smile None of this fits neatly into a sprint. None of it survives a "show your research" culture. Great design routinely violates orthodox advice. That's not a bug. It's the signature of taste in action.

Designers become human proxies

Your job is no longer to generate options. AI does that. Your job is to decide on behalf of users who can't evaluate infinite ones. Think about what that means. You're a proxy, standing in for people who don't have the time, bandwidth, or expertise to sift through everything that could exist. You exercise judgment so they don't have to. Proxy for whom? Users who are already overwhelmed. Proxy doing what? Filtering the infinite down to the meaningful. This is the new job. Not production. Protection.

Skills are table stakes. Taste is the differentiator.

Execution is assumed now. Anyone with AI access can produce. What's scarce is the judgment to know what's worth producing. The conviction to ship one thing instead of ten. The instinct for what will land. Skills get you in the room. Taste is why you stay.

So develop taste deliberately

This isn't about consuming more design inspiration. Dribbble won't save you. Taste develops through committed practice: Choose. Make decisions with incomplete information. Don't defer to data when your gut has something to say. Commit. Ship the version you believe in, not the version that survives committee. Defend. Have opinions strong enough to argue for. If you can't articulate why something should exist, you haven't developed taste. You've developed preferences. Repeat. Taste sharpens through reps. Every choice you make, ship, and observe is a data point. The feedback loop is yours to accelerate. Expose yourself to great work, yes. But more importantly, practice conviction. Taste isn't just knowing good when you see it. It's having the nerve to insist on it.

The design process got eaten. Good.

It was never the point anyway. What remains is the thing that mattered all along: the human judgment to know what's worth making, and the conviction to make it well. That's taste. And it's more valuable now than ever.

But is any of this true? Does saying "please" actually get you better outputs? And what happens if you're actively rude? Existing research has explored this question, and some studies even suggest that rudeness can improve performance, though critics note that the findings were based on a single model (GPT-4o).

I ran 625 API calls across five frontier models to find out for myself. The results surprised me.

The setup: A spectrum from groveling to growling

I designed a simple experiment. Five tasks covering the full range of what we ask LLMs to do:

For each task, I wrote five versions of the prompt, ranging from "aggressively rude" to "embarrassingly grateful":

Then I threw all of this at five frontier models:

• Claude Sonnet 4.5 (Anthropic)
• GPT-5.2 (OpenAI)
• Gemini 3 Flash (Google)
• DeepSeek 3.2 (DeepSeek)
• Kimi-k2 (Moonshot)

Each prompt ran 5 times at temperature=0.0 for consistency. That's 5 tasks × 5 tiers × 5 runs × 5 models = 625 responses.

The secret sauce: Blind cross-scoring

Here's where it gets interesting. I needed to score all these responses, but having Claude grade Claude's homework felt... biased.

So I set up a model rotation. GPT-5.2 scored Claude's responses. Claude scored GPT's responses. And crucially, the scoring model never knew which "tier" (hostile, polite, etc.) the response came from. It just saw raw text.

No peeking. No favoritism. Just vibes.

The results: Four things I didn't expect

1. Some models are emotional chameleons. Others are stone cold.

The first thing I wanted to know: do these models mirror your tone?

Turns out, it depends entirely on the model.

The takeaway: If you want a warm, conversational response, Claude will play along. If you want the AI equivalent of "new phone, who dis," try Gemini.

2. GPT-5.2 has a "politeness tax"

Here's where things got weird.

Most models gave consistent effort regardless of how I asked. Gemini and Kimi maintained a rock-solid effort score whether I was begging or barking.

But GPT-5.2? It punished rudeness.

Being rude to GPT-5.2 cut my response length by 75% and dropped effort scores. It's like the model took my hostility personally.

If you're using GPT, be nice. Seriously.

3. The "politeness paradox": Extreme tones spark better creativity

This one broke my brain.

I fully expected that polite prompts would produce the best creative writing. Happy writer = happy prose, right?

Wrong.

When I analyzed the creative tasks specifically, the data showed that Hostile and Effusive prompts both outperformed Polite ones on imagery and originality:

What's going on? My theory: intensity (whether positive or negative) pushes the model out of "helpful assistant" mode and into a more vivid, persona-driven headspace. Standard politeness triggers the "professional template," which is... safer. Blander.

If you want creative fire, bring the heat. In either direction.

4. The surprise creative champion: Kimi-k2

Of all the models tested, Kimi-k2 dominated the creative quality metrics:

• 5.0 out of 5.0 for Imagery
• 5.0 out of 5.0 for Craftsmanship
• Highest emotional impact scores

I did not see this coming. Kimi is the dark horse of frontier models, and if you're writing fiction or building immersive worlds, it's worth a look.

So what should you actually do?

If you're writing code or technical docs:

Just be direct. Politeness adds length but not quality. A terse "write a function that..." works fine.

If you're doing creative work:

Go big or go home. Either be effusively grateful or adopt a demanding persona. The middle ground (polite but measured) produces the most generic outputs.

If you're using GPT:

Seriously, be nice. It's the only model that measurably punishes rudeness with lower effort.

If you want consistent output regardless of mood:

Use Gemini. It genuinely does not care about your feelings.

The nerdy details (methodology)

For the skeptics:

• Deterministic outputs: All runs used temperature=0.0
• Blind scoring: Scorer models never saw tier labels
• Cross-model rotation: No model graded its own outputs
• N=5 per condition: 625 total samples for statistical robustness. Why five runs per prompt? Even at temperature=0.0, LLM outputs aren't perfectly deterministic. Subtle variations in tokenization, floating-point arithmetic, and server-side caching can produce slightly different responses. Running each prompt five times lets me average out these micro-fluctuations and capture the model's "true" baseline behaviour rather than a lucky (or unlucky) one-off.

Full dataset and analysis scripts are on GitHub.

The bottom line

After 625 API calls and more spreadsheets than I care to admit, here's what I can tell you:

Politeness doesn't make AI try harder. Not in any statistically meaningful way.

What does matter:

• The model you choose (they have very different personalities)
• Intensity of framing (for creative tasks, passion beats politesse)
• GPT specifically (where rudeness costs you)

So keep saying "please" if it makes you feel like a good person. Just know that for most models, it's not unlocking any secret capabilities.

The real magic words? Clarity. Specificity. And maybe a little existential urgency.

If you recognised your organisation in that piece, you're probably wondering: how do we get out?

Here's the uncomfortable truth I've learned from studying the organisations that actually escaped FaUX—from government digital services to Silicon Valley to legacy enterprises: Real UX doesn't come from better methodologies or more passionate designers. It comes from enforcement mechanisms that make user research non-negotiable.

The difference between FaUX and RUX isn't intention. Everyone intends to be user-centered. The difference is accountability.

The enforcement problem

Most organisations practicing FaUX already have the right tools. They have design systems. They have research repositories. They have journey maps collecting dust in Confluence. They might even have a Service Design team.

What they don't have is consequences.

When user research can be skipped because of timeline pressure, it will be skipped. When UX recommendations can be overridden by executive preference, they will be overridden. When workshops can produce outputs that no one is obligated to act on, no one will act on them.

The organisations that practice Real UX have solved this problem structurally. Not culturally. Structurally.

How organisations actually escaped FaUX

The escape routes look different depending on context, but they share a common thread: tying UX to something the organisation already cares about—money, risk, or reputation.

In government: tying UX to funding gates

The UK Government Digital Service's most important innovation wasn't their design principles or their pattern library. It was this: service assessments became a condition of Cabinet Office spend approval.

Teams cannot get funding to proceed without demonstrating genuine user research. Four-hour assessment sessions with specialist panels produce ratings for each of their 14 service standards. Reports are published publicly.

Suddenly, "we didn't have time for research" stops being an acceptable answer. Because no research means no money.

The US followed with the 21st Century IDEA Act, legally mandating that federal digital services be accessible, consistent, and user-centered through "qualitative and quantitative data-driven analysis." Not guidelines. Law.

Australia took a similar path. The Digital Transformation Agency introduced its own Digital Service Standard, with Version 2.0 becoming mandatory for all new government services from July 2024. Criterion 2—"Know your user"—requires agencies to conduct regular user research, test designs with diverse user groups, and demonstrate validated solutions at each phase. Services with more than 50,000 transactions per year face DTA assessment.

I've seen this work firsthand. Working as a UX designer on myGov at Services Australia, I watched research-driven changes move the needle on real outcomes. One example: allowing users to sign in with their email address instead of a system-generated username reduced failed login attempts by 37%. That's not a design flourish—it's friction removed because someone studied where users were getting stuck. The $630 million investment announced in the 2024–25 Budget signals that this isn't a one-off commitment; it's sustained investment in getting government services right.

In enterprise: tying UX to executive accountability

IBM's transformation took a different route. They invested $100 million to hire 1,000 designers and train 100,000 employees in Enterprise Design Thinking. But the money wasn't the key—the structural change was.

They introduced "The Loop" (Observe, Reflect, Make) as a mandatory governance process, not an optional workshop. They embedded designers into engineering squads at ratios of 1:8. Forrester found this reduced development time by 33% and doubled project ROI.

The lesson: IBM didn't just add designers. They changed how decisions got made and who was in the room when they happened.

Intuit took a similar approach with "Design for Delight," but went further by creating a corps of "Innovation Catalysts"—employees from Finance, HR, Engineering, and other functions trained to coach teams in customer empathy methods. UX stopped being something the design team did; it became something everyone was accountable for.

Atlassian, the Sydney-founded collaboration software company, built research into its operating model from early on. They embed UX researchers directly into product teams—not as a shared service you book time with, but as permanent members of the squad. Their internal research panel, the "Atlassian Research Group," includes over 50,000 customers, making participant recruitment a solved problem rather than a three-week ordeal. They run a dedicated research facility called "Atlab" for in-depth studies. The result: research becomes as routine as sprint planning, not a special event that requires executive sign-off.

In startups: building it into the DNA before there's a culture to change

Airbnb's founders were designers who understood something most startups miss: the product is the experience.

When they were struggling for traction, they didn't hire a growth hacker. They flew to New York, stayed with hosts, and observed the friction firsthand. They discovered the core problem wasn't the booking flow—it was trust. That insight led to professional photography services and the peer review system that unlocked a billion-dollar market.

The advantage startups have: no legacy culture to overcome. The risk: if you don't embed user-centered practices early, you'll be trying to retrofit them later when you're bigger and it's harder.

The four shifts from FaUX to RUX

Whatever your sector, the shift from Fake UX to Real UX requires the same fundamental changes. The implementation differs; the principles don't.

Shift 1: from outputs to outcomes

FaUX measures success by what was produced: features shipped, designs delivered, research reports written.

RUX measures success by what changed: task completion improved, support calls reduced, user satisfaction increased, time-to-completion shortened.

In government: The UK established four mandatory KPIs that all digital services must measure and publish: cost per transaction, user satisfaction, completion rate, and digital take-up. These are published on public dashboards where anyone—including journalists, auditors, and Parliament—can see them. When your completion rate is 34% and it's public, you can't pretend everything is fine.

In enterprise: McKinsey's Business Value of Design study found that companies in the top quartile of their Design Index achieved 32% higher revenue growth and 56% higher shareholder returns than industry peers. The top performers tracked design metrics with the same rigor as financial metrics—not as vanity dashboards, but tied to executive accountability.

In startups: The equivalent is being ruthless about whether features actually move the metrics you claim to care about. Most startups ship features and never look back. The ones that escape FaUX track adoption, retention impact, and task success for everything they ship—and kill features that don't perform.

The practical shift: Stop roadmaps that promise features. Start roadmaps that promise outcomes. Instead of "Build chatbot (Q3)," commit to "Reduce support ticket volume by 20% (Q3)." This gives the team license to discover the right solution—which might not be a chatbot at all.

Shift 2: from validation to discovery

FaUX uses research to validate decisions that have already been made. "We tested it and users liked it" (after we'd already committed to building it and couldn't change course anyway).

RUX uses research to discover what to build in the first place. The decision about what to build comes after understanding the problem, not before.

In government: The UK Service Standard requires teams to demonstrate research at Alpha, Beta, and Live phases—with independent assessments at each gate. You can't start building (Beta) without proving you understood the problem (Alpha). This kills the most common FaUX pattern: bringing designers in after the solution has already been determined.

In enterprise: Teresa Torres's Continuous Discovery framework has gained traction precisely because it makes research sustainable at corporate scale. The core habit: the product trio (PM, designer, engineer) talks to at least one user every week. Not quarterly "big bang" research projects. Weekly conversations that make research a routine habit, like standups or code reviews.

In startups: The "Wizard of Oz" and "Fake Door" tests let you validate demand with zero engineering time. Put a button on the site that says "New Feature." If users click it, show a "Coming Soon" message and count the clicks. You've just validated (or invalidated) demand in an afternoon instead of a sprint.

The practical shift: Block one hour per week for direct user contact. Automate recruitment through in-app intercepts or drip campaigns. Make it a team habit, not a special event requiring three weeks of planning.

Shift 3: from consensus to evidence

FaUX resolves disagreements through opinion, seniority, or politics. The HIPPO (Highest Paid Person's Opinion) wins. Dot-voting in workshops determines direction based on who's in the room, not what users actually need.

RUX resolves disagreements through evidence. "Let's test it" becomes the default response to conflicting opinions.

Across all sectors: This requires creating psychological safety around being wrong. In a RUX culture, proving that an executive's pet idea doesn't work is celebrated—you just saved the organisation months of wasted effort. In a FaUX culture, that same finding gets buried because no one wants to be the messenger.

Amazon's "two-way door" framework helps here. Two-way doors are reversible decisions (button color, copy)—just ship and measure. One-way doors are irreversible decisions (core pricing model, platform architecture)—do rigorous research first. Not everything needs the same level of validation.

The practical shift: When someone proposes a solution, respond with "That's an interesting hypothesis. What's the fastest way we could test it?" Frame ideas as bets to be validated, not decisions to be defended. And when you test an executive's idea against alternatives, present results in terms of their goals: "We tested your idea against Alternative B. Your idea had 5% conversion; B had 15%. We recommend B to maximise your goal of increasing revenue."

Shift 4: from isolated function to integrated practice

FaUX treats UX as a service bureau. Product and engineering request designs; designers deliver them. Research is something the research team does, separate from delivery.

RUX embeds UX into cross-functional teams where product, design, and engineering work together throughout. Designers aren't downstream of decisions—they're in the room when decisions are made.

In government: The UK GDS achieved this by requiring multidisciplinary teams as a service standard. You literally cannot pass assessment without demonstrating that your team includes the right disciplines working together.

In enterprise: Spotify's squad model (for all its complications) got this right: small cross-functional teams with product, design, and engineering working on shared outcomes. The design system enables consistency without requiring centralised control of every decision.

In startups: You don't have the luxury of silos anyway. The risk is the opposite—design getting swallowed by engineering priorities because there's no structural protection for research time.

The practical shift: If your designers are receiving tickets that say "mock up this screen" rather than "help us solve this problem," you have a structural issue. Reorganise around problems, not functions.

The kill rate: a metric that signals real UX

Here's a counterintuitive indicator of UX maturity: how many ideas did you kill before writing code?

In FaUX organisations, every idea gets built. The backlog grows endlessly. Features ship regardless of whether research supported them.

In RUX organisations, the funnel is wide at the top (lots of ideas explored) and narrow at the bottom (few make it to development). A healthy discovery process should eliminate most ideas before they consume engineering resources.

If your organisation builds everything that gets proposed, you're not doing discovery. You're doing order-taking dressed up in design thinking language.

Track your kill rate. Celebrate the ideas that got invalidated early. Every killed idea is money and time saved—50% of developer time is estimated to be spent on rework that could have been avoided with earlier validation.

The ROI argument (because you'll need it)

Talking about user needs doesn't move budgets. Talking about money does.

The revenue case: McKinsey found top-quartile design performers achieve 32% higher revenue growth. Forrester found experience-led businesses have 1.6x higher brand awareness and 1.5x higher employee satisfaction.

The cost case: Every dollar invested in UX returns roughly $100 in value, primarily through avoided rework. Fixing a UX error after development is up to 100 times more expensive than fixing it during design. UK government data shows online transactions cost £0.22 versus £6.62 by post—channel shift driven by good UX pays for itself.

The retention case: 88% of users are unlikely to return after a bad experience. Better UX increases willingness to pay by 14.4%. One SaaS platform reduced support requests by 40% through UX improvements, directly impacting operating margins.

These numbers aren't arguments for "nice to have." They're arguments for fiduciary responsibility.

When the law says one thing and users need another

For those of us in government or regulated industries, there's a tension that private sector UX rarely confronts: what happens when legislation requires something that creates friction for users?

This isn't hypothetical. Government services are built on legislation and regulation. The policy intent—what government wants to achieve—is often codified in law before any designer touches the project. You can't just ignore it because users find it inconvenient.

But here's what I've learned from studying how the best government teams handle this: the answer isn't compromise. Settling in the middle doesn't help anybody.

Understanding policy intent before you design

The UK Government Service Manual is explicit about this: service teams need a clear understanding of what government wants to change or achieve through its policies before they start designing. This means understanding:

• What outcome the policy was designed to deliver
• Who will be affected
• How success will be measured
• What related policies, regulations, and contractual commitments apply

If you skip this step and design purely based on user research, you'll build something that doesn't reflect the policy at all. And it won't ship.

But here's the crucial insight: policy intent is not the same as current implementation. The legislation might require identity verification, but it doesn't mandate a specific clunky process. The regulation might require certain information to be collected, but it doesn't specify that users must enter it three times across four forms.

The best service designers distinguish between what the law actually requires and what current systems have layered on top.

Creating feedback loops from delivery to policy

The UK Department for Education developed a technique called "impact mapping with user value." Standard impact mapping moves from desired impacts straight to activities and features. They added an extra stage—value to users—so they could see user needs alongside policy intent.

This matters because it surfaces conflicts early. If the policy intent and user needs are fundamentally misaligned, that's information the policy team needs to hear.

And here's where Real UX differs from Fake UX: in RUX organisations, user research actually feeds back into policy design.

One example from Nava, a US civic tech consultancy: they were implementing an unemployment insurance system where policy required beneficiaries to recertify their wages weekly—even when their benefit amount never changed. User research revealed this was burdensome for people already dealing with tough situations: injury, illness, new babies. The designers didn't just implement the requirement and move on. They documented the user impact and suggested the state simplify the policy. That suggestion was ultimately reflected in finalized regulations.

This is the difference between service design and screen design. Service design works "from front to back"—not just the user-facing interface, but the internal processes, supporting policy, and organisational structures. If your user research never influences anything upstream, you're not doing service design. You're decorating.

The practical approach

When you're working within legislative constraints:

Map policy provisions across the service blueprint. Identify exactly which requirements come from legislation versus inherited process versus "we've always done it this way." You'd be surprised how much friction comes from the third category.

Distinguish between policy intent and policy implementation. The intent might be "verify identity"; the implementation is a specific process. You often have more flexibility than you think in how to achieve the intent.

Document user pain points that stem from policy, not just UI. This creates the evidence base for policy feedback. If you never surface these issues, they'll never get fixed.

Build relationships with policy teams. As one UK Chief Digital Officer put it: "The service designer has to be able to start to talk policy and policy has to be able to start to talk service design." If you can't explain why a policy requirement is creating user harm, you can't influence it.

Accept that some friction is intentional. Not all user friction is bad. Sometimes legislation deliberately creates barriers—for fraud prevention, safety, or equity reasons. Your job is to understand which friction is intentional and which is accidental, then eliminate the accidental kind.

The goal isn't to override policy with user preferences. It's to ensure policy achieves its intent while serving users well. Those aren't always in conflict—but when they are, the conflict needs to be surfaced, not buried.

What to do if you're stuck in FaUX

Let's be honest: most of us can't wave a wand and restructure our organisations. We don't control funding gates or executive priorities. We're practitioners trying to do good work within systems that weren't designed for it.

Some practical tactics:

Start with one team. Pick a project with sympathetic leadership. Apply rigorous discovery practices. Document everything—especially the money saved by killing bad ideas early. Use this as proof of concept for broader change.

Make the cost of FaUX visible. Track how much rework could have been avoided with earlier research. Calculate the support costs generated by usability issues. Put numbers to the pain.

Build coalitions. Find allies in product management, engineering, and leadership who understand the problem. Change doesn't happen through design teams alone.

Use data as a shield. When HIPPO pushes back on research findings, frame your response in terms of their goals and with data they can't dismiss.

Time-box everything. The "we don't have time" objection is perennial. Counter it with: "It takes two weeks to build this and two days to test a prototype. If we build it wrong, we waste two weeks plus rework. If we test it and it fails, we save two weeks. Research is an accelerator, not a tax."

And sometimes, honestly, the answer is: find an organisation that gets it. Life is too short to spend your career decorating decisions you had no part in making.

The uncomfortable truth about transformation

Here's something the case studies don't emphasise enough: crisis is often what creates the conditions for change.

Healthcare.gov's catastrophic failure—6 enrollments on launch day—created the political mandate for the US Digital Service. The embarrassment of 2,000 disjointed UK government websites enabled GOV.UK's radical consolidation. IBM's commoditisation crisis justified a $100 million design investment. Airbnb's existential early struggles forced the founders to get on planes and actually meet their users.

If your organisation is stuck in FaUX and comfortable, it may stay stuck. Visible failure generates the urgency that comfortable mediocrity never will.

I'm not suggesting you sabotage projects. I am suggesting that if you're waiting for leadership to spontaneously prioritise user-centered design without external pressure, you may be waiting a long time.

What RUX actually looks like

Real UX isn't a utopia where every recommendation gets implemented and executives defer to research.

It's a system where:

• User research is a prerequisite for decisions, not a post-hoc justification
• UX outcomes are measured, published, and tied to accountability
• Designers have seats at tables where strategy is set, not just execution
• Bad ideas get killed early, and the killing is celebrated
• Cross-functional teams own problems together rather than passing artifacts over walls
• Compliance requirements are integrated into practice, not bolted on at the end
• Research findings feed back into policy and process, not just interface design

Getting there requires structural change, not just cultural aspiration. It requires tying UX to the things organisations actually care about: money, risk, and public accountability.

The organisations that escaped FaUX didn't do it by wanting it more. They did it by building systems that made Real UX the path of least resistance.

This is Part II of the FaUX series. Part I diagnosed the problem; this piece outlined the path out. What's your organisation's biggest barrier to Real UX? I'd like to hear about it—find me on X or LinkedIn.

And yet.

Something's off. Despite all this UX maturity, users still encounter baffling experiences daily. Designers burn out at alarming rates. Research findings gather dust. The gap between what organisations say about their commitment to users and what they actually ship has never felt wider.

I have a name for this phenomenon: FaUX — Fake UX.

FaUX is what happens when organisations adopt the aesthetics of user-centered design without the accountability. The rituals exist. The job titles exist. The workshops happen. But the feedback loop between understanding users and actually serving them better? Broken.

The anatomy of FaUX

FaUX manifests in predictable patterns. You'll recognise them immediately—either from your own organisation or from products you've had the misfortune of using.

Process theatre

This is FaUX at its most visible: the performance of user-centered design without the substance.

Fakeshops. Workshops conducted with full zeal and zest. Sticky notes flying around, everyone clutching multiple Sharpies, Miro boards so dense you'd need to zoom for an hour to parse them. Great energy. Impressive documentation. Outcomes that are "ready for action." Except no action is ever taken. The documents slide into a void where no one looks at them again. A few weeks later, you repeat the entire exercise.

Checkbox research. Running a single usability test so someone can write "validated with users" in a slide deck. The findings don't influence anything. They weren't meant to. The research existed to satisfy a process requirement, not to generate insight.

Fake validation. Executives referencing their conference keynotes or webinar Q&As as "talking to users." Internal demos to colleagues framed as user testing. Confirmation bias dressed up as discovery.

Synthetic user dependency. Using AI-generated personas or simulated user responses as a substitute for actual human research. As I've written before, AI cannot replicate the emotional richness, contradictions, and contextual messiness of real human beings. Synthetic users give you synthetic insights.

Structural disempowerment

This is FaUX embedded in how organisations are built. The designers exist, but they've been architecturally prevented from influencing outcomes.

The decorative UX function. A UX team that's there for show. Their work carries no weight. No one with decision-making authority pays attention to their recommendations. They're a line item that makes the org chart look modern.

Post-decision design. Designers brought in after the solution has already been determined by others. Their job isn't to solve problems—it's to make predetermined solutions look presentable. Painting by numbers into an already laid-out canvas.

Proximity without influence. UX positioned so close to development that there's literally no scope to change anything substantive. The role has been reduced to producing high-fidelity wireframes on a timeline that permits no iteration.

The HIPPO effect. Highest Paid Person's Opinion. In the review meeting, an executive says, "I don't like blue, and I think users want a dashboard," despite data proving otherwise. The team pivots to please the executive. Research becomes decoration; intuition (of the powerful) becomes strategy.

Surface-level craft

This is FaUX disguised as quality. The work looks impressive but misses the point entirely.

Pixel perfection, zero usability. Interfaces polished to a gleaming shine, with no attention paid to whether humans can actually use them. Aesthetic refinement as a substitute for functional design. As I've explored in reducing cognitive load for usability, real usability is about making things easier to process, not prettier to look at.

Lipstick on a pig. Beautifully designed forms connecting to a fundamentally broken service experience. The UI is gorgeous; the underlying journey is a nightmare. The design team has optimised the visible 10% while the invisible 90% remains hostile to users.

Metrics theatre. Tracking NPS, CSAT, or satisfaction scores that leadership celebrates in good quarters and conveniently ignores when they decline. Measurement without accountability. Dashboards that exist to provide comfort, not insight.

The infinite backlog

FaUX has a favourite graveyard: the product backlog.

UX recommendations get "prioritised"—which means they're added to a list where they'll sit indefinitely behind revenue features and technical debt. The research was done. The insights were documented. The recommendations were made. They're just never going to be implemented.

Discovery without delivery. Months of research, zero shipped improvements. The organisation can claim it invested in understanding users while conveniently never acting on that understanding.

The FaUX diagnostic: How to know if you're practicing it

Here's a self-assessment. Be honest with yourself.

1. Trace your last three research studies. How many findings were implemented? If the answer is less than half, you might have a FaUX problem. If you can't even locate the findings, you definitely do.

2. When was the last time UX research changed a significant product decision? Not refined a decision. Changed it. If you can't point to a concrete example in the past year, your research function may be decorative. Remember: users are fickle, but their whys are not—if you're not uncovering and acting on those whys, you're doing FaUX.

3. Where does UX sit in your decision-making hierarchy? Are designers in the room when strategy is set, or are they briefed afterward? Do they have the authority to push back, or only to execute?

4. What happens when UX recommendations conflict with executive preferences? If HIPPO always wins, your user-centered process is a fiction.

5. How much time elapses between research and implementation? If insights routinely go stale before they're acted upon, the feedback loop is broken.

6. Do your workshops produce outcomes that actually ship? Pull up the artifacts from your last three Fakeshop—sorry, workshop—sessions. How many of those sticky-note insights made it into the product?

7. Is your design team measured on craft or outcomes? If success is defined by pixel perfection and stakeholder approval rather than user behaviour change, you're optimising for the wrong thing.

Why FaUX persists

FaUX isn't usually malicious. It persists because it's functional—for the organisation, if not for users.

FaUX is comfortable. Real UX requires confronting uncomfortable truths. Users might hate your product. Your assumptions might be wrong. The feature your CEO championed might be solving a problem no one has. FaUX lets organisations feel innovative and user-focused without the discomfort of actually changing anything.

FaUX satisfies process requirements. Many organisations have mandated "user research" or "design reviews" as stage gates. FaUX checks those boxes efficiently. The process happened. The documentation exists. No one examines whether it influenced anything.

FaUX is cheaper in the short term. Real UX requires time, resources, and organisational patience. It means sometimes killing features, extending timelines, and admitting mistakes. FaUX keeps the trains running on schedule. The costs show up later—in technical debt, user attrition, and redesign cycles—but later is someone else's problem.

FaUX protects power structures. When UX has real influence, it redistributes decision-making authority. Suddenly, data about user behaviour matters more than executive intuition. Not everyone welcomes that shift. FaUX maintains the appearance of user-centricity while keeping traditional power structures intact.

FaUX is hard to measure. How do you prove that a workshop was performative? That research was ignored? That a design team is disempowered? The absence of impact is harder to quantify than its presence. FaUX thrives in measurement gaps.

The cost of FaUX

FaUX isn't free. Organisations pay for it—just not immediately and not in ways that show up on obvious balance sheets.

Designer burnout and attrition

Nothing erodes morale faster than feeling like your work doesn't matter. Designers who spend months on research that's ignored, who watch their recommendations die in backlog purgatory, who are brought in to decorate decisions they had no part in making—they leave. They leave for organisations where they might actually influence outcomes. Or they leave the field entirely.

The cost of replacing a designer is substantial. The cost of losing institutional knowledge and team continuity is worse. The cost of building a reputation as a place where design doesn't matter? That affects every future hire.

Compounding experience debt

Every ignored insight, every unimplemented recommendation, every user pain point that gets backlogged indefinitely—these accumulate. Like technical debt, experience debt compounds. Small usability issues become ingrained user behaviours (workarounds, avoidance patterns, support ticket habits). By the time the organisation decides to address them, the fix requires not just solving the original problem but undoing the adaptations users built around it.

User attrition you can't diagnose

Users rarely announce why they're leaving. They just leave. They encounter one too many frustrations, find an alternative, and quietly disappear from your metrics. FaUX makes this attrition invisible because the research that might explain it either wasn't done or wasn't heeded. You know users are churning; you don't know why, so you can't fix it.

Erosion of competitive advantage

In mature markets, experience is often the primary differentiator. When your UX function is performative, you're not building that advantage—you're just maintaining parity (at best) while competitors who take UX seriously pull ahead. The gap widens slowly, then suddenly.

The cynicism tax

Perhaps the most insidious cost: FaUX breeds organisational cynicism. When people watch user-centered language deployed without user-centered action, they stop believing. They stop trying. "We'll just do what the executives want anyway" becomes the unspoken operating principle. This cynicism is contagious and persistent. It outlasts any individual initiative to "fix culture."

The path forward

Recognising FaUX is the first step. Escaping it is harder—it requires structural change, not just attitudinal shifts.

In Part II of this series, I'll explore what Real UX (RUX) looks like in practice: how to measure UX impact in ways that matter to the business, how to build accountability into design processes, and how to move from UX as a nice-to-have add-on to Product and UX operating as a unified function with shared outcomes.

Because the goal isn't just to stop faking it. It's to build organisations where understanding users genuinely shapes what gets built.

If you recognised your organisation in this piece—or worse, recognised your own practice—I'd like to hear about it. What does FaUX look like where you work? Find me on X or LinkedIn.

For decades, we've designed software as if pixels were permanent. Every button placement, every dropdown menu, every carefully crafted interaction, all built on the assumption that interfaces are things you make and then maintain. But something fundamental is shifting. The pixel layer is decoupling from the systems beneath it, and this changes everything about how we think about design.

To understand where we're headed, we need to think about software in three distinct layers.

Layer 1 is the system of record your databases, your canonical sources of truth, your Salesforce instances and ERPs. This layer isn't going anywhere. It's the bedrock. The data must persist, must be authoritative, must be trustworthy.

Layer 2 is becoming something new: an agentic layer. This is where AI agents operate autonomously over your data, orchestrating actions, making decisions within boundaries, fetching and transforming information on demand. Think of it as the operational intelligence sitting between your data and your users.

Layer 3 is the pixel layer, the interface itself. And here's the radical proposition: this layer is becoming an artefact of intent. Not a permanent structure, but a momentary crystallisation of what someone needs right now.

State your intent, and your UI appears

Imagine this: you have a question about your sales pipeline. Instead of navigating to your CRM, clicking through to reports, filtering by date range, and scanning for patterns, you simply state your intent. The system spins up an interface—a chart, generated on demand, perhaps through something as simple as a "nano API"—that exists purely to answer that question. You get your insight. The interface dissolves.

This is throwaway UI. Not disposable in the sense of being cheap or careless, but ephemeral by design. The interface materialises when needed and disappears when its purpose is fulfilled.

The speed from intent to results in this model can be genuinely addictive. Anyone who has used an AI that generates working code, or creates a custom visualisation in seconds, knows the feeling. It's not just convenience—it's a fundamental shift in the relationship between thought and outcome.

Traffic decays stochastically

Here's an uncomfortable truth for product designers: in a world of generated interfaces, traffic patterns become unpredictable. Users don't follow the same paths through your application because there are no fixed paths. Each interaction might spawn a different interface configuration based on context, history, and stated intent.

This isn't chaos—it's stochastic decay. The carefully designed funnels and user journeys we've obsessed over start to dissolve when every user can summon precisely the interface they need. Some views will still be visited repeatedly—people might want to save views they find valuable—but the aggregate patterns become probabilistic rather than deterministic.

What persists, and what doesn't

Not everything can be ephemeral. A trader executing high-frequency transactions needs interface consistency—muscle memory matters when milliseconds count. A surgeon reviewing imaging data needs guaranteed layouts and predictable interactions. A air traffic controller cannot be surprised by their interface.

This points to a crucial distinction: exploratory software versus operational software.

Exploratory software—tools for research, analysis, creative work, decision support—can embrace the generative model fully. These are contexts where users are exploring possibilities, where the path isn't predetermined, where the interface should adapt to the inquiry rather than constraining it.

Operational software—trading platforms, medical systems, industrial controls—needs its persistence. These are contexts where reliability, consistency, and learned expertise matter more than flexibility.

The interesting middle ground is what we might call "exploration-permissible" software: tools that have operational cores but allow for generative interfaces at the edges. Your core workflow is stable, but you can spawn temporary interfaces to investigate, analyse, or experiment without disrupting the critical path.

Design for the grammar, not the layout

If interfaces are generated rather than designed, what do designers actually do?

The answer is: define the grammar.

Think about language. We don't design every sentence a person might speak—we define vocabulary, syntax, semantics. We create the rules and components from which infinite expressions can emerge. Interface design in the AI age works the same way.

Designers need to define:

Interface grammar: The components, the rules for composition, the valid combinations. What can exist next to what? How do elements relate? What are the atomic units of interaction?

Attention hierarchies: How does the system know what deserves human attention? Not just visual hierarchy in a fixed layout, but dynamic attention allocation in generated interfaces. What should pulse, what should fade, what should demand acknowledgment?

State change patterns: How do transitions work? How does the interface communicate that something has changed? In a generative model, state changes might be more frequent and more varied—the design system needs to handle this gracefully.

Boundary definitions: What are the hard limits? Where does the generative model stop and human decision-making begin? What can never be automated, abbreviated, or assumed?

Is your system easy for AI to compose?

Here's a question every product team should be asking: is your software agent-compatible?

This isn't just about having an API. It's about whether your system exposes itself in ways that AI can understand, compose, and orchestrate. Can an agent navigate your data model coherently? Can it understand the relationships between entities? Can it make reasonable decisions about what to show and what to hide?

The technical concept of idempotency becomes crucial here. An idempotent operation produces the same result regardless of how many times it's executed. In a world where AI agents are orchestrating your system—potentially making multiple attempts, retrying on failure, parallelising requests—idempotent operations prevent cascading errors and unpredictable states.

Systems that weren't designed for agent interaction will struggle. Those built with composability in mind will thrive.

Beautiful UIs are going to get a lot of competition

Here's the uncomfortable implication for interface designers who pride themselves on craft: when any system can generate a competent, contextually appropriate interface on demand, visual beauty becomes table stakes rather than differentiator.

This doesn't mean aesthetics don't matter. It means the source of aesthetic value shifts. The beauty of a generated interface isn't in its pixels but in its appropriateness—how perfectly it fits the moment, the intent, the user's context. An interface that materialises exactly what you need, precisely when you need it, with zero friction, has a different kind of elegance than a lovingly crafted static design.

The competition isn't between beautiful and ugly interfaces. It's between fixed interfaces—however beautiful—and generative ones that adapt to intent. And in many contexts, adaptability wins.

Collaboration tools as bedrock

If we're building toward this future, what do we build on?

Collaboration tools might be the answer. They already deal with multi-user state, real-time updates, flexible layouts, and component composition. They're built for environments where the "right" interface varies by user, by context, by moment.

The primitives of collaborative software—cursors showing presence, components that can be moved and resized, real-time synchronisation of state—map naturally onto generative interfaces. Multiple users can share a dynamically generated view. Changes propagate instantly. The interface becomes a shared artefact that multiple participants can shape through stated intent.

This isn't certain, but it's suggestive. The architectural patterns we've developed for Figma, Notion, Miro, and their ilk might be the foundation for whatever comes next.

A generative mode for applications

Perhaps the future isn't a binary choice between designed interfaces and generated ones. Perhaps it's a mode—a switch you can flip.

Your application has its standard interface, the one that's been designed and tested and refined. But there's also a generative mode, where you can state intents, spawn custom views, compose elements in novel ways. Power users might live in generative mode. New users might start with the designed interface and gradually discover the flexibility beneath.

This suggests a hybrid architecture: a stable, designed shell with generative capabilities embedded within it. The shell provides orientation, consistency, learnability. The generative core provides power, flexibility, responsiveness to intent.

What designers must do now

The transition won't happen overnight, but designers who want to remain relevant need to start thinking differently:

Design for components, not pages. Every element should be capable of existing independently, of being composed with other elements in ways you didn't anticipate.

Design for state, not static. Your components need to handle dynamic data, real-time updates, transitions between states. The generative system will be changing things constantly.

Design for boundaries. Where should the AI stop? What requires human confirmation? What should never be automated? These decisions are design decisions, not just engineering ones.

Design for attention. In a world of infinite generated interfaces, the scarcest resource is human attention. How do you design systems that know what deserves attention and what doesn't?

Design for grammar. Document your design systems not just as component libraries but as grammars—rules for valid composition, semantic relationships between elements, patterns that the generative layer can learn and apply.

The interfaces we'll keep

Not every interface will dissolve into generated ephemerality. Some we'll keep because they work, because we've built skill around them, because consistency has value.

The question isn't whether generated interfaces will replace designed ones. It's which contexts call for which approach. And increasingly, that boundary will be determined not by designers or engineers but by users stating their intent and receiving whatever interface best serves that intent in the moment.

The pixels are decoupling. The question is what we build next.

This might sound strange, even fantastical. But engaging in this imaginary dialogue isn't about predicting the future; it's about actively creating it. By conversing with your hypothetical older self, you embark on a unique self-discovery journey, one that empowers you to define your own "hero's journey."

Here's how:

1. Charting Your Course: Imagine yourself ten, twenty, or even fifty years down the line. What are your accomplishments? What challenges did you overcome? What choices led you there? By visualizing your future self, you set aspirational goals and identify the values that guide your path. This clarity serves as a compass, keeping you focused amidst life's inevitable twists and turns.

2. Unearthing Hidden Potential: Ask your future self about your biggest regrets. What skills did you wish you'd learned? What opportunities did you miss? These insights become valuable lessons for your present self. You'll recognize areas for growth and potential roadblocks, allowing you to make informed decisions that align with your future aspirations.

3. Conquering Your Fears: The unknown can be daunting. But by talking to your future self, you gain a glimpse of successful navigation through those uncertainties. You learn about the challenges you'll likely face and, more importantly, how you overcame them. This instills confidence and resilience, equipping you to tackle present obstacles with newfound courage and determination.

4. Cultivating Gratitude: Imagine your future self expressing gratitude for specific moments or choices you made today. This exercise shifts your perspective, fostering appreciation for your present journey and the small steps that contribute to your long-term goals. It reminds you that every experience, even the seemingly insignificant ones, shapes the hero you're becoming.

5. Embracing the Journey: Remember, your future self isn't a fixed point; it's a dynamic reflection of your present choices. This conversation isn't about achieving a preordained destiny, but rather about embracing the journey of self-discovery. By actively shaping your path and learning from your future self's experiences, you become the author of your own hero's tale, filled with unexpected twists, internal battles, and ultimately, triumphant self-actualization.

So, the next time you find yourself contemplating the future, don't just wonder. Engage in dialogue with your future self. Ask questions, seek guidance, and most importantly, listen. This introspective journey will empower you to chart your course, overcome obstacles, and ultimately, craft a hero's journey that is uniquely your own.

The future is unwritten, but you can influence it by telling your story to yourself.

The central idea behind the theory of cognitive load is that the human brain can only process a small amount of new information, and a large amount of stored information. Cognitive load theory is about optimising the information load for short term memory, make it easier to process or transfer information to long term memory.

For the average user, high cognitive loads directly translate into 'hard to use'.

There are 3 types of cognitive loads:

• Intrinsic. Inherent difficulty of the task or information at hand. For example, is the topic eigenvectors or simple addition? A 12-step application or a quick feedback form?
• Extraneous. Anything that effects the learning of the intrinsic task, such as jargon, inessential info, distracting elements, confusing interface or more.
• Germane. This is a positive load, mainly to reinforce what the user has learnt so far. In traditional learning environments, it includes things such as spaced learning, quick follow-up quizzes and other desirable difficulties. For usability in the digital world, it could include reinforcing previous choices and confirming decisions among others.

Research in this area has produced a couple of key techniques to improve instructional design:

• Worked example effect. The finding that novice learners perform much better if a worked example of a problem is presented to them along with the instruction.
• Expertise reversal effect. The finding that as learners become more proficient at solving a particular type of problem, they should gradually be given more opportunities for independent problem solving.
• Tailored experiences. Gauge the existing skills and knowledge of the user, and tailor the experience that matches it.
• Present all essential information together. Give users an overview of the entire concept in one go (for usability in the digital world, this strategy could prove counter-productive).

The magical number seven (7)

One of the most cited cognitive psychology papers is Miller's the magical number seven, plus or minus two. The finding is that the average person can only hold about 7 things in their short term memory, plus or minus 2 things.

But what's the implication for usability? If your interaction demands a long process, where you are counting on your users to remember things, you might want to review the cognitive load on your users. Are you stretching the limits of what the average person can remember in a short span of time? If you are, then you need to optimise their cognitive load.

Can we measure cognitive loads?

For digital experiences, we rely mostly on user-provided feedback to assess cognitive load. This is subjective, as the variability of humans is a constant in this scenario.

However, there has been research into multi-modal scientific studies to measure cognitive loads on students who study difficult-to-grasp concepts such as Integration or Eigenvectors.

Optimising cognitive load for usability

There are a few usability principles that come into play when optimising cognitive loads:

Progressive disclosure

Simply disclose information that is directly needed to do the task at hand.

Write well

Write concisely, so users don't entirely skip the text, and stay to the point, as the users in most transactional systems are there to get the job done.

Also make sure that your communications meet the readability scores needed for your audience.

Contextual explanations

Provide distributed, small and to-the-point explanations of all possible friction points. Use layering such as tooltips or expanders to keep these explanations only for those who seek it.

Limit choices

Allow users only the most essential choices in any particular pathway in your process. Increasing choices makes decision-making harder. With limited choices, their cognitive load will be significantly reduced.

Use recognition rather than recall

This is one of the 10 usability heuristics for interface design by the legendary Jakob Nielsen.

Simply let people recognise familiar information, rather than asking them to provide it from memory. For example, if you want users to select a state from a dropdown control, present them a list of the states, rather than asking them to type in the name of the state.

Provide memory aids

Reinforce previous choices by repeating or displaying them along the way.

Chunking

Chunking is a cognitive psychology concept, where related things are grouped into chunks that are remembered and processed by users much better than just a linear list or queue.

Chunking depends on the existing knowledge of the user cohort. Expert users have advanced knowledge of how things work, so their cognitive load will be different from the average user.

Subitising

Subtising is the rapid and accurate recognition that human brain does, usually only for small numbers of items.

An application of subtising is digit grouping. For example, writing one million as 1,000,000 rather than 1000000.

Other things to keep in mind

Contiguity effect

Contiguity effect suggests that things are better recalled that are in close proximity to each other, primarily because human memory depends on association between items and their mental context.

Use existing mental models, if you can

In cases where it makes sense to use an existing mental model, it would help immensely to build on top of it. For example, as soon as I mention the word tree, you'd immediately understand the related concepts of roots, branches, leaves, watering and more.

The cost of believing that lie is invisible but real: you ship something adequate when something better was within reach. You solve the problem you were handed instead of the problem that actually exists. You optimise for speed when the situation called for depth.

This isn't about perfectionism or endless iteration. It's about a specific discipline: systematically generating variations before committing to a direction. The goal isn't more options for their own sake. It's arriving at a solution you can genuinely stand behind—one that survives contact with users, stakeholders, and the messy reality of implementation.

Here's a framework for getting there.

The 7-step framework

This framework comes from Artiom Dashinsky, who developed it while leading design at WeWork and conducting hundreds of design interviews. It appears deceptively simple. It isn't. Each step does specific cognitive work that's easy to skip and expensive to skip.

Step 1: Why

Most design problems arrive pre-packaged as solutions.

"We need a dashboard." "Build us an onboarding flow." "Add a settings page." These aren't problems—they're conclusions someone else reached. Your job is to unpack them.

The discipline here is asking why until you hit bedrock. Why a dashboard? Because stakeholders want visibility into user behaviour. Why do they want that? Because churn is increasing and they don't know why. Why don't they know? Because the current analytics are fragmented across three tools.

Now you have a problem worth solving: unified visibility into user behaviour to diagnose churn. A dashboard might solve that. So might automated alerts, a weekly digest, or a predictive model. The solution space just expanded dramatically.

The trap to avoid: Accepting problem statements that have only one possible solution. If the brief permits only one answer, you're not designing—you're transcribing.

Step 2: Who

"Users" is not a user.

Every design problem involves multiple cohorts with competing needs. A checkout flow serves first-time buyers (who need guidance), repeat customers (who need speed), and gift purchasers (who need different delivery options). Designing for all three equally means designing for none of them well.

The discipline here is explicit selection. List every cohort involved. Choose the one you're optimising for. Document that choice. This doesn't mean ignoring other cohorts—it means establishing a hierarchy when trade-offs arise.

The trap to avoid: Designing for an abstracted "average user" who doesn't exist, or trying to serve everyone equally and serving no one distinctively.

Step 3: When and where

Context isn't background information. It's design material.

A user checking their bank balance at 7am on their commute has different needs than the same user checking at 11pm after receiving an overdraft notification. Same feature, radically different design requirements.

Map the contextual variables:

• Location: Where are they physically? What device are they using?
• Trigger: What prompted this interaction? Habit? Notification? Crisis?
• Emotional state: Calm and exploratory? Anxious and goal-directed?
• Before and after: What happened just before this? What will they do next?
• Constraints: How much time do they have? What's competing for their attention?

This mapping generates a list of contextual needs that your solution must address. Skip it, and you're designing for a vacuum.

The trap to avoid: Assuming users encounter your product in ideal conditions with full attention and no stress.

Step 4: What (divergent options)

Now—and only now—you generate solutions.

The key word is divergent. You're not looking for A/B variations on a single concept. You're looking for categorically different approaches to the same problem.

If the goal is reducing customer support volume, your options might include:

• Improved self-service documentation
• Proactive in-app guidance
• AI-assisted troubleshooting
• Community-driven support forums
• Redesigned UI that eliminates confusion points
• Better onboarding that prevents issues upstream

These aren't variations. They're fundamentally different strategic bets. Each implies different resource requirements, timelines, success metrics, and second-order effects.

Generate at least four or five genuinely distinct options before evaluating any of them. The first two will likely be obvious. The interesting ones come after you've exhausted the obvious.

The trap to avoid: Generating variations within a single approach and calling it divergent thinking. "Blue button vs. green button" is not strategic exploration.

Step 5: Prioritise and choose

Here's where rigour earns its keep.

Plot your options on an Effort vs. Impact matrix:

        High Impact
             │
             │   ★ Sweet spot
             │   (High impact, reasonable effort)
             │
Low Effort ──┼── High Effort
             │
             │
             │
        Low Impact

The discipline isn't just placing options on the grid—it's pressure-testing your placements. Impact estimates are often inflated by enthusiasm. Effort estimates are almost always understated.

For each option, ask:

• What's the minimum impact this could have? What assumptions would need to hold for maximum impact?
• What hidden effort exists? Integration complexity? Organisational change management? Maintenance burden?
• What's the reversibility? If this fails, how hard is it to try something else?

Choose the option that maximises impact while maintaining a realistic relationship with effort. This sounds obvious. It's routinely ignored in favour of whatever's most exciting or most aligned with existing momentum.

The trap to avoid: Letting sunk cost, organisational politics, or personal attachment override the matrix.

Step 6: Solve (task-level design)

With your strategic direction chosen, you finally design.

The discipline here is task decomposition. List every discrete action a user must take to accomplish their goal within your solution. Then sketch against each task—not as finished UI, but as a way of thinking through the interaction.

This exercise surfaces problems that conceptual thinking misses:

• Where does the user need to make decisions? Do they have the information to make them?
• Where might they get stuck, confused, or frustrated?
• What happens when things go wrong?
• Where are the hidden dependencies between tasks?

Sketching isn't about visual design. It's about forcing your solution through the narrow aperture of actual use.

The trap to avoid: Jumping to high-fidelity design before the task flow is proven. Polish obscures structural problems.

Step 7: How (success metrics)

A solution without a success metric is a hope, not a design.

Define—before launch—how you'll know whether this worked. The metrics should be:

• Specific: Not "engagement" but "7-day retention among new users"
• Measurable: You need instrumentation in place, not just intent
• Attributable: You should be able to isolate the effect of your change
• Time-bound: When will you evaluate? What's the minimum viable sample?

This step also closes the loop to Step 1. If your why was "reduce churn caused by fragmented analytics visibility," your success metric might be "20% reduction in churn among users who engage with the new unified view within their first 30 days."

If you can't articulate a success metric, you don't yet understand your own solution.

The trap to avoid: Metrics that are easy to measure but don't connect to business outcomes. Dashboard views are vanity metrics if they don't correlate with the behaviour change you actually need.

The variations: Where the framework multiplies

Here's where things get interesting.

Real design problems rarely exist in a single context. The same problem may need to work across:

• Multiple cohorts: Your primary user and a secondary power-user segment
• Multiple contexts: Mobile on-the-go and desktop deep-work sessions
• Multiple constraints: A brand refresh that's in progress, an internationalisation requirement, a platform migration
• Multiple futures: The current product and a planned ecosystem expansion

Each of these represents a parallel run through the framework. Same problem, different inputs, potentially different solutions.

Work the framework separately for each major variation. You'll end up with a set of solutions—not one—each optimised for its specific context.

Then the real synthesis begins.

Pattern recognition: The path to general solutions

When you hold multiple context-specific solutions in view, patterns emerge.

You might notice that three of your five variations share a core interaction model, differing only in surface-level adaptation. That core model is a candidate for your general solution—robust enough to flex across contexts.

Or you might notice that no general solution exists. The cohorts are too different. The contexts are too divergent. The constraints are genuinely incompatible. This is equally valuable information. It tells you that you're not building one feature—you're building a family of features, or making a hard prioritisation call about which context to serve.

The discipline isn't forcing generality. It's letting generality emerge from rigorous specificity.

When to apply this framework

This level of rigour isn't appropriate for every design decision. Use it when:

• The problem is ambiguous or contested
• The stakes are high (significant investment, hard to reverse, high user impact)
• Multiple stakeholders have conflicting visions
• You're designing something foundational that other decisions will build upon
• You're personally uncertain about the right direction

For lower-stakes, well-understood problems, a lighter process is appropriate. The framework is a tool, not a ritual.

The discipline, restated

The "obvious" solution that arrives early and confidently is not your enemy. It's your starting point. The discipline is treating it as one option among several—worthy of consideration, but not coronation.

Work the problem. Generate genuine alternatives. Evaluate them honestly. Choose with intention. Define success before you ship.

Do this consistently, and you'll stop arriving at solutions through intuition and inertia. You'll arrive at solutions you can defend—not because you're defensive, but because you've actually done the work to know why this solution, for this user, in this context, measured this way, is the right bet to make.

That's not perfectionism. That's professional design practice.

There's an element of discovery, a little surprise, may be even a pinch of delight, if it matches user expectations.

The cost of cleverness

But cleverness brings with it layering and cognitive load. Most times, this means complexity, which the average user translates to hard to use.

When you hire a designer to build an interface, your expectation might be that of looking at an exquisite design, never before seen, that will stand out and steal the world's attention. Critics will be dumb-founded at the originality, onlookers will stare at it for hours, and you'll be smug thinking, it was you who did it, you hired the designer after all.

This line of thinking has just one major problem; clarity trumps cleverness, and if you try to be too clever, users will loath you.

Designers like clever

Designers do have a tendency to do clever things. This could be born out of the an urge for originality, or making things prettier, but at the end of the day, usability demands clarity, not cleverness. If you are looking to make things usable, you'll be aiming for simplicity.

Clarity begets speed and efficiency

Clarity means that the user will do their job faster, with minimal errors. This translates to efficiency. If your business wants to keep users engaged, it's probably a good idea to make their lives easier and give them efficient ways of doing things.

Keep cleverness for power users

Power users need a lot of flexibility in their work, that's primarily why they're called power users. For them, it makes sense to think of clever ways to design interfaces. Their work is complex, with lots of options, scenarios and use-cases. Meet their complexity with cleverness if you can.

Same situation, different behaviours

It happens to me, and it might've happened to you too; in a situation that was literally the same, you behaved differently based on that moment's context. We humans are excited one day, and dull the other. Sometimes we're with a girlfriend, other times with dad. Human behaviour is so fluid, you might struggle to repeat your own behaviour from one day to the next.

What does it mean for designers? Is user research kaput? Certainly not. but you might want to look through user actions and arrive at the whys.

Users say one thing & do another

Some people buy an SUV because they think they'll go offroading. For others, it's the thing everyone's doing these days, so they like to fit in. Some might like the extra space, still others might prefer it for transporting sports gear. Whatever the whys are, all of these people go ahead and perform the same action: buy an SUV.

I am pretty sure car companies know all of these whys, and then some more. SUVs in general are quite spacious, but most are not designed for offroading. Didn't the SUV designers know some people might want to go offroading? Surely they do. But they also know that good intentions don't always result in actions. So plenty of people think they'd like to go offroading, but they never actually do. May be the car designers know this difference between what people say and what they actually do.

The key thing here is to understand what percentage of people have that particular why. If it's an edge-case, designers can safely focus on other more important things.

The Hawthorne effect in user research

There's a recognised human bias that occurs when people behave differently because they know they are being watched. It's called the Hawthorne effect. I suspect Hawthorne effect comes into play whenever we carry out moderated usability testing or discovery research. People are self-conscious and want to appear smart. Their behaviour with your service at home might be vastly different.

The 'why' behind user actions

We humans tend to be reasonable beings most times. I say reasonable because usually whatever we do, we have a reason to do it. That reason is the why behind our actions. But our reasons are not always logical or obvious. Is there a deadline looming? We tend to work faster. But if there's something else at play such as a date with a girlfriend, the deadline can wait. We have our reasons for everything we do, although the reasoning could be unreasonable by various standards.

Sometimes it's just a matter of asking. During one usability testing session I was facilitating, the participant kept going back and forth between pages of a form he was supposed to fill out. But after a couple of attempts, he was able to complete the process. My initial hunch was he was just checking if he's filled out the form correctly. Just to be sure, at the end of the test, I asked him why he was navigating back and forth. His answer? He thought he was at the wrong place because he'd filled out a very similar-looking form in the previous test. He just wasn't sure if he was at the right place.

Now this confusion caused by similar-looking forms was the real insight I needed. Another user might completely ignore this confusion, even if they did find it confusing, possibly due to the Hawthorne effect.

Is user research repeatable?

User researchers can make their process repeatable, but users are fickle. They'd do one thing the first time, and do another next. There's no way you'll be able to get exactly the same reactions, feelings, behaviours and comments from a user twice. So, the only way to find real insights is to dig deeper and find the why.

Are the whys repeatable?

Whys can be valid, but more often than not, they're not consistent with each other. They are just as varied as humans are, with no unifying theme. There could be just more reasons for users to do what they do. Once you corroborate the discoveries of why in your research, you'll understand the various motivations, mindsets and preferences of those user cohorts.

By the way, if you've read this far, you should let me know your why on Twitter.

2024 addendum: The AI layer as a third option

When I wrote this piece six years ago, I framed flexibility as a tradeoff between two layers: the product and the service. You could build flexibility into the interface—at the cost of usability—or push it up to the service layer, where human processes could absorb the complexity.

That framing still holds. But something fundamental has changed.

AI has emerged as a third layer where flexibility can live. Not as a feature bolted onto products, but as a genuinely different place to locate the burden of adaptation.

What makes the AI layer different

Traditional product flexibility asks users to understand their options and choose correctly. Service flexibility asks organisations to staff and train for exceptions. AI flexibility asks neither—or rather, it asks the system itself to bear the interpretive load.

Consider a document submission flow. The 2018 approach gave users choices: upload a file, take a photo, fill out a PDF. Each option added interface complexity. The service approach handled edge cases manually: a staff member would call users whose submissions were unclear.

An AI-mediated approach does something else entirely. It accepts whatever the user provides and figures out what to do with it. Blurry photo? Enhance it or extract what's legible. Wrong form? Map the fields to the right one. Missing information? Ask for just what's needed, conversationally, rather than rejecting the whole submission.

The flexibility still exists—the system handles tremendous variation in input—but it's invisible to the user. The interface stays simple because the intelligence sits behind it.

The new tradeoff: predictability

This isn't a free lunch. Each layer trades one kind of cost for another:

• Product flexibility costs usability. Users must navigate complexity.
• Service flexibility costs efficiency. Humans must handle exceptions.
• AI flexibility costs predictability. The system's behaviour becomes harder to guarantee.

For some domains, unpredictability is unacceptable. Financial transactions, medical decisions, legal processes—these need deterministic behaviour that users and auditors can verify. Product and service flexibility remain the right choices here, even with their costs.

But for many other domains—onboarding flows, support interactions, content creation, search—some unpredictability is tolerable, even welcome, if it means users don't have to think about the system's constraints.

Choosing where flexibility lives

The question is no longer just "product or service?" It's now a three-way decision:

Put flexibility in the product when:

• Users need direct control and visibility
• The domain requires auditability
• Variations are finite and well-understood

Put flexibility in the service when:

• Exceptions require human judgment
• Stakes are high and errors costly
• Personal relationships matter

Put flexibility in the AI layer when:

• Input variation is high but intent is clear
• Speed matters more than perfect accuracy
• Users shouldn't need to know the system's constraints

Most systems will use all three. The art is in knowing which variations belong where.

What this means for design practice

For product designers, the implication is significant: you may no longer need to expose every option in the interface. If AI can infer intent from behaviour or context, explicit controls become unnecessary. The skill shifts from designing comprehensive option sets to designing appropriate feedback—helping users understand what the AI understood and correct it when needed.

For service designers, AI changes the economics of exception handling. Many exceptions that once required human intervention can now be resolved automatically. This doesn't eliminate the service layer; it refocuses it on cases where human judgment genuinely adds value.

The core insight from the original piece—that usability should never be compromised, and flexibility should be traded elsewhere when it threatens usability—remains true. We simply have more places to trade it now.

The original piece (2018)

What is product flexibility?

Can't do forms online? Fill out a PDF and upload. Can't upload a photo? Take a photo using the device camera. Giving choice at the product level brings robustness and flexibility into the system. Users find this "easy to use" and there's a much higher chance of them completing their journeys.

For power users, the same principle applies differently. Your system might allow bulk actions, navigational shortcuts, contextual menus, additional options, permission systems, audit logs. Flexible systems serve more users in more situations. But flexible systems are usually complex.

Lidwell's flexibility-usability tradeoff

William Lidwell's Universal Principles of Design describes a flexibility-usability tradeoff: the more flexible something is, the less usable it tends to be.

There's nothing inherently unusable about flexible systems. The issue is what flexibility demands from users. Flexible systems require users to be more aware of their working context. Users need to understand their options at various stages, know the consequences of their actions, carry more cognitive load, maintain bigger working memory.

With flexibility comes complexity. We're simply asking users for more—more attention, more effort, more responsibility.

This tradeoff seems inevitable if we stay within the boundaries of the product. But the product is rarely the whole picture.

Trading flexibility up to the service layer

Services are bigger than products. Their surface area covers not just a system's internal processes, but the physical spaces, the human touchpoints, the offline-online boundaries. This wider scope gives services greater capacity to absorb complexity.

A service designer can distribute complexity elsewhere so that the product ends up simple.

Consider a government application process. A product-centric approach might build extensive validation, multiple document upload options, branching logic for different applicant types—all the flexibility needed to handle variation, all surfaced in the interface.

A service-centric approach might simplify the product to a single happy path, then create processes for handling variations: a triage team that reviews incomplete applications, a phone callback for complex cases, an in-person option for those who can't use digital channels at all.

The total system complexity might be similar. But the product complexity—what users experience—is dramatically reduced.

Service designers can advocate for modularity, breaking monolithic systems into focused components with limited responsibility. They can create handoff points where human judgment takes over from automated processes. They can design feedback loops that let exceptions inform future product improvements.

Product-service flexibility is the real tradeoff

The flexibility-usability tradeoff isn't wrong, but it's incomplete. It assumes flexibility must live in the product. Once we recognise that flexibility can migrate between product and service layers, a different tradeoff emerges: where should flexibility live?

One thing we should never compromise on is usability. When usability suffers, we should look back and ask why so much capability ended up in the product. Can this flexibility be traded up to the service level?

Sometimes the answer is no—the service organisation lacks capacity, or latency requirements rule out human intervention, or the edge cases are too frequent to handle manually. These are real constraints.

But often the answer is yes, it's just that nobody asked. Product and service design happen in silos. Product teams build flexibility into interfaces because that's what they control. Service teams deal with whatever products emerge.

Breaking that pattern might require a difficult conversation with a service owner. It might require changes to staffing or training. It might require a systems architect to rethink handoff points.

It's worth trying. Users shouldn't bear complexity that belongs elsewhere.