Hick's Law for booking forms: how chunking a five-decision screen cuts drop-off
On Take Therapy's booking flow, the existing single-page form violated Hick's Law in a textbook way. Here's the chunking pattern that fixed it — and how to apply the same shape to your own forms.
The moment I noticed it: I'd opened Take Therapy to book a follow-up, tapped through to the booking screen, and immediately put my phone down. Not because I'd changed my mind. Because the screen was asking me — in one scrollable view — to commit to which concern I was booking for, which specialist, which time slot, which payment method, and any notes for the session. Five decisions. One submit button at the bottom. No sense of where I was in the process or how much was left.
I came back to it the next morning, finished the form, and booked the session. But the moment of putting the phone down stuck with me. I wasn't tired. I wasn't distracted. I just hadn't decided on one of the five fields yet (the notes field, in my case — I didn't know what to write), and the form gave me no way to park that decision and move forward with the others. The path of least resistance was to close the app and come back later.
That moment is a Hick's Law moment, and it's the cleanest example of the law I've encountered in a real product. The single screen wasn't broken. It just sat the user in front of too many simultaneous choices, with no structure for working through them. The redesign I proposed in the Take Therapy audit centres on the chunking pattern that fixes this kind of friction — and this post zooms in on exactly that pattern, because the same shape repeats across booking flows, checkouts, onboarding, and account settings.
What Hick's Law actually says
The principle, stated plainly: the time it takes a user to make a decision grows with the number of options presented at once.
The original formulation, from William Edmund Hick's 1952 paper, is a logarithmic one: RT = a + b log2(n), where RT is reaction time, n is the number of choices, and a and b are constants for the individual user. The log2 part is what makes it interesting — doubling the number of options doesn't double decision time, it adds a roughly constant increment. So the cost of going from 1 option to 2 is high, the cost of going from 8 to 16 is also one increment, and so on.
The practical takeaway for product designers is simpler than the formula suggests. More visible options means a slower commit and a higher chance of abandonment. You don't need to compute log2 of anything. You need to count the decisions on a screen and ask whether they belong there together.
The law also doesn't argue for fewer choices in absolute terms. A booking flow that asks five questions still has to ask five questions. What Hick's Law argues against is unstructured simultaneity: presenting all five at once with no scaffolding for working through them one at a time.
How the existing form violated it
Take Therapy's booking screen, in the version I audited, surfaced these five decisions on a single scrollable page:
- The concern being booked for (anxiety, sleep, relationship, other)
- The specialist (a long picker)
- The time slot (a calendar that expanded inline)
- The payment method (card on file, new card, insurance)
- Notes for the session (free text)
The decisions didn't cluster. They came from different mental modes. Concern is reflective — you have to name something about yourself. Specialist and time slot are evaluative — you're comparing options against constraints. Payment is administrative. Notes is generative. Asking the user to flip between four cognitive modes in a single scroll is exactly the kind of friction Hick's Law predicts will slow commitment.
There's also the engineering-side reason this pattern exists, which is worth naming because it's not malicious. A single-page form is cheaper to build. One template, one submit handler, one validation pass. From inside an engineering team, the case for "just put it all on one screen" is easy to make on the implementation cost. The case against it lives in a place the team usually can't see: the drop-off between opened the form and submitted the form. That gap is where the cost actually sits, and it's invisible until you go looking for it.
Said more directly: one-page forms feel cheap to ship because the cost they generate is paid by users in abandonment, not by the team in dev time. Hick's Law gives you the vocabulary to point at that hidden cost.
The chunking pattern that fixed it
The redesign replaces the single-page form with three labelled steps, a progress bar that sits above every step, and a persistent summary at the bottom of the screen so the user can see what they've committed to so far.
Here's the split:
| Step | What it asks | Why it groups |
|---|---|---|
| 1 of 3 | What's the concern you're booking for? | Reflective. The user names the thing they want help with, isolated from any logistical decision. |
| 2 of 3 | Which specialist + which time slot? | Evaluative. Specialist and time are tightly coupled — you pick a person partly by their availability — so they belong on the same screen. |
| 3 of 3 | Review and confirm (payment + notes) | Administrative. The decisions that don't require thinking about the therapy itself. |
The reason concern goes first is that it filters the rest. Once the user has named the concern, the specialist list can be ordered by relevance, and the booking ladders up from a meaningful starting point rather than an undifferentiated catalogue. That's worth more than the technical chunking on its own.
The reason specialist and time slot share a step — rather than getting their own screens — is that they're a coupled decision in the user's head. You don't pick a therapist and then find out their next slot is six weeks out; you pick a therapist because of their availability, or you switch to a different therapist when the availability doesn't work. Splitting them across two screens would force backtracking. Hick's Law isn't a license to over-chunk.
The progress bar matters more than it sounds. It's the visual contract — "step 2 of 3" — that tells the user how much commitment is left. Without it, the user has no read on whether they're about to finish or about to start a long sequence. With it, the cognitive load of "should I park this and come back later" drops sharply, because the user can see they're closer to the end than they thought.
The persistent summary at the bottom is the other half of the chunking pattern. As the user advances through the steps, the summary keeps showing them what they've already chosen — concern, then concern + specialist + time, then everything. They don't have to backtrack to verify, and they don't have to hold the prior decisions in working memory while they work on the current one. That's the difference between a multi-step form that feels like progress and one that feels like a maze.
Where the same shape applies
Hick's Law isn't booking-specific. Once you start counting decisions per screen, the chunking pattern shows up everywhere:
Checkout flows. A single-page checkout that asks for shipping address, billing address, payment, and review at once is the ecommerce equivalent of Take Therapy's booking screen. The same three-step split usually works: address → payment → review. Shopify's hosted checkout, which most stores use by default, is built around this pattern for a reason — abandonment rates on long single-page checkouts are markedly higher than on chunked ones.
Multi-step onboarding. If you're asking new users to set up their account and invite teammates and connect a tool and pick a starter template — that's four decisions, and putting them on one screen will make most users bounce. Splitting into "essentials" (account + one starter choice) and "optional" (teammates + integrations, deferred to a later prompt) gets more users to the activated state.
Settings reorganisation. A settings page that shows every option at once is a Hick's Law problem dressed up as an information-architecture problem. The fix is usually the same shape: group settings into labelled sections (account, notifications, billing, advanced), let the user enter one section at a time, and keep the most-changed settings near the top of each section.
The pattern that repeats across all three: identify the natural clusters of decisions, give each cluster its own screen, surface progress and prior choices, and only break the clusters into smaller steps when the cognitive load on a single cluster is still too high.
Honest scope of what this writeup proves
This is, as with the rest of the Take Therapy audit, a redesign proposal rather than a shipped change with measured outcomes. I'm not going to fabricate drop-off numbers for the chunked form versus the original. The honest claim is that the redesign is defensible — every decision in the chunking pattern traces back to either Hick's Law itself or to the natural clustering of decisions in the user's mental model. Whether it materially improves completion rate is a question for a moderated test, which would be the next step.
What the framing does give you, even pre-test, is the language to argue for the change with a sceptical engineer or PM: not "this feels nicer," but "the existing form puts five decisions across four cognitive modes on one screen, and Hick's Law predicts that pattern slows commitment and increases abandonment." That's enough to get the redesign onto a sprint board.
If this framing has been useful, the broader argument is in the pillar post on anchoring a UX audit to four named laws, and the chunking pattern itself sits inside the full Take Therapy audit and redesign proposal. If you're a founder wondering whether the same shape would help a flow in your own product — booking, checkout, onboarding, or something else with too many decisions on one screen — the services page covers what an audit engagement looks like. Intro calls are free.
