The Clarity Framework: how I use UX, copy and analytics to remove friction from conversion

Interested people leave because something is unclear

Most pages that fail to convert do not fail for lack of interest. The visitor came on purpose. Then something got in the way. A vague headline. A form that asks for a budget before saying hello. A button that jumps as they reach for it. Together these add up to a quiet "not today".

I call the work of finding and removing those obstacles the Clarity Framework. It is my own way of reviewing a page or a flow, and it has four layers, checked in this order:

1. Copy: do the words say what this is, who it is for and what happens next?
2. Flow: does each step follow from the last, without dead ends or questions asked too early?
3. Visual: does the eye land on the right thing first, and can everyone read it?
4. Speed and technical: does the page load, respond and stay still?

The order matters. Speed is easy to measure, so agencies love to start there. A page that loads in one second and says nothing useful just disappoints people faster. I start with the words, because that is where most of the friction lives in the flows I review.

Around the four layers sit two habits: know what the visitor came to do before you start, and measure whether the change helped after.

Worked example: the flow to fix

To keep this concrete, one invented business will carry us through. Salthill Rota is a small software company in Galway. It sells staff scheduling software to independent dental practices around the country, at €149 a month per practice. Aoife runs it with two developers. Every new customer starts with a live demo, so the demo request flow is the whole sales pipeline.

Here is the flow as Aoife inherited it:

1. The demo page opens with a headline that reads "Workforce optimisation for modern practices", over an autoplaying video.
2. A button reads "Submit a request".
3. The form has 11 fields, all required: name, email, phone, company, job title, practice size, number of chairs, current software, budget, how did you hear about us, and a message box. The labels sit inside the fields as grey placeholder text.
4. After submitting, the visitor sees "Thanks, we'll be in touch."
5. Within two working days, someone emails to agree a time.
6. The demo happens, or it does not.

In October, 2,400 visitors who had accepted analytics reached the demo page. 40 of them ended up attending a demo. Every number in this example is made up, and so is the business. Each layer below returns to these figures.

Start with what the visitor came to do

A page cannot be clear in general, only clear for a person trying to get a particular job done. So before I touch a single word, I write down, in one sentence, what the visitor on this page is trying to do, and what they need to know before they will do it.

This sounds obvious and is skipped constantly. A demo page is often written to serve the sales team's wish list (qualify the lead, capture the budget, learn the source) rather than the visitor's question, which is usually "will this sort out my problem, and what am I letting myself in for?".

To find that job, look at the ad or search that brought them, read what existing customers said when they first got in touch, and ask.

Worked example: the one sentence for Salthill Rota

Aoife reads the message box of the last 20 demo requests. A good few of them share the same three worries: "we still do the rota on a spreadsheet", "how long does setup take", and "does it handle part time hygienists". The ad that brings most visitors reads "Dental staff rotas without the spreadsheet".

So the sentence becomes: a practice manager who is tired of building the rota in a spreadsheet wants to see, in a short call, whether this handles their awkward shifts, without committing to anything. A budget field does not serve that sentence. A 20 minute demo with a clear agenda does.

Layer one: copy that says what it is

People do not read web pages. They scan them. Jakob Nielsen's early studies at the Nielsen Norman Group found that 79% of test users always scanned a new page and only 16% read word by word.¹ A later analysis of real browsing data estimated that on an average page visit people have time to read at most 28% of the words, and 20% is more likely.²

So the headline, subheading, button and labels carry the whole load. The same 1997 study compared versions of one site. Making the text concise improved measured usability by 58%, making it scannable by 47%, and making it objective, without promotional language, by 27%. All three together scored 124% better than the original.¹ The study is old, so I treat the exact percentages as history. The direction has held up in every flow I have worked on since.

What I check in the copy layer:

• The headline names the thing and the audience in the visitor's own words, not the category the company would like to own.
• The button says what happens next. "Submit" says nothing. "Book a 20 minute demo" says what, how long and what kind.
• The visitor's real doubt (time, cost, commitment) is answered next to the action.

For a longer treatment of the small words, I wrote a whole piece on microcopy and conversion.

Worked example: rewriting the demo page words

A practice manager scanning "Workforce optimisation for modern practices" has to translate it: optimisation of what? Aoife rewrites the page in the words of her ad and her customers:

• Headline: "Staff rotas for dental practices, without the spreadsheet."
• Subheading: "Part time hygienists, locums and holiday cover in one rota. Most practices are set up in an afternoon."
• Button: "Book a 20 minute demo".
• The line under the button: "A live walkthrough with Aoife. No contract, no card."

Out went "optimisation" and "modern". In came the visitor's own nouns, a time and a person's name.

Layer two: a flow that never asks too early

Flow clarity is about order. Each step follows from the last, keeps what the visitor already said, and asks only for what is needed now. Most friction I find here is a question asked too early.

The research on forms is unusually consistent. The Nielsen Norman Group's top recommendation for forms is simply "keep it short": remove fields that can be derived, collected later or dropped.³ The same guidance asks for one column, labels placed close to their fields, optional fields kept to one or two and clearly marked, and formatting rules stated up front.³ It also warns against putting the label inside the field as placeholder text. The hint vanishes as soon as someone types, which strains memory, makes it hard to check entries and harder to fix errors, and some screen readers do not announce it at all.⁴

The Baymard Institute, which benchmarks checkout usability, finds the same pattern in ecommerce. In its benchmark the average checkout shows 23.48 form elements by default, 14.88 of them form fields, while its research suggests a checkout can be done with 12 to 14 elements, or seven to eight fields.⁵ Among shoppers who abandoned an order for a reason other than just browsing, 18% left because the site wanted them to create an account and 17% because the checkout was too long or complicated.⁵ A demo form is not a checkout, but the lesson transfers: every field is a small cost.

Two tools make a flow shorter without losing information. Progressive disclosure, a term the Nielsen Norman Group uses for showing the few things most people need first and the rest only when asked for.⁶ And deferral: ask the question later, when the answer is needed and the visitor already trusts you. Accessibility pulls in the same direction. Web Content Accessibility Guidelines (WCAG) 2.1 require labels or instructions wherever content asks for input, at level A.⁷ At level AA, fields that collect information about the user must declare their purpose in code, which in practice means the HTML autocomplete attribute, so a browser can fill them in.⁸ A form built to that standard is quicker for everyone.

Worked example: from 11 fields to four

Aoife takes each of the 11 fields and asks one question: is this needed before the demo can be booked?

Field	Needed to book?	What happens to it
Name	Yes	Kept
Email	Yes	Kept, labelled "Work email"
Practice name	Yes	Kept, replaces "Company"
Number of staff	Yes, it sets the demo	Kept, as four radio buttons
Phone	No	Asked on the calendar step, marked optional
Job title	No	Asked in the demo
Practice size, number of chairs	No	Covered by number of staff
Current software	No	Asked in the demo
Budget	No	Dropped, the price is on the pricing page
How did you hear about us	No	Dropped, the campaign link already says
Message	No	One optional box on the calendar step

The four fields get visible labels above them, one column, and autocomplete attributes. Then the biggest change: submitting the form opens a calendar on the next screen, and the visitor picks a slot there and then. The two day email ping pong disappears.

Layer three: the eye lands on the right thing

Visual clarity means the page's hierarchy matches the visitor's priorities. The most important thing is the most visible thing. There is one primary action per screen. Related things sit together, unrelated things have space between them. And everything can be read by everyone.

That last point is not a nicety. WCAG 2.1 success criterion 1.4.3, at level AA, asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, which it defines as at least 18 point, or 14 point bold.⁹ Pale grey text on white, the favourite of many design systems, fails it more often than people expect. The same forms guidance asks that errors be signalled by more than colour, with an outline, text and weight, so nobody misses them.³

The contrast ratio has an exact definition in the standard:¹⁰

$$C = \frac{L_1 + 0.05}{L_2 + 0.05}$$

Here $C$ is the contrast ratio, from 1 (no contrast) to 21 (black on white). $L_1$ is the relative luminance of the lighter colour and $L_2$ the relative luminance of the darker one, each a number from 0 for the darkest black to 1 for the lightest white. The $0.05$ added to both stands in for the light a real screen reflects, and keeps the ratio finite when the darker colour is pure black. It is a ratio of two quantities like any other (Foundations: ratios and rates).

Worked example: the placeholder grey

Aoife's old form showed its labels as placeholders in a light grey, #9ca3af, on a white field. White has a relative luminance of 1. Working through the standard's formula for that grey gives a relative luminance of about 0.364. So:

$$C = \frac{1 + 0.05}{0.364 + 0.05} = \frac{1.05}{0.414} \approx 2.54$$

Here $C$ is the contrast ratio of the grey text on white, $1$ is the luminance of the white background, $0.364$ the luminance of the grey, and $0.05$ the same constant as before. At 2.54:1 it is well short of the 4.5:1 that normal text needs. The new labels sit outside the fields in #52525b, a dark grey with a luminance of about 0.086, which gives $1.05 / 0.136 \approx 7.73$, comfortably above the line (Foundations: ratios and rates).

Two more fixes. The old page had two equally loud buttons, "Submit a request" and "Download our brochure". The brochure becomes a quiet text link, so the demo button is the only primary action. And the field errors, once a thin red border and nothing else, now carry a sentence: "Please add your work email, so I can send the calendar invite", with the field outlined and the text in bold.

Layer four: speed and stability are clarity too

A page that is slow to show its content, slow to react, or that moves while you read it is unclear in the most literal way.

Google's Core Web Vitals put numbers on all three. Largest Contentful Paint (LCP) measures how quickly the main content becomes visible. Interaction to Next Paint (INP) measures how responsive the page is to clicks, taps and key presses. Cumulative Layout Shift (CLS) measures how much content moves unexpectedly while the page is in use.¹¹ The thresholds, measured at the 75th percentile of real page loads and split by mobile and desktop, are:

Metric	Good	Poor
LCP	2.5 seconds or less	above 4.0 seconds
INP	200 milliseconds or less	above 500 milliseconds
CLS	0.1 or less	above 0.25

The values in between need improvement.¹²¹³¹⁴ The 75th percentile means three out of four visits must reach the threshold, so a fast office laptop proves little. Google's own explanation of CLS names the cost directly: a shift can make someone click the wrong link or button, and its example is a user confirming a large order they meant to cancel.¹⁴ I go deeper into the metrics in the article on Core Web Vitals and user experience.

Worked example: the video and the jumping calendar

Aoife has the site report its Core Web Vitals as a consented event from real visits. On mobile, the demo page shows an LCP of 4.3 seconds at the 75th percentile, which is poor. The largest element is the autoplaying video at the top. Its CLS is 0.31, also poor, because a chat widget loads late and pushes the button down just as people reach for it.

The fixes are dull, which is usually a good sign:

1. The video becomes a still image with a play button. The video file loads only when someone presses play.
2. The chat widget gets its space reserved in the layout before it loads, so nothing below it moves.
3. The new calendar step gets a fixed height while its slots load, for the same reason.

The next month, LCP on mobile is 2.1 seconds and CLS is 0.02. Both are good. INP was already at 140 milliseconds and stays there.

Measure what changed, without watching anyone

Every change above is a guess until it is measured. I do not use session recordings or heatmaps for that. They watch the reader instead of respecting them, they sit badly next to a privacy promise, and in my experience they produce pictures that rarely change a decision. Irish law is also clear on the point. Regulation 5 of the ePrivacy Regulations 2011 allows a site to store or read anything on a visitor's device without consent only where that is needed to carry the communication or strictly necessary for a service the visitor asked for.¹⁵ The Data Protection Commission's guidance says plainly that analytics cookies need consent, and its only leniency is for first party cookies strictly limited to aggregated statistics.¹⁶ A recording of one visitor's clicks and scrolls is the opposite of aggregated.

What I use instead is four things.

1. Consented events, one per step that matters. Nothing fires before the visitor agrees. The setup is in my article on event tracking and consent mode.
2. Step rates, which turn a vague "conversion is low" into "most people give up between starting and submitting the form".
3. Asking people one short question at the right moment. A question answers why, which no event can.
4. A/B tests, where the traffic is big enough, with the sample size fixed before the test starts.

The step rate is the most useful of these:

$$r_k = \frac{n_k}{n_{k-1}}$$

Here $r_k$ is the rate of step $k$, $n_k$ is the number of people who completed step $k$, and $n_{k-1}$ is the number who completed the step before it, so they had the chance to do step $k$ (Foundations: ratios and rates).

The overall conversion rate of the flow is then the product of the step rates:

$$R = r_1 \times r_2 \times \cdots \times r_K$$

Here $R$ is the share of people at the start of the flow who reach the end, $r_1$ to $r_K$ are the step rates, and $K$ is the number of steps. Multiplying works because each rate is a share of the people who survived the step before, which is the multiplication rule for "this and then that" (Foundations: probability). A weak step anywhere drags the whole product down, so the weakest step is where to look first.

One caveat: consented events count only the people who agreed to analytics. Comparing two months is fair only if the consent rate stayed roughly the same.

Worked example: Salthill Rota's October funnel

From the 2,400 consented visitors who reached the demo page in October:

Step	People	Step rate
Reached the demo page	2,400
Started the form	600	600 / 2,400 = 25.0%
Submitted the form	132	132 / 600 = 22.0%
Agreed a time by email	66	66 / 132 = 50.0%
Attended the demo	40	40 / 66 = 60.6%

The overall rate is:

$$R = 0.250 \times 0.220 \times 0.500 \times 0.606 \approx 0.0167$$

Here $R$ is the share of demo page visitors who attended a demo, about 1.67%, and the four factors are the step rates from the table in order (Foundations: probability). Two steps stand out. Only 22% of the people who started the form finished it, and half of those who finished it never agreed a time.

Then Aoife asks. The thank you page gets one optional question, "What nearly stopped you booking today?", and she asks the next ten practice managers on their demo calls. The answers repeat: "I didn't know how long the demo would be", "why do you need my budget before I've seen it", and "I forgot to reply to the email". The first is a copy problem, the other two flow problems. The numbers said where. The people said why.

Test the change when the traffic allows

A before and after comparison of two months can mislead, because months differ. When the traffic is there, the honest way to know whether a change works is an A/B test: half the visitors see the old version, half the new, at the same time, and the difference is checked for chance.

The traffic has to be decided before the test, not after. For a test of two rates, the number of people needed in each version is roughly:

$$n = \frac{(z_{\alpha/2} + z_{\beta})^2 \left[p_1(1-p_1) + p_2(1-p_2)\right]}{(p_1 - p_2)^2}$$

Here $n$ is the number of people needed in each version, $z_{\alpha/2}$ is 1.96 for a 5% significance level, $z_{\beta}$ is 0.84 for 80% power, $p_1$ is the current rate and $p_2$ the smallest improved rate worth detecting (Foundations: sample size). Choose $p_2$ as the smallest change you would care about, not the change you hope for. Hope makes tests too short. I explain how much data each kind of question needs in how much data you actually need.

Worked example: testing the short form

Aoife tests the four field form against the 11 field form, on the people who start the form. The current completion rate is 22%. She decides that 28% is the smallest improvement worth the change. Plugging in:

$$n = \frac{(1.96 + 0.84)^2 \left[0.22 \times 0.78 + 0.28 \times 0.72\right]}{(0.28 - 0.22)^2} = \frac{7.84 \times 0.3732}{0.0036} \approx 813$$

Here $n$ is the number of form starters needed in each version, $1.96$ and $0.84$ are the values for 5% significance and 80% power, $0.22$ is the current completion rate, $0.28$ the smallest improved rate worth detecting, and $0.78$ and $0.72$ are one minus each rate (Foundations: sample size). With about 600 form starters a month, split in two, she needs a little under three months. She writes down the end date and does not look at the result before it.

When it ends, each version has 820 starters. The old form was completed by 180 (21.95%), the new one by 330 (40.24%). She checks the difference with a two proportion test:

$$z = \frac{p_2 - p_1}{\sqrt{p(1-p)\left(\frac{1}{n_1} + \frac{1}{n_2}\right)}} = \frac{0.4024 - 0.2195}{\sqrt{0.3110 \times 0.6890 \times \left(\frac{1}{820} + \frac{1}{820}\right)}} \approx \frac{0.1829}{0.0229} \approx 8.0$$

Here $z$ is the test statistic, $p_1$ and $p_2$ are the completion rates of the old and new form, $n_1$ and $n_2$ the starters in each version, and $p$ the pooled rate, $510 / 1{,}640 \approx 0.311$, the completion rate of both groups together (Foundations: hypothesis tests). A $z$ of 8.0 is far beyond the 1.96 needed at the 5% level. The short form is better, and not by chance.

Small sites cannot always test: 50 form starters a month would need years. Then I make the change, label the result honestly as a before and after, and watch the step rate for a few months rather than a few days.

The Galway flow, before and after

After the test, Aoife rolls out everything: the new words, the four field form, the calendar on the next screen, the still image and the reserved space. Here is a comparable month afterwards, again 2,400 consented visitors on the demo page, set against October.

Step	October	After the changes
Started the form	600 (25.0%)	720 (30.0%)
Submitted the form	132 (22.0%)	288 (40.0%)
Booked a time	66 (50.0%)	179 (62.2%)
Attended the demo	40 (60.6%)	108 (60.3%)

The horizontal axis shows the four steps of the flow, each as a pair: the first bar of a pair is October, the second, highlighted, is the month after the changes. The vertical axis is the step rate, the share of people who reached the step before and went on to complete this one. The takeaway is where the movement happened. The biggest jump is in submitting the form, from 22% to 40%, which is the form change the test had already confirmed. Booking rose from 50% to 62.2% because the calendar replaced the email exchange. Starting the form rose a little with the new words. Attendance did not move at all, which is useful too: nothing Aoife changed touched it, so if she wants more demos attended, that is a different problem, with reminders, not page clarity.

Multiplying the new step rates gives $0.300 \times 0.400 \times 0.622 \times 0.603 \approx 0.045$, so 4.5% of demo page visitors now attend a demo, against 1.67% before: 108 demos a month instead of 40. These figures are invented, and a real flow rarely moves this much at once. The shape is the lesson: one or two steps carry most of the gain.

The review, step by step

Here is the whole review as I run it, from the first question to the decision. The four layers sit in the middle, and the measurement wraps around them.

Measurement comes before the layers, so I fix the step that leaks most, not the one I find most interesting. The question to real people comes before the review, so it starts from their words rather than mine. And the loop never ends: once the weakest step is fixed, another one is now the weakest.

What clarity is not

Clarity is not a trick. No countdown timer, no fake scarcity, no pre ticked box. If a "fix" works by making it harder to say no, it is not clarity, it is a dark pattern, and in Ireland, as everywhere in the EU, it can be a legal problem as well as a moral one. I wrote about that line in GDPR dark patterns in UX.

Clarity is also not a redesign. Aoife's page kept its colours, layout and logo. Most of the work took days. In my experience that is typical: the expensive part of a conversion problem is not the fix, it is the time spent not knowing where the problem is.

The method fits on a postcard. Know what the visitor came to do. Count each step, with consent. Ask a few real people why. Then go through the words, the order, the look and the speed, and change the thing that is in the way.

Footnotes

1. Jakob Nielsen, How Users Read on the Web, Nielsen Norman Group, 1997, https://www.nngroup.com/articles/how-users-read-on-the-web/

2. Jakob Nielsen, How Little Do Users Read?, Nielsen Norman Group, 2008, https://www.nngroup.com/articles/how-little-do-users-read/

3. Kathryn Whitenton, Website Forms Usability: Top 10 Recommendations, Nielsen Norman Group, 2016, https://www.nngroup.com/articles/web-form-design/

4. Katie Sherwin, Placeholders in Form Fields Are Harmful, Nielsen Norman Group, 2014, https://www.nngroup.com/articles/form-design-placeholders/

5. Baymard Institute, Cart Abandonment Rate Statistics, Baymard Institute, 2026, https://baymard.com/lists/cart-abandonment-rate

6. Jakob Nielsen, Progressive Disclosure, Nielsen Norman Group, 2006, https://www.nngroup.com/articles/progressive-disclosure/

7. W3C, Understanding Success Criterion 3.3.2: Labels or Instructions, Web Content Accessibility Guidelines 2.1, 2018, https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html

8. W3C, Understanding Success Criterion 1.3.5: Identify Input Purpose, Web Content Accessibility Guidelines 2.1, 2018, https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html

9. W3C, Understanding Success Criterion 1.4.3: Contrast (Minimum), Web Content Accessibility Guidelines 2.1, 2018, https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html

10. W3C, Web Content Accessibility Guidelines (WCAG) 2.1, glossary entries for contrast ratio and relative luminance, W3C Recommendation, 2018, https://www.w3.org/TR/WCAG21/

11. Philip Walton, Web Vitals, web.dev, Google, 2024, https://web.dev/articles/vitals

12. Philip Walton and Barry Pollard, Largest Contentful Paint (LCP), web.dev, Google, 2025, https://web.dev/articles/lcp

13. Jeremy Wagner and Barry Pollard, Interaction to Next Paint (INP), web.dev, Google, 2025, https://web.dev/articles/inp

14. Philip Walton and Milica Mihajlija, Cumulative Layout Shift (CLS), web.dev, Google, 2023, https://web.dev/articles/cls

15. Government of Ireland, S.I. No. 336/2011, European Communities (Electronic Communications Networks and Services) (Privacy and Electronic Communications) Regulations 2011, Regulation 5, Irish Statute Book, 2011, https://www.irishstatutebook.ie/eli/2011/si/336/made/en/print

16. Data Protection Commission, Guidance note: Cookies and other tracking technologies, DPC, 2020, https://www.dataprotection.ie/sites/default/files/uploads/2020-04/Guidance%20note%20on%20cookies%20and%20other%20tracking%20technologies.pdf