How I anchored a UX audit to four named laws — and what each one fixed

The rule I gave myself going into the Take Therapy audit was simple. Every redesign decision had to be justifiable in exactly two sentences: what problem it solves, and which named principle says the existing pattern was wrong. Not "this looks better." Not "this feels more modern." A named law, every time.

I'd been using Take Therapy as a regular user for a few weeks when a couple of moments started snagging me. A cancel button sitting one tap away from a confirmed session, with no confirmation modal. Specialist cards that asked me to drill in just to find out a price. A booking form that gave no sense of how long it would take.

None of those are subjective. They're places where an interface fights against either user safety or user understanding. So I took the time to audit the app properly — not from inside the company, just as someone who cares about how this kind of product feels.

The output was a redesign proposal, not a shipped change. But I wanted every decision in it to survive scrutiny from an engineer asking "why this and not that." Four laws ended up doing most of the heavy lifting. This post is the walkthrough of how each one diagnosed a specific friction in the existing app — and what changed in the redesign because of it.

If you're a founder weighing whether a UX audit is worth scoping for your product, or a designer looking for a framing constraint that makes design conversations less subjective, this is the writeup I wish I'd had before I started.

Why anchor to named laws at all?

There's a difference between "this feels off" and "this violates Hick's Law." Both might end up at the same redesign. But only the second one is defensible across the table from a sceptical engineer, a stretched founder, or a product manager who needs to weigh the cost of the change against everything else in the backlog.

Named principles aren't a marketing veneer on a design decision. They're a constraint that forces the conversation to be about what's actually true, not what's pretty. "I want to add friction here" is hard to argue for. "I want to add friction here because Nielsen's fifth heuristic says we should prevent errors at the source rather than report them after" is much easier to push through code review.

The framing also scopes the audit. A 40-screen redesign would have been ignored as too ambitious for an outsider proposal. A four-screen proposal, with every change traceable to a law, fits inside an engineering sprint.

Here's the spine of the audit I actually wrote:

That's the whole audit, in one table. Let me walk through each row.

Hick's Law: chunking a five-decision form into one decision per screen

The principle: Decision time scales with the number of options visible at once. The more choices a user sees, the longer it takes them to commit to one — and the higher the chance of abandonment.

Where it diagnosed friction: Take Therapy's booking flow was a single screen that asked the user to commit to concern, specialist, time, payment method, and notes all at once. No chunking. No progress indicator. The user has no visual contract for "how long this will take." They start filling, get distracted by a field they don't have the answer to (insurance details, often), and abandon halfway down.

What the redesign did: Three labelled steps replace the single-page form. Each step owns one decision:

1. What's the concern you're booking for?
2. Which specialist + which time slot?
3. Review and confirm.

A progress bar sits above each step so the user can see "step 2 of 3" at a glance. Hick's Law is now satisfied: at any moment, the user is choosing between a much smaller set of options. The booking commitment ladders up instead of confronting them all at once.

Hick's Law is one of those principles that sounds obvious until you start counting decisions on real screens. Most ecommerce checkouts violate it. Most onboarding flows violate it. Most booking forms — including Take Therapy's — violate it. The reason it gets violated isn't ignorance. It's that "one long form" is the path of least design resistance. Breaking a form into steps requires deciding where the steps go, which requires understanding which decisions naturally cluster together. That work usually doesn't get done.

What makes this defensible to engineering: "splitting this into 3 steps" sounds like more work (3 templates instead of 1). It is more work. But the cost of the extra templating is much lower than the cost of the half-completed bookings the existing form was generating. The math is on the side of the redesign.

Fitts' Law: making destructive actions harder to mis-tap

The principle: Time to acquire a target scales inversely with its size and proportionally with its distance. Small distant targets take longer to hit accurately than large nearby ones.

Where it diagnosed friction: Take Therapy's cancel button for a confirmed upcoming session sat one tap deep on the home screen. Same visual weight as the primary "view session details" action. Same colour family. No confirmation. A misfire — a thumb landing one row too high — vacated a booked specialist slot. For a paid therapy session that may have taken a week to find availability for, that's not a small failure.

The Fitts'-law diagnosis is specific: the destructive action was exactly as accessible as the safe action it sat next to. By Fitts, the cost of mis-tapping cancel is identical to the cost of correctly tapping the safe action. That's the wrong distribution of accessibility.

What the redesign did: Cancel is now two taps deeper. Manage → Cancel → Confirm. The manage view is intentionally a smaller secondary action. The cancel button inside manage is rendered in destructive colour (red border, slightly muted fill — visible but not inviting). The confirm sheet spells out the consequence in plain language: "You'll lose this 4pm slot with Dr. X. We can't guarantee it'll be available if you change your mind."

By Fitts' Law, the destructive action is now further from the user's default thumb position, smaller in the visual hierarchy, and gated behind an explicit consequence statement. The cost of mis-tapping has gone from "lost slot" to "one extra tap." That's the right asymmetry.

What I like about pairing Fitts with consequence-framing: the user who genuinely wants to cancel reads the consequence and proceeds. The user who tapped cancel accidentally reads the consequence and backs out. The friction protects the right user without blocking the right user. That's the trade you're trying to find in destructive flows.

Doherty Threshold: surfacing decision-critical info without a tap

The principle: Productivity drops sharply when system response exceeds about 400ms. Originally framed for compute responsiveness, it generalises to any case where decision-critical information is one interaction away from where the user expects it to be.

Where it diagnosed friction: Take Therapy's specialist listing showed name + photo + speciality on the card. To find out price and rating — the two other inputs a user weighs when picking a specialist — they had to tap into the detail page. Two of the three decision-driving variables were hidden behind a tap. Each tap-out-and-back is a comparison cost. For a user scanning ten specialists, that's twenty extra taps of latency between "let me find someone" and "I've picked one."

Doherty isn't usually invoked at the IA level, but the principle generalises. The friction here isn't compute latency. It's decision latency. The user's mental loop ("is this specialist in budget?") is being broken by a tap that should be unnecessary.

What the redesign did: Pricing and rating now sit directly on the listing card, next to the name. Speciality is treated as a filter-chip rather than body copy, so users can scan-filter across many specialists fast. A small "next slot: Wed 2pm" hint replaces having to tap in just to see the calendar.

The redesigned card is denser than the original. That density is the cost. The benefit is that a user can now scan ten specialists in roughly the time it used to take to evaluate two. Doherty is satisfied: every piece of information the user needs to compare options is visible in the same glance.

The wider point: information architecture is a Doherty-Threshold problem in disguise. Every time you hide decision-critical content behind a tap, you're trading user-feedback latency for visual cleanliness. Sometimes that trade is right (don't put your terms-of-service on the card). Often it's wrong. The principle gives you a vocabulary for deciding which is which.

Nielsen's fifth heuristic: error prevention as a system property

The principle: Prevent errors at the source rather than reporting them after the fact. The 10 usability heuristics Jakob Nielsen published in 1994 still hold up; the fifth is the one most directly about destructive flows.

Where it diagnosed friction: Cancel without a confirmation modal is the canonical Nielsen-5 violation. So is "delete account" without a typed confirmation. So is "publish to subscribers" without a preview. Take Therapy had cancel exposed on the home screen with no confirm — error prevention at zero.

But Nielsen-5 isn't just about destructive actions. It generalises to anything where the user can take an action they'll later regret. Are they about to send a calendar invite to the wrong therapist? Are they about to overwrite their session notes? Are they about to book an appointment with the wrong payment method? Any of those should have an error-prevention pattern around them.

What the redesign did: Every destructive action on Take Therapy now has a two-step pattern: tap to enter the destructive interaction, then confirm with the consequence in plain language. The same pattern applies to:

• Cancelling a session (the headline case)
• Changing payment method on a booked session
• Editing session notes after the session has happened
• Switching specialists mid-engagement

Each of those has the same shape: a manage-style entry point, a confirm sheet with the consequence stated, and a back-out option that's at least as prominent as the proceed option.

Nielsen-5 pairs well with Fitts' Law here. Fitts gives you the distance asymmetry (destructive action is further from the default thumb position). Nielsen-5 gives you the consequence-statement asymmetry (the user has to read the consequence before they can proceed). Together they protect the user without blocking the user.

What this audit doesn't prove

The honest scope of this audit is: it's a proposal, not a shipped change with measured outcomes. I'm not going to invent metrics. What the audit does claim is that each change has a principled reason — and that the four named laws give a designer a vocabulary for arguing the trade-offs in front of an engineer or a sceptical PM.

The next honest step is to put the redesigned flows in front of real users in a moderated test and measure:

• Whether the booking-form chunking reduces drop-off
• Whether the destructive-style confirm materially changes the rate of accidental cancels
• Whether surfacing pricing on the listing card improves time-to-first-booking
• Whether the manage-then-confirm pattern is intuitive across the user base (or whether it confuses first-time users)

I'd love to run that test. Without it, the claim stops at principled, which is the right level it should stop at. The redesign isn't proven to work — it's proven to be defensible. That's a different thing.

When to anchor an audit to named laws (and when not to)

This framing works well when:

• The product has a defined set of friction points you can name (not "the whole app feels bad")
• You're proposing changes from outside the company, where engineering buy-in matters more than design polish
• The audience for the audit is mixed (founders + PMs + engineers, not just designers)
• The redesigns are scoped to specific flows, not "rebuild the whole UI"

It works less well when:

• The brief is "make it more delightful" (named laws don't argue for delight — they argue against specific failures)
• The redesign is meant to be a vision exercise (Hick's-law-justified redesigns tend to be conservative; if you want creative leaps, anchor differently)
• The team already has strong design opinions (named laws can read as a debate-club move if the team already shares your conclusions)

The framing is most useful as a discipline for the designer doing the audit. It forces you to justify every change before you ship it. The shipping itself is easier afterwards.

A short follow-up

If you've found the framing useful, the other two cases I've shipped in this voice are worth a look:

• Painted Juttay — brand-led ecommerce design for a Karachi label selling hand-painted juttis. The IA decision I'm proudest of: replacing "colour filter" with "palette mood."
• Enrichplay — responsive crypto product design with one system across mobile + web. The move that did the most work: two density tokens that scale across breakpoints.

And if you're a founder thinking about whether to scope a UX audit for your own product, I take on a small number of audit engagements per quarter. The services page covers what's included; the contact page has booking. Both 30-min intro calls and longer scoping conversations are free.

Whatever framing constraint you end up choosing for your own audits — named laws, jobs-to-be-done, heuristic walkthroughs — the discipline matters more than the choice. A constraint that forces every redesign decision to be defensible in two sentences is a constraint worth keeping.