The short version: "The first 80 percent takes 20 percent of the time" is folklore. Nobody measured it. The phenomenon behind it is nevertheless evidenced from three independent directions: defects cluster (roughly 20 percent of files hold 80 percent of the bugs), estimates are systematically optimistic (the planning fallacy), and IT projects overrun with a fat tail — one in six by 200 percent. What matters in practice is something else: the part that gets cut first is exactly where error cases, edge cases and finishing quality live. Cutting it doesn't save the work. It moves it into operations.

There's a sentence you hear in project meetings roughly every two weeks, and it's always wrong:

"We're 90 percent done."

Translated, it means: the visible part works. The rest is small stuff.

And then the small stuff takes four months.

This is the last piece in a series about forms, error states, status emails, cancellation routes, language and accessibility. Six pieces about things that routinely fall off the end of projects. This one isn't about another thing. It's about the mechanism that makes all of them fall off the end together.

1. First, the Fact-Check, Because the Rule Isn't One

I'm starting with a correction, because otherwise I'd be working with an argument that can be dismantled in three sentences.

The 80/20 distribution itself is real. Vilfredo Pareto observed land distribution in Italy in 1906; Joseph Juran turned it into the "vital few and trivial many" in the 1940s. As a distribution pattern it's well documented across many domains.

The sentence "the first 80 percent takes 20 percent of the time" is not. Nobody has collected that data. There's no study, only a rule of thumb — and its best-known version was explicitly a joke. The ninety-ninety rule is attributed to Tom Cargill of Bell Labs and was popularised by Jon Bentley in his 1985 column in Communications of the ACM:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

The punchline is in the sum: 180 percent. Bentley filed it under "Rule of Credibility."

So anyone arguing "according to the 80/20 rule" in a meeting loses the moment someone asks for the source. What you can use instead is considerably better: three independent, defensible findings that together explain the same thing.

2. Finding One: Defects Don't Distribute Evenly

This is where Pareto genuinely holds.

Analyses of large industrial codebases — by Ostrand and colleagues, and by Hamill, among others — repeatedly show that around 20 percent of files contain roughly 80 percent of defects, and that within those files the defects cluster again. That isn't anecdote, it's been replicated several times.

Two practical consequences follow, and both are usually understood by half:

First, evenly distributed effort is waste. Test every file, screen and flow with equal intensity and you spend most of your effort where there's nothing. That's the legitimate, useful application of Pareto: as a prioritisation tool.

Second, Pareto isn't an excuse. "80 percent is enough" doesn't mean you can leave out 20 percent of the work. It means you know where to look first. The difference between those two sentences is roughly the entire content of this article.

3. Finding Two: Estimates Aren't Imprecise, They're Skewed

If estimates were merely imprecise, you'd land above as often as below. But you land below almost every time. That has a name and a research history.

Kahneman and Tversky called it the planning fallacy and explained it through the difference between the inside view (planning from the details of your own undertaking) and the outside view (looking at how comparable undertakings actually turned out).

The best-known evidence comes from Buehler, Griffin and Ross, published in 1994 in the Journal of Personality and Social Psychology. Thirty-seven students were asked to predict when they would submit their thesis. On average they predicted 33.9 days. They actually took 55.5 days — around 64 percent longer. Only about 30 percent finished by their own stated date.

And here's the part I most enjoy quoting in project meetings: the same people were also asked when they'd be finished if everything went as badly as it possibly could. That catastrophe figure averaged 48.6 days. Reality was still worse.

Remember that for your next planning session: your worst case is, statistically, the optimistic one.

A follow-up study by the same team is particularly awkward. Participants were made to write down beforehand how they had performed on comparable tasks, and were explicitly told to take that into account. Their estimates did not improve. Knowing about it doesn't cure it.

4. Finding Three: It Isn't the Average, It's the Tail

Which brings us to the largest available dataset.

Bent Flyvbjerg and Alexander Budzier analysed 1,471 IT projects. Average cost overrun came to 27 percent — which sounds manageable. But the average conceals the actual risk: the distribution has a fat tail. One in six projects was a "black swan" with an average cost overrun of 200 percent and a schedule overrun of nearly 70 percent. The study at arXiv.

An accompanying analysis by McKinsey with the University of Oxford across more than 5,400 large IT projects landed in similar territory: on average 45 percent over budget, 7 percent over schedule — and 56 percent less value than predicted.

That last figure is the most interesting and the least quoted. It isn't just that projects get more expensive. It's that less comes out of them than planned. And in practice, less coming out means things were left out.

Which brings us to the actual subject.

5. Why the Last 20 Percent Is Different From the First 80

The reason the closing stretch is so unpredictable isn't its size. It's that it's made of something else.

The first 80 percent is the happy path. Known requirements, clean test data, a cooperative user, a working interface, the standard case. That's the part you can describe in advance — which is why it's in the concept, why it can be estimated, and why it goes quickly.

The last 20 percent is everything else. Edge cases. Error states. Real data quality instead of sample data. Integration with a system that behaves differently from its documentation. Accessibility. Performance under load. Migration of legacy records. Legal special cases. The question of what happens when someone has two surnames, lives abroad, or closes the browser mid-flow.

These things have one thing in common: you can't estimate them, because you don't know them in advance. That isn't a planning weakness. That's the nature of the thing. You find edge cases by building, not by planning.

So "we're 90 percent done" is almost always a statement about the happy path — and the happy path isn't 90 percent of the work, it's 90 percent of the visible work.

6. Why It's Exactly This Part That Gets Cut

Now the organisational core, which is what actually interests me about the topic.

The last 20 percent doesn't get cut because someone considers it unimportant. It gets cut because it comes last in time. By the point you'd have to decide about it, the budget is spent, the date is fixed, and the question is no longer "what's important?" but "what can we still manage?"

That's the difference between a decision and a condition. Nobody decided not to write the error messages. There simply wasn't a Friday left.

Three amplifiers make sure it happens again every time:

The progress bar lies. Progress gets measured in features, because features are countable. Error cases, edge cases and quality aren't. So a project looks great in week 12 and isn't.

The visible wins every trade-off. In a demo you see the new screen. You don't see the error message you didn't trigger, or the status email nobody has received yet.

The costs land somewhere else. This is the thread running through the whole series. What gets saved here reappears later in support, in rework, in chargebacks, in training, in warning letters, in operating costs. Different cost centre, different quarter, different department. Nobody connects the two numbers.

So cutting the last 20 percent isn't a saving. It's a transfer — out of a budget that's visible and into several that aren't.

7. Where 80 Percent Genuinely Is Enough

So this doesn't turn into a sermon on perfectionism: there are cases where 80 percent isn't only enough, it's correct.

Prototypes. A prototype should answer a question, not be a product. Design error states there and you're burning money.

Internal explorations and tests. Anything thrown away once the learning is banked.

First market trials with a small, informed user group that knows it's standing on a building site.

Features affecting a small minority — provided you've checked it really is a small minority and the majority can get through without them.

So the mistake isn't the principle. The mistake is misassignment: 80 percent in a prototype is efficiency, 80 percent in a payment flow is an operating risk. The question that needs asking in the project isn't "is 80 percent enough?" but: "who carries the missing 20 — us or the user?"

For the prototype: us. For the application form: the user. And they pay in a currency that arrives back with you as support costs and abandonment.

8. What to Do About It

Four measures, in ascending order of discomfort.

1. Name the last 20 percent before you start. Not "buffer" — a list: error states, empty states, edge cases, accessibility, migration, copy, status communication. What has a name can be defended. What's called "buffer" gets cut first.

2. Pull it forward where you can. Not everything can be pulled forward — but copy, error messages, empty states and accessibility can be built in parallel with the happy path. Same amount of time, spent at a point where there's still budget.

3. Definition of done instead of feature counting. A feature is finished when the error case is designed, the copy is written and keyboard operation has been checked. Otherwise you're counting progress that doesn't exist.

4. Reference class forecasting. Flyvbjerg's own remedy for the planning fallacy, and the only approach with a defensible evidence base: don't estimate from inside the project, estimate from outside. How long did your last five comparable undertakings actually take? Not how long they were planned for — how long they took. That number is your baseline, and then you adjust upward, not down.

Point four is uncomfortable, because it requires somebody to write down your own track record. In most companies that list doesn't exist, and that's no accident.

Why You Can Take My Word for It

I'm Tobias Adam, a freelance UX designer in Hamburg, more than ten years in digital product development.

I learned the craft agency-side, including at Jung von Matt and deepblue networks. I've worked for BMW, Audi, FIFA, Union Investment, Vodafone, OBI and Deutsche Messe, among others. Over 20 awards, including Webby, ADC and Cannes.

What I've learned in that time: I'm rarely the first to notice the last 20 percent — but often the first to write it down. In regulated flows like the VisualVest account opening in the Union Investment orbit that's obvious, because mandatory disclosures, identity verification and review periods sit precisely in that part. In other projects it only surfaces when someone asks what actually happens when something goes wrong. Asking that in the concept phase costs an hour. Asking it after launch costs a quarter.

Today I work freelance and together with HC Merkle as intro.team — two freelancers for the phase where an idea becomes a testable product: concept, UX, UI, prototype, user testing. Short cycles, senior staffing, no agency apparatus.

The Short Version

1. "The first 80 percent in 20 percent of the time" is not a study, it's a rule of thumb — and in its best-known form, a joke.
2. The phenomenon behind it is evidenced anyway, from three independent directions.
3. Defects cluster. Around 20 percent of files hold 80 percent of the bugs. Use that to prioritise, not to omit.
4. Estimates are skewed, not imprecise. And your worst case is statistically the optimistic one.
5. Knowing doesn't cure it. Even people who know their own history keep estimating optimistically.
6. The risk isn't the average, it's the tail. One in six IT projects overruns by 200 percent.
7. The last 20 percent is made of different material: edge cases, errors, real data, integration. Unplannable, because unknown in advance.
8. It doesn't get cut, it's simply what's left over. That's a condition, not a decision.
9. Cutting saves nothing, it transfers — into support, rework, operations.
10. The right question isn't "is 80 percent enough?" but "who carries the missing 20?"

And with that the series closes. Forms, error states, status emails, cancellation routes, language, accessibility: those aren't six different topics. That's the same last 20 percent, six times over.

Previously in this series: forms, field count and smart defaults — B2B software and internal tools — error states — the last mile — cancellation flows — bureaucratic and legal language — accessibility.

Sources and Further Reading

• Jon Bentley: Programming Pearls – Bumper-Sticker Computer Science, Communications of the ACM 28(9), 1985 (origin of the ninety-ninety rule, attributed to Tom Cargill) – doi.org
• Buehler, Griffin & Ross: Exploring the "Planning Fallacy", Journal of Personality and Social Psychology 67(3), 1994 – web.mit.edu
• Flyvbjerg & Budzier: Why Your IT Project May Be Riskier Than You Think, Harvard Business Review 2011 – arxiv.org
• Bloch, Blumberg & Laartz (McKinsey / University of Oxford): Delivering large-scale IT projects on time, on budget, and on value, 2012
• Ostrand, Weyuker et al. and Hamill & Goseva-Popstojanova: studies on defect distribution in large codebases
• Vilfredo Pareto (1906) and Joseph M. Juran: "vital few and trivial many"

Der Beitrag “We’re 90 Percent Done.” erschien zuerst auf Intro.

The short version: Germany's Accessibility Strengthening Act has applied since June 2025, and the market surveillance authority in Magdeburg has been actively checking since January 2026. The most common corporate response was a bought-in overlay plugin. That doesn't work: the US Federal Trade Commission fined the best-known vendor one million dollars in 2025 for claiming its tool made websites WCAG-conformant. Meanwhile the WebAIM Million 2026 analysis shows the first regression in six years: 95.9 percent of home pages have detectable WCAG failures. And six recurring error types account for 96 percent of all problems. These aren't specialist topics. They're fundamentals.

When the BFSG arrived, the same thing happened in a lot of companies: panic in spring, a call to the agency, then the question "isn't there something we can just install?" — and then one line of JavaScript that puts a round icon in the bottom right of the page.

Increase contrast. Enlarge text. Read aloud. Dyslexia mode.

The feeling: sorted. The effect: almost none. And in many cases: negative.

A year on you can take stock, and the result is more interesting than the usual compliance narrative. Two things show up: the pressure has become real — and the industry still mostly bought the wrong thing.

1. What Happened in a Year

A quick situation report, so the baseline is clear.

The authority is working. The joint market surveillance body of the German states for the accessibility of products and services (MLBF), based in Magdeburg, entered its active monitoring phase in January 2026 and has published its inspection strategies. It checks two ways: reactively on complaints — which by its own account takes priority — and actively through its own, often automated sampling. The focus is on services with high reach, high relevance to independent living, and providers with a history of defects.

The fine ceiling is up to €100,000 for serious breaches; in extreme cases the operation of a service can be prohibited.

Warning-letter practice has become more professional. A broadly scattered first wave in summer 2025 has been followed since early 2026 by a second, backed by formal audit reports. Whether BFSG breaches are actionable under German competition law at all is not conclusively settled by the courts — that needs saying. It's a cost risk with an open legal position, not an established cause of action.

And there's pressure from Brussels. In March 2026 the European Commission issued Germany a reasoned opinion on its implementation of the European Accessibility Act. Several trade publications consider a tightening of the German rules likely.

How far implementation has actually got is hard to quantify seriously. Vendors of audit tools report roughly half of criteria met on average — figures from firms whose business depends on the number looking bad, so treat them accordingly. My own observation in projects matches the direction, not necessarily the number.

2. The Overlay Mistake, Now With a Case Number

To what was actually bought.

On 3 January 2025 the US Federal Trade Commission opened proceedings against accessiBe, the best-known vendor of these overlays. The allegation: the company had claimed its tool made any website WCAG-conformant. The FTC considered those claims false, misleading or unsubstantiated. In April 2025 the order became final: one million dollars, plus a prohibition on claiming in future that the automated product can make websites WCAG-conformant or keep them that way — absent evidence. FTC statement on the final order.

Read the core of that order again: a vendor was officially prohibited from promising exactly what its customers were paying it for.

Then there's practice. In the US, where there's active litigation on digital accessibility, operators with an overlay installed continue to get sued — a substantial share of all cases, according to analyses by specialist providers. Those figures again come from market participants, but the direction is undisputed and matches what courts there have been saying for years: an overlay is not evidence of accessibility.

The professional community is unusually united here. The Overlay Fact Sheet has been signed by several hundred accessibility specialists, many of whom rely on assistive technology themselves. overlayfactsheet.com

3. Why This Can't Work Technically

This isn't a vendor problem that a better product would solve. It's a structural one.

An overlay runs in the browser and tries to repair, after the fact, what is missing from structure and content. But most barriers are information gaps, not rendering faults.

Alternative text. A script can detect that an image is there. It cannot know what that image is supposed to mean in this context. The same photo needs a different description on a product page than in a news article. Only the person who placed it knows.

Form labels. A script can guess which label belongs to which field. Guessing is not a strategy on a thirty-field application.

Reading order and structure. Whether the heading hierarchy correctly reflects the content is a question of meaning. Automation can detect patterns, not meaning.

And the worst part: overlays intervene in an environment where users are already running their own tools. Someone using a screen reader has had it configured for years. A script interfering with that usually makes things worse rather than better. That's why rejection is so widespread in the affected community — not on principle, but from experience.

The comparison I use in projects: an overlay is a ramp placed in front of a building without checking whether there's a door behind it.

4. The State of the Web, Measured

Now the numbers that show where the problem actually sits.

WebAIM runs an annual automated analysis of the home pages of the one million most visited websites. The February 2026 results:

• 95.9 percent of home pages had detectable WCAG 2 failures, up from 94.8 percent the year before. That's the first regression after six years of slow improvement.
• An average of 56.1 detected errors per page, up 10.1 percent on 2025.
• WebAIM names the main drivers as sharply increased page complexity and growth in ARIA code — both linked to heavier use of frameworks, libraries and automatically generated code.

WebAIM Million 2026.

Two caveats so the figure isn't over-read: these are automated tests of home pages. Automated testing covers only a subset of WCAG criteria and cannot establish conformance — so the real situation is likely worse, not better.

But the most important finding sits elsewhere anyway: the same six error types account for 96 percent of all detected errors, for the seventh year running.

1. Insufficient text contrast
2. Missing alternative text
3. Missing form labels
4. Empty links
5. Empty buttons
6. Missing document language

Look at that list. There isn't a single specialist topic on it. Any design tool checks contrast. Alternative text is an editorial decision. A form label is one attribute in the code. The document language is precisely one word in the HTML head.

That's the real message of this article: the bulk of the problem is solvable with fundamentals that require no dedicated team. It just doesn't happen, because nobody in the process asks for it.

5. Why the Fine Is the Worst Argument

Now the uncomfortable part, aimed at everyone who took this into their company last year with "we have to do something because of the law" — myself included, because that argument appears in my earlier pieces too.

It works. But it produces the wrong measures.

Someone acting out of fear of a fine buys whatever calms the fear fastest: a plugin, a statement page, a certificate with a seal. All things that show the outside world something was done, and change nothing on the inside.

Someone thinking from use instead lands automatically on the list in section 4 — because those are the failures people actually run into.

It's the same mechanism as with forms, error messages and the last mile: compliance asks "is that enough?" Design asks "does that work?" The first question is cheaper to answer and produces results nobody benefits from. And it has an unpleasant side effect: it turns accessibility into a burden you work through rather than a quality you want to have.

6. The Argument to Use Instead

First: the size of the group. Around eight million people in Germany have a recognised severe disability, and that's only the formal category. Add everyone with temporary impairments, everyone whose eyesight is declining, everyone with motor limitations — and simply: an ageing population. Build a website for thirty-year-olds with perfect eyesight and you're building for a shrinking market.

Second — and this is the point that actually convinces decision-makers: the curb-cut effect. The dropped kerb was built for wheelchair users. Today it's used mostly by people with prams, wheeled suitcases, bicycles and shopping trolleys.

Digitally it's the same, on nearly every point:

• Contrast helps everyone looking at a phone in sunlight.
• Captions are used predominantly by people without hearing impairments — on the train, in the office, at night.
• Keyboard operability is the foundation for every power-user shortcut and every piece of automation.
• Clear labels and comprehensible error messages help everyone, see the earlier parts of this series.
• Clean semantics is simultaneously the basis for search engines and for any machine processing of your content.

Accessibility is the only quality standard I know whose side effect is making the product better for everyone else too. That isn't a moral argument. It's an argument about product quality.

7. What Would Actually Have Worked

What should a company have done with the money it spent on an annual overlay subscription?

1. Fix the six errors. In that order, across all pages. This isn't a project, it's a clean-up — and it covers the bulk of measurable problems.

2. Repair components, not pages. If your buttons, form fields, modals and tables come from a library, you fix each error exactly once. If they don't, that's the real job: sort out the library first, then derive everything from it.

3. The keyboard test. Put the mouse away. Operate your most important flow using only Tab, Enter and arrow keys. Is focus always visible? Can you get out of every overlay? Is the order logical? Twenty minutes, and more informative than most automated reports.

4. Listen with a screen reader once. Not clicking around yourself — invite someone who uses the device daily and watch. That's the meeting after which things start happening in projects.

5. Publish the accessibility statement. It's required under the BFSG anyway, and its absence is the most easily evidenced allegation in warning letters. Half a day's work.

6. Into the definition of done. Otherwise you'll be producing new failures from tomorrow while fixing the old ones. That's exactly what the WebAIM curve shows: more tools, more awareness, more regulation — and worse numbers, because production creates barriers faster than remediation removes them.

8. The Business Case

As in the other parts of this series:

The cost side is lower than everyone assumes. Build accessibility in from the start and you barely pay a premium — the six most common failures don't arise from effort, they arise from inattention. Only retrofitting gets expensive, in proportion to how long you wait.

The risk side you know: up to €100,000, prohibition in extreme cases, plus warning-letter costs in an unsettled legal position, plus audit effort.

The revenue side never gets calculated and is the larger one: every barrier is an abandonment. A form field without a label isn't hard for screen reader users, it's impossible. That's not a worse conversion rate, that's a conversion rate of zero — in a group large enough to show up in your statistics if you went looking.

And the item you can cut immediately: the overlay subscription. That money is better spent on two weeks of clean-up.

Why You Can Take My Word for It

I'm Tobias Adam, a freelance UX designer in Hamburg, more than ten years in digital product development.

I learned the craft agency-side, including at Jung von Matt and deepblue networks. I've worked for BMW, Audi, FIFA, Union Investment, Vodafone, OBI and Deutsche Messe, among others. Over 20 awards, including Webby, ADC and Cannes.

What I've learned in those years: accessibility rarely fails on capability and almost never on budget. It fails because nobody asks early enough. In the projects where it worked — from application flows like the VisualVest account opening in the Union Investment orbit through to onboardings and internal systems — it was never a separate accessibility project. It was a question asked in the concept, again in design, and a third time at sign-off.

Today I work freelance and together with HC Merkle as intro.team — two freelancers for the phase where an idea becomes a testable product: concept, UX, UI, prototype, user testing. Short cycles, senior staffing, no agency apparatus.

The Short Version

1. An overlay is not evidence of accessibility. The FTC penalised the best-known vendor for claiming otherwise.
2. Most barriers are information gaps, not rendering faults. No script can guess what an image means.
3. 95.9 percent of home pages have detectable WCAG failures — the first regression in six years.
4. Six error types account for 96 percent of all problems. Contrast, alt text, labels, empty links, empty buttons, document language.
5. These are fundamentals, not specialist topics. Nobody just asks for them.
6. Repair components, not pages. Fix once instead of a hundred times.
7. The keyboard test takes twenty minutes and finds more than most reports.
8. The fine is the weakest argument. It reliably produces measures that help nobody.
9. Curb-cut effect: what gets built for a few ends up used by everyone.
10. Into the definition of done. Otherwise you create barriers faster than you remove them.

Accessibility isn't a state you purchase. It's a question that has to be asked early enough — and then again, and again.

Provisionally the last part of this series. Previously: forms, field count and smart defaults — B2B software and internal tools — error states — the last mile — cancellation flows — bureaucratic and legal language.

Sources and Further Reading

• WebAIM Million 2026, analysis of the home pages of the top one million websites – webaim.org
• FTC: final order against accessiBe, April 2025 – ftc.gov
• Overlay Fact Sheet, signed by several hundred specialists – overlayfactsheet.com
• Barrierefreiheitsstärkungsgesetz (BFSG), in force since 28 June 2025 – bfsg-gesetz.de
• Market surveillance body of the German states for accessibility (MLBF), Magdeburg – mlbf-barrierefrei.de
• Web Content Accessibility Guidelines 2.1/2.2, quick reference – w3.org

Der Beitrag You Bought a Plugin, Not Accessibility erschien zuerst auf Intro.

The short version: Around 20 percent of adults in Germany sit at the lowest level of reading proficiency — roughly 10.6 million people. Jargon in applications, contracts and interfaces is still the norm. The standard counter-argument ("it has to be worded that way legally") fails in both directions: a 2023 MIT study shows that even lawyers understand and remember legalese worse than plain language — and § 307(1) sentence 2 of the German Civil Code makes incomprehensible terms and conditions void. Incomprehensibility isn't a shield. It's a liability.

A sentence of the kind that appears on German screens millions of times a day:

"Final processing of your request is currently not possible, as the required documentation is not available in full."

What the user wants to know: what's missing, what do I do, how long will it take.
What the sentence delivers: none of that.

You could also write:

"We're still missing your proof of income. Upload it and we'll be done in about three working days."

Same information. Same legal effect. A fraction of the effort for the reader.

And now the surprising part: the second version isn't the riskier one. It's the safer one.

1. Who You're Actually Writing For

Let's start with the audience, because it's systematically misjudged in this area.

The 2023 PIAAC survey, analysed by Anke Grotlüschen's team at the University of Hamburg, puts around 20 percent of adults in Germany aged 16 to 65 at the lowest competence level in reading — roughly 10.6 million people. The earlier LEO study arrived at 6.2 million adults with low literacy in 2018, using a different measurement concept. The figures aren't directly comparable, and that should be said. Overview of LEO PIAAC 2023.

But whichever number you take: we're talking about millions of adults who sign contracts, submit applications, hold insurance policies and run bank accounts — and who come unstuck on a nested sentence with three nominalisations.

Add everyone else: people whose first language isn't German. People under time pressure. People filling in the form on a phone on the train. People with reading or attention impairments. And people who simply can't be bothered to read a sentence three times — probably the largest group of all.

So writing in jargon isn't writing for "the general public minus a few exceptions." It's writing for a minority and excluding everyone else from your own service.

2. The Myth That Jargon Is More Precise

The standard argument runs: it has to be worded that way, or it stops being legally correct.

That's become difficult to sustain empirically.

Even lawyers understand legalese worse. A study by Eric Martínez and colleagues, published in the Proceedings of the National Academy of Sciences in 2023, presented 105 US attorneys with contract passages in two versions: classic legalese and plain language. The lawyers did better overall than laypeople — but they too understood and recalled the legalese versions less well. A further group of attorneys additionally rated the plain-language versions as higher quality, as more likely to be signed, and as no less enforceable. Summary in Scientific American.

And everyone prefers plain language, the educated most of all. Christopher Trudeau surveyed around 376 people about legal communication for his 2012 study The Public Speaks. Result: about 80 percent prefer clear language — and, contrary to expectation, that preference rose with level of education rather than falling. Comparable surveys among judges land at similarly high figures. Study at SSRN.

That clears away two excuses at once. Jargon is neither more precise nor a concession to a sophisticated readership. It's a convention nobody likes and everybody passes on.

3. And Now the Argument That Turns Legal Around

This is where it gets interesting for decision-makers, because the usual defensive line — "incomprehensible but legally watertight" — is exactly backwards in Germany.

Section 307(1) sentence 2 of the German Civil Code contains the transparency requirement: an unreasonable disadvantage may also arise from the fact that a provision is not clear and comprehensible. The consequence isn't a reprimand. It's the invalidity of the clause. Legal text.

In settled case law, the Federal Court of Justice requires that rights and obligations be presented transparently, correctly, definitely and as clearly as possible — and that economic disadvantages and burdens be recognisable. The transparency requirement doesn't apply to consumers alone; the principles developed around it are also applied between businesses.

Translated for your next meeting: the incomprehensible clause doesn't protect you. It falls away. And then, instead of your carefully negotiated arrangement, the default statutory position simply applies.

Two further obligations point the same way:

• Article 12 GDPR requires information "in a concise, transparent, intelligible and easily accessible form, using clear and plain language."
• The BFSG, Germany's Accessibility Strengthening Act, in force since June 2025, points via EN 301 549 to the WCAG. Comprehensible labels, comprehensible error messages and comprehensible instructions aren't a question of style there, they're checkpoints.

A note: I'm a designer, not a lawyer. Someone else does the case-by-case review. What I can assess is whether a sentence gets understood — and that can be tested rather than debated.

4. Why It Stays This Way Anyway

If the arguments are that clear, why does every insurance application still look like 1974?

Because the causes aren't linguistic, they're organisational. Four patterns I see in almost every regulated project:

Copy-paste from the statute. The legal text moves unchanged into the interface. It's convenient and it feels safe. Except the statute addresses legal practitioners, not customers. A paragraph of law isn't user copy, it's the source you write user copy from.

The approval chain only runs one way. Legal can delete and add. But nobody has a mandate to demand comprehensibility. So every text grows with each round — and never shrinks.

Liability fear with no counterweight. Making a sentence more complicated carries no risk. Simplifying it means having to justify yourself. Under that asymmetry no text can improve.

Jargon as a status signal. Nobody says this out loud, but it's there. Complicated language signals competence, seriousness, importance. Especially in sectors where the product itself is invisible — finance, insurance, public administration — the language is often the only thing that looks like substance.

That last pattern is the most persistent, because nobody admits to it. It helps to name it: if your product only seems serious as long as it stays incomprehensible, you have a problem that isn't a copy problem.

5. Finance and Other Regulated Sectors: Mandatory Information Isn't Filing

In regulated industries there's an additional mechanism, and it's a particularly treacherous one: the legislature requires that information be given — and companies treat that as a filing obligation rather than a communication task.

The key information document, the product information sheet, the cost disclosure, the policy conditions, the pre-contractual information: all documents whose stated purpose is to let consumers make an informed decision. And all documents designed in practice so that precisely this doesn't happen — a PDF in the attachment, 8 point type, no structure, no examples, no numbers anyone can relate to their own situation.

The point I most often leave with people responsible in this field: regulation very rarely requires you to be incomprehensible. Usually it requires the opposite, and only prescribes content, sequence and scope. The rest — language, typography, examples, explanatory structure — is your room to manoeuvre. You just don't use it, because nobody ever named it as room to manoeuvre.

And the effect is measurable where it hurts: people who don't understand what they're signing up for abandon, call, cancel later or withdraw. In regulated flows, incomprehensibility produces exactly the same costs as bad forms — just spread across more departments, so nobody notices.

6. Where Bureaucratic Language Actually Shows Up in the Interface

Not in the terms and conditions. Everyone expects it there. In the operation of the product:

Labels. "Identity verification" instead of "check your ID." "Premium payer" instead of "who pays?"

Buttons. "Submit application" is fine. "Complete process" isn't, because the user doesn't know whether anything happens afterwards.

Status labels. "In progress," "under review," "subject to confirmation" — system states passed straight through from back-office processing into a customer interface. "We're waiting on your bank" says the same thing and answers the actual question as well.

Error messages. See the piece on error states: "The input does not conform to the format requirements" versus "The IBAN has 22 characters, yours has 20."

Letters and emails. The classic is the premium increase. "Effective 1 July, an adjustment of premiums will be made pursuant to § 8 of the policy conditions" versus "From 1 July you'll pay €4.20 more a month, so €58.90 instead of €54.70." Both sentences are correct. Only one answers the question the recipient actually has.

The pattern is always the same: jargon describes the transaction from the system's point of view. The user wants it from theirs.

7. The Solution Legal Will Agree To

The most common mistake in simplifying is trying to replace the legal text. That starts a fight you won't win — and don't need to.

The solution is layering: plain language on top, legal text beneath. Both are there, both apply, but the order is right.

In practice that means:

• A summary in everyday language, right at the decision point. What happens, what it costs, what it means for me.
• The full legal text, expandable or linked, unchanged.
• A worked example with numbers. Nothing explains a cost clause like a calculated case.
• Definitions in context, not in a glossary at the end. Someone stumbling over "excess" wants it explained where it appears.

The argument that wins legal over, incidentally, isn't "comprehensibility is nice." It's § 307 from section 3: the summary increases the chance the clause survives at all.

And one distinction that often gets muddled: Leichte Sprache (Easy Language) is a separate, strictly regulated concept with fixed rules, aimed primarily at people with cognitive impairments. Einfache Sprache (Plain Language) is less formalised and means comprehensible standard German. For most products, plain language is the right benchmark — and that bar is higher than most people think.

8. The Business Case

As in the other parts of this series, the version that gets it approved:

Direct: every incomprehensible passage generates enquiries. Take your ten most common support contact reasons and mark the ones where somebody calls because they didn't understand a text. Multiply by your cost per contact. That number is the price of your writing style, and it recurs every year.

Indirect: abandonment in application flows, incomplete document submissions, rework in back-office processing, withdrawals and cancellations from customers who only understood afterwards what they'd signed.

And the risk: a struck-down clause doesn't cost you the clause, it costs you the arrangement behind it — potentially across every contract containing it.

Against that stands a copy project. A few weeks. One person who can write, working with someone who knows the subject matter, plus review by legal. That isn't a transformation. That's a sprint.

9. What You Can Actually Do

1. Read your texts out loud. In the meeting where you approve them. The test is remarkably brutal and takes ten minutes.

2. Find the ten most important sentences. Not every text at once. The sentences every customer sees: completion, rejection, status update, cost notice, cancellation.

3. Write before-and-after pairs. Nothing convinces decision-makers faster than two sentences side by side that mean the same thing.

4. Test with five people who don't work for you. Don't ask whether they understood it — ask what they would do now. That's the only honest test.

5. Build the layered structure. Plain language on top, legal text beneath, worked example alongside.

6. Give someone the mandate. Who is allowed to shorten sentences? As long as the answer is "nobody," nothing changes.

Why You Can Take My Word for It

I'm Tobias Adam, a freelance UX designer in Hamburg, more than ten years in digital product development.

I learned the craft agency-side, including at Jung von Matt and deepblue networks. I've worked for BMW, Audi, FIFA, Union Investment, Vodafone, OBI and Deutsche Messe, among others. Over 20 awards, including Webby, ADC and Cannes.

Regulated flows are where this topic shows itself most clearly. In the VisualVest account opening in the Union Investment orbit, for instance, mandatory disclosures, risk information and identity verification all converge — content that is prescribed and still has to be understood, because at the end of it somebody invests money. That's exactly where you find out whether regulation is really the reason for incomprehensibility, or just the most convenient one. In my experience it's usually the most convenient one.

Today I work freelance and together with HC Merkle as intro.team — two freelancers for the phase where an idea becomes a testable product: concept, UX, UI, prototype, user testing. Short cycles, senior staffing, no agency apparatus.

The Short Version

1. Around 20 percent of adults in Germany sit at the lowest level of reading proficiency. You're writing for them too.
2. Jargon isn't more precise. Even lawyers understand and recall legalese worse.
3. Everyone prefers plain language — and the preference rises with education, it doesn't fall.
4. Incomprehensibility doesn't protect you. Under § 307(1) sentence 2 the clause falls away.
5. The problem is organisational, not linguistic. Legal can add, nobody can cut.
6. Regulation rarely requires you to be incomprehensible. It usually requires the opposite.
7. System language isn't customer language. "Under review" versus "we're waiting on your bank."
8. Layer, don't replace: plain language on top, legal text beneath, a worked example alongside.
9. Test for action, not comprehension. Not "did you understand?" but "what would you do now?"
10. Read the sentences out loud. The cheapest test there is.

A text nobody understands hasn't informed anyone. It has only documented that you could have.

Previously in this series: forms, field count and smart defaults — B2B software and internal tools — error states — the last mile — cancellation flows.

Sources and Further Reading

• LEO PIAAC 2023, University of Hamburg (Grotlüschen et al.): low literacy in the German-speaking world – leo.blogs.uni-hamburg.de
• Martínez, Mollica & Gibson: Even lawyers do not like legalese, PNAS 2023 – summary at scientificamerican.com
• Christopher R. Trudeau: The Public Speaks: An Empirical Study of Legal Communication (2012) – papers.ssrn.com
• Section 307 of the German Civil Code (BGB), content review and transparency requirement – gesetze-im-internet.de
• Article 12 GDPR, transparent information and communication – dsgvo-gesetz.de
• Barrierefreiheitsstärkungsgesetz (BFSG), in force since 28 June 2025 – bfsg-gesetz.de

Der Beitrag Nobody Understands You. Your Lawyers Included. erschien zuerst auf Intro.

The short version: In Germany, a cancellation button has been mandatory since 1 July 2022 (§ 312k of the Civil Code). Get it wrong and you don't risk a fine, you risk something considerably more expensive: customers can then cancel at any time without notice — minimum terms and notice periods become void, across every affected contract. In July 2026 the Federal Court of Justice added that the confirmation page may contain no retention offers. Anyone still running "but wait, here's a discount" at that point isn't operating a retention flow, they're operating a legal breach. And a consumer association study found back in 2023 that only around 42 percent of the sites it checked met the requirements.

There's a UX pattern with a name of its own: the roach motel. Easy to get in, hard to get out.

Two minutes to sign up, three taps, Apple Pay, welcome aboard. And to cancel: find the login, reset the password, dig through four levels of the account area, find a form asking for a contract number that appears nowhere, then the hotline, then Monday to Thursday 9 to 3, then a callback offer, then a discount, then one more confirmation loop.

Companies think this is retention. It isn't.

A customer who wants to cancel has already cancelled internally. What you still influence at this point isn't whether they leave, but how they talk about you once they're gone — and whether they ever come back. That's the entire remaining lever. And it points in the opposite direction from what most companies do.

It's also been illegal for four years. Let's start there, because that's the argument that lands internally.

1. What Has Applied Since 1 July 2022

Section 312k of the German Civil Code obliges companies that conclude continuing obligations with consumers online to provide a cancellation route as easy as the sign-up route. Specifically:

A cancellation button. Labelled "cancel contracts here" or wording equally unambiguous. Permanently available, directly and easily accessible — not three levels deep in the help section and not behind a login.

A confirmation page. Where the consumer can supply the necessary details: type of cancellation, identification of the contract, identification of themselves, the effective date.

A confirmation button. "Cancel now" or equally unambiguous.

An immediate acknowledgement. Receipt of the cancellation must be confirmed to the consumer immediately, electronically and in storable form — with content and timestamp.

Legal text at dejure.

This is, at its core, a design specification written into civil law. A legislature prescribing interaction design is rare — and usually a sign that an industry ignored the topic deliberately for years.

2. The Sanction You Should Care About

Here's the paragraph to read aloud in your next meeting.

The consequence of a faulty cancellation process isn't a fine you can price in. Under § 312k(6), the consumer may terminate the contract at any time and without observing any notice period for as long as the buttons fail to meet the requirements.

Translated: if your cancellation process isn't clean, your entire affected customer base has a right of immediate termination. Minimum term: irrelevant. Notice period: irrelevant. The lock-in your sales model may be built on simply doesn't exist in law.

And under the case law, the obligation applies regardless of whether the individual contract was actually concluded online and regardless of whether it predates July 2022. What matters is that you offer such contracts through your website today.

This isn't a compliance ticket for legal. This is a balance sheet risk.

3. The Courts Have Since Struck Down Every Excuse

Four years of practice have produced a fairly clear line. The key points:

No login first. The Düsseldorf Higher Regional Court ruled in 2024 that a cancellation button leading not to the confirmation page but to a page requiring login constitutes an impermissible splitting of the statutory route (I-20 U 3/23). A step the law doesn't provide for is an obstacle.

No hiding through design. The Munich Regional Court dealt in 2023 with a grey, inconspicuously placed button. "Present" isn't enough; the button has to be genuinely findable.

Broad scope. The Federal Court of Justice clarified in May 2025 that a one-off payment doesn't reliably exclude § 312k where the service is delivered continuously over a term (I ZR 161/24).

And the key point for product teams: in a judgment of 16 July 2026 (I ZR 200/25), the Federal Court of Justice held that § 312k governs the permissible content of the confirmation page exhaustively. Content designed to distract from cancelling or steer towards a different decision is not permitted there — even where it would objectively benefit the customer. Commentary on the ruling.

Read that last point twice. The classic retention flow — "before you go: 50% off for three months!" — is now unlawful on the confirmation page. Not inelegant. Unlawful.

Still open is whether a password prompt for identification is permissible. The Berlin Regional Court considered it defensible in 2024, the Berlin Court of Appeal took up the question in 2025, and the Federal Court of Justice hears it in November 2026. If you're planning today, build conservatively.

A note: I'm a designer, not a lawyer. Implementation in your specific case needs legal review. What I can assess is the process — and in most products I see, it isn't merely legally risky, it's simply badly made.

4. One Year to Comply, and Most Still Hadn't

Germany's federation of consumer organisations examined around 3,000 websites in 2023 — a good year after the rule took effect. Result: only about 42 percent met the cancellation button requirements.

That's a striking number, because nobody can claim the requirement was unclear or technically demanding. One button, one page, one confirmation email. That isn't a week's work.

The obvious explanation is also the uncomfortable one: it wasn't forgotten. It was deferred, because someone thought a little friction was good business.

For contrast, a look across the Atlantic: the US Federal Trade Commission adopted something similar in 2024 with its "click-to-cancel" rule. On 8 July 2025 — six days before it took effect — the Eighth Circuit vacated it entirely over a procedural failure; the FTC began a new rulemaking in early 2026. Overview of the proceedings.

Which means: in the US it's still being litigated. In Germany it's been law for four years. Playing for time here means playing against a statute already in force and case law that has since settled.

5. Now Without the Law: Why Friction Makes No Commercial Sense Either

Suppose § 312k didn't exist. Would a difficult cancellation process be a good idea?

No, for four reasons.

First: you're not keeping anyone, you're only delaying them. A customer who wants to cancel cancels. They cancel a month later, angrier. The revenue you "save" through friction isn't earned, it's deferred — and expensively paid for.

Second: you manufacture payment problems. People who can't get out the normal way block the payment method, reverse the direct debit or trigger a chargeback. That costs fees, handling, and — above a certain rate — the goodwill of your payment provider.

Third: you're buying the review. The cancellation process is the last impression. And the last impression is the one that gets repeated on review platforms, in comparison forums and to the next friend who asks. Nothing produces a one-star review as reliably as a cancellation you had to fight for.

Fourth — and almost everyone misses this: you're blocking the return. A cleanly cancelled customer is a prospect with a complete record, known preferences and a history. That's the cheapest lead you will ever have. A customer you annoyed on the way out isn't a lead. They're a multiplier, just pointing the wrong way.

Put differently: you optimise one month of subscription and pay for it with the re-signup and the referral. That isn't a good trade, it's a trade made out of embarrassment.

6. What Stays Legitimate – The Distinction That Matters

I'm not claiming you have to give up on win-back. I'm claiming there's a difference between an offer and an obstacle, and that nearly everyone blurs it deliberately.

The dividing line is simple:

Does it lengthen the route to the goal, or does it offer a different route?

An offer the user can skip with one click is an offer. Something they have to pass through to reach their goal is an obstacle — even with "we've got something for you" written on top.

Legitimate, and often better than cancellation:

• Pausing. For many customers, cancelling is a workaround for "not right now." Three months' pause retains more contracts than any discount flow — voluntarily.
• Downgrading. People who find you too expensive often want less, not nothing.
• Changing the plan. Annual to monthly, family to individual.

But the place for all of that is before the cancellation button is pressed — in the account area, say, or in the renewal notice — not inside the statutory cancellation route. Since the July 2026 ruling that's no longer merely a design question.

And one detail that's surprisingly often wrong: after cancelling, it should state clearly how long access continues and what coming back would look like. That isn't a retention attempt. It's information the customer needs — and an open door some of them walk back through.

7. The Opportunity Everyone Leaves on the Table

The cancellation process is the one moment where someone tells you honestly why your product didn't work for them. No incentive, no politeness, no interview setting. It's the cheapest user research there is.

But it only works under three conditions:

1. Optional. A mandatory question is an obstacle, see above. And it produces junk data, because people click whatever is fastest.
2. After the cancellation, not before. Let them out first, then ask.
3. Analysable and actually analysed. If the reasons have been sitting in a spreadsheet for two years that nobody opens, the question is just one more question aimed at an irritated human being.

If you take it seriously: the distribution of cancellation reasons is a better product compass than most roadmap workshops. "Too expensive" means something different from "no longer needed," and both mean something different from "doesn't work properly."

8. The Checklist

Walk your own cancellation route once, without insider knowledge and without being logged in:

1. Is the button reachable without logging in? From the homepage, findable in seconds.
2. Does it say what it is? "Cancel contracts here." Not "contract options," not "manage my account."
3. Does it look like a button? Grey on grey in the footer is hiding by other means.
4. Does it lead straight to the confirmation page? No interstitial, no redirect, no promotional block.
5. Is the confirmation page clean? Form, button, nothing else.
6. Does the acknowledgement arrive immediately? Electronic, storable, with content and timestamp.
7. Does it then state how long access runs? And how to come back.
8. Is the reason question optional and placed afterwards?
9. Does it all work on a phone? That's where most people will try.
10. How long does the whole thing take? Compare that number with the length of your checkout. The difference is your problem.

Why You Can Take My Word for It

I'm Tobias Adam, a freelance UX designer in Hamburg, more than ten years in digital product development.

I learned the craft agency-side, including at Jung von Matt and deepblue networks. I've worked for BMW, Audi, FIFA, Union Investment, Vodafone, OBI and Deutsche Messe, among others. Over 20 awards, including Webby, ADC and Cannes.

My interest in this topic isn't legal, it's practical. In projects involving contracts and completion flows — from the VisualVest account opening in the Union Investment orbit to signup and onboarding processes — you see the same reflex over and over: the way in gets polished until it gleams, and the way out gets treated as a threat. Yet the way out is often exactly what decides whether someone is willing to go in at all. A visible exit lowers the threshold at the entrance. That isn't friendliness, that's conversion logic.

Today I work freelance and together with HC Merkle as intro.team — two freelancers for the phase where an idea becomes a testable product: concept, UX, UI, prototype, user testing. Short cycles, senior staffing, no agency apparatus.

The Short Version

1. Cancelling has to be as easy as signing up. In Germany that's been law since 1 July 2022.
2. The sanction isn't a fine, it's a right of immediate termination for the entire affected base. Minimum terms become void.
3. No login before the cancellation button. Courts have struck that down repeatedly.
4. No retention offers on the confirmation page. The Federal Court of Justice settled that in July 2026.
5. A 42 percent compliance rate after one year says this wasn't an oversight, it was a calculation.
6. Friction retains nobody. It delays, adds cost and produces chargebacks.
7. The cancellation process is the last impression — and the one that gets repeated.
8. A cleanly cancelled customer is your cheapest future lead. An irritated one is the opposite.
9. Offer, not obstacle: pause, downgrade, change plan — offer them, yes; put them in the mandatory route, no.
10. Ask for the reason. Optional, afterwards, and actually read it.

A visible exit isn't a risk. It's the reason people walk in at all.

Previously in this series: forms, field count and smart defaults — B2B software and internal tools — error states — the last mile.

Sources and Further Reading

• Section 312k of the German Civil Code (BGB), cancellation of consumer contracts in e-commerce – dejure.org
• German Federal Court of Justice, judgment of 16 July 2026 – I ZR 200/25, on a confirmation page without distraction – mtrlegal.com
• Case law overview on the cancellation button (Bird & Bird) – twobirds.com
• Eighth Circuit vacates the FTC "click-to-cancel" rule (8 July 2025) – lw.com
• Harry Brignull on dark patterns and the "roach motel" – deceptive.design

Der Beitrag Let Them Go erschien zuerst auf Intro.

The short version: Everything that happens after the click on "buy" or "submit" doesn't get designed in projects, it gets forgotten. Yet the confirmation page is the highest-attention screen in your whole product, status emails get opened far more often than anything marketing sends, and appointment reminders cut no-shows by roughly a third. Stay silent here and you generate support contacts, no-shows and follow-up questions — from customers who had already said yes.

Every project has a moment where everyone exhales. The user clicked. Order placed, application submitted, appointment booked. Target hit, KPI green, champagne.

For the user, that's where it starts.

They've just handed something over — money, personal data, a slot in their calendar — and at that precise moment they know the least about what happens next. Maximum attention, minimum information. You couldn't manufacture unease more reliably.

And what does the product do? It shows a grey page saying "Thank you for your order," sends an email written in 2017, and then goes quiet for three days.

I call this area the last mile: everything between completion and the moment the user actually has what they wanted. Confirmation page, confirmation email, status updates, reminders, appointment confirmations, delivery notifications, progress reports.

In logistics, everyone knows the last mile is the most expensive part of the route. In product projects it gets treated as though it weren't part of the route at all.

1. The Confirmation Page: Highest Attention, Lowest Effort

This page is seen by practically every customer you have. Not by 3 percent, like your blog. By all of them. And it gets read carefully, because the user wants to know whether it worked.

It's still a text snippet in most projects.

What belongs on it isn't a matter of taste. It's five answers:

Did it work? Unambiguously, at the top, without guessing. A green tick plus an order number beats any block of prose.

What did I actually just do? A summary of the transaction. What, how much, to which address, with which payment method. The moment someone spots a typo in their address is the cheapest moment for both of you.

What happens next — and when? The most important point and the one most often missing. "We're reviewing your application" isn't a statement. "We're reviewing your application, that usually takes three working days, then you'll get an email" is.

What can I do now? Change, cancel, upload, add the appointment to a calendar. And if there's nothing to do: say that too. "You don't need to do anything else" is a good sentence.

Where do I find this again? Order number, link to status, a note about the email. In copyable form, not as an image.

Incidentally, part of this isn't optional in Germany. Section 312i(1)(3) of the German Civil Code requires businesses in e-commerce to confirm receipt of an order without undue delay by electronic means. Legal text. The Munich Regional Court clarified in 2022 that for consumers, "without undue delay" means a matter of a few office hours. Most shops meet this technically — but only technically.

2. The Gap Afterwards: Silence Costs Money

After the confirmation, most products deliver: nothing.

And into that nothing steps the most common support enquiry in retail. It even has its own acronym: WISMO — Where is my order?

The figures vary considerably by source, and most come from vendors selling tracking software; I present them as an order of magnitude, not a measurement. But the range is unambiguous either way: depending on the survey, WISMO accounts for somewhere between 10 and 40 percent of total support volume, considerably more at peak times. In many contact centres it isn't one topic among others, it's the topic.

The decisive point: these contacts are almost never caused by slow delivery. They're caused by silence between two events. A customer who knows their parcel arrives Thursday doesn't call. A customer who hasn't heard anything since Monday calls — even if the parcel arrives Thursday.

So you're not only selling a product. You're also selling the certainty that it's on its way. That certainty costs you roughly nothing if you deliver it proactively, and quite a lot if you make people collect it from you by phone.

The same applies well beyond retail: application processing, credit decisions, recruitment, repair jobs, account openings. Anywhere there's a wait between submission and outcome, a progress update is the cheapest service you can provide. Even the update "this is taking longer than expected" comfortably beats silence.

3. Reminders: The Best-Evidenced Measure in This Whole Piece

If you schedule appointments, this is the section with the best effort-to-effect ratio.

Missed appointments are a bigger problem than most people assume. Germany's National Association of Statutory Health Insurance Physicians reported that in the first quarter of 2023, around 22 percent of specialist appointments booked through the central service went unattended; in psychotherapy the rate was higher still. Across sectors, the average no-show rate in the research literature sits at around 23 percent.

And reminders work, demonstrably: a systematic review of 29 studies (Hasvold and Wootton) found non-attendance reduced by roughly 34 percent of baseline — median no-show rates fell from 23.1 to 12.5 percent. A meta-analysis of SMS reminders lands at an odds ratio of about 1.6.

Run that for any appointment-based operation. A clinic, a consultancy, a workshop, a public counter: every missed appointment is paid time with no return, and every prevented one is pure margin. The measure costs a few cents per message.

What matters is less the channel than the action option. A reminder without a cancel or reschedule link is half a measure: someone who can't make it still has no way to tell you. And cancellations are exactly what you want — cancelled slots can be refilled, missed ones can't.

4. Who Owns the Last Mile? Nobody. Which Is Why It Looks Like That.

Now the structural part, and it's the same in almost every company.

The confirmation page belongs to the product team — in theory. In practice it ships as a default with the shop system or the framework.

The confirmation email belongs to… whom, exactly? It sits as a template in the back end. It was probably written by a developer setting the system up, in five minutes, because that day was about something else. Marketing can't get at it, because it isn't campaign material. Design has never seen it, because it exists in no design file. The copy sits in a configuration file, in language nobody has edited.

The status notifications belong to the logistics provider or the line-of-business system. So: to nobody who thinks about language.

That's why the last mile reads like a different product from the website that preceded it: different tone, different typography, different form of address, sometimes a different logo. Customers notice. Above all, they notice that the care ran out exactly at the point the payment came in.

That's the real finding: the last mile isn't a quality problem, it's an ownership problem. As long as it appears in no concept, no design and no backlog, it stays the product of the default setting.

A very concrete test: in your next meeting, ask who last read the confirmation email. Not wrote — read. Most rooms go quiet.

5. Transactional Emails Are Not a Marketing Channel (Legally Either, in Germany)

Here's where someone from marketing usually wakes up: these emails have open rates campaigns can only dream of. Depending on the survey, transactional mail sits somewhere between 45 and 70 percent, while ordinary newsletters often land in the low double digits. Those are mostly vendor figures too — but nobody disputes the direction.

The reflex is then: let's put something in there.

Two reasons not to.

First, usefulness. The high open rate exists because the email contains one specific piece of information the recipient is looking for. Overload it with cross-selling and you destroy the very reason it gets opened. The tracking number goes at the top, not underneath three product recommendations.

Second, the law. In Germany this isn't merely impolite, it's risky. In 2018 the Federal Court of Justice ruled that a customer satisfaction survey counts as advertising — even when it's embedded in an invoice email (judgment of 10 July 2018, VI ZR 225/17). Without consent or a proper notice of the right to object, that's an infringement of general personality rights. Summary at Wettbewerbszentrale.

Note the logic: a transactional email doesn't stay advertising-free just because there's an invoice at the top. The promotional part is assessed on its own.

6. The Craft, in Brief

A few things that turn up in nearly every audit and can be fixed in a week:

The sender address. no-reply@ is the least friendly line a company can write. It says: we'll contact you, please don't contact us. If you don't want to process replies, at least set up an auto-response pointing to the right route.

The subject line. It should identify the transaction, not you. "Your order 4711 is on its way" beats "News from us."

The preview text. The second line in every mail client. Nine times out of ten it reads "If this email doesn't display correctly…".

Mobile and dark mode. Most of these emails are read on a phone, a growing share in dark mode, where plenty of templates turn into black boxes with invisible text.

Most important information at the top. Not below the logo, not below the greeting. Tracking number, appointment, amount — at the top.

Plain language, not system language. "Status: PENDING_REVIEW" is not customer communication.

Accessibility. The BFSG applies here too since June 2025: if the ordering flow is covered, the confirmation page and its associated electronic communication are part of the same service. A confirmation delivered purely as an image file is therefore a problem.

7. The Business Case

As in the other parts of this series: this is the section that gets it approved.

Assume 30,000 transactions a year. Three percent of customers get in touch with a status question — realistic, if anything low. That's 900 contacts. At €12 per contact that's €10,800 a year, spent telling people something your system already knew.

An automated status email at two sensible points in the flow costs you: writing the copy once, building the template once, setting the trigger once. After that it runs.

For appointments the maths is even clearer. 2,000 appointments a year, 20 percent no-shows, that's 400 lost slots. Preventing a third — the order of magnitude from the research — is around 130 additional used appointments. Put your own value per appointment in; the number will surprise you.

And one item you can't quantify directly but everyone recognises: the last mile is the part customers remember. Nobody tells their friends about a well-made product page. Everybody tells them about an order that vanished without a trace.

8. What You Can Actually Do

1. Print out your last mile. Confirmation page, every automated email, every SMS, every status message. Lay them side by side. It takes a morning and it's reliably the most uncomfortable morning of the quarter.

2. Order from yourself once. All the way through, with a real address. Remarkably many teams have never done this.

3. Answer the five questions. Did it work, what did I do, what happens when, what can I do, where do I find it again. Any page or email leaving one of these open gets rewritten.

4. Find the silent stretches. Where do more than 48 hours pass without a message? That's exactly where a progress update belongs.

5. Give every reminder an action option. Cancel, reschedule, change. Otherwise it's just a notification.

6. Appoint an owner. Without one, nothing happens and you'll be back here in a year.

Why You Can Take My Word for It

I'm Tobias Adam, a freelance UX designer in Hamburg, more than ten years in digital product development.

I learned the craft agency-side, including at Jung von Matt and deepblue networks. I've worked for BMW, Audi, FIFA, Union Investment, Vodafone, OBI and Deutsche Messe, among others. Over 20 awards, including Webby, ADC and Cannes.

The last mile has shown up as a blind spot in project after project — most visibly wherever there's processing time between completion and outcome. The VisualVest account opening in the Union Investment orbit, for example: between "application sent" and "account usable" sit review steps the customer can't see. What they hear during that time decides whether they feel their money has landed with someone who knows what they're doing. Or a digital future planner, so far unpublished, where the same question came up in the quiet periods between sessions.

And then it runs through everything else: signups, onboardings, applications, internal systems. The last mile is the part I most often write down for the first time in a project's history.

Today I work freelance and together with HC Merkle as intro.team — two freelancers for the phase where an idea becomes a testable product: concept, UX, UI, prototype, user testing. Short cycles, senior staffing, no agency apparatus.

The Short Version

1. For you the transaction ends with the click. For the user it starts there.
2. The confirmation page has the highest attention in your product — and the least design work.
3. Five questions need answering: did it work, what did I do, what happens when, what can I do, where do I find it again.
4. Silence generates calls. Not slowness. A progress update is the cheapest service there is.
5. Appointment reminders cut no-shows by roughly a third — evidenced, cheap, shippable in a week.
6. Every reminder needs an action option. Cancelled slots can be refilled, missed ones can't.
7. Transactional emails are not advertising space — not in substance, and not under German case law.
8. no-reply@ is a statement about you, and not a good one.
9. The last mile belongs to nobody. Which is why it looks like the default setting — because it is one.
10. Order from yourself once. All the way through.

The click isn't the end of the route. It's the point where you stopped designing.

Previously in this series: forms, field count and smart defaults — B2B software and internal tools — error states.

Sources and Further Reading

• Section 312i of the German Civil Code (BGB), general obligations in e-commerce – gesetze-im-internet.de
• German Federal Court of Justice, judgment of 10 July 2018, VI ZR 225/17, on customer satisfaction surveys in invoice emails – wettbewerbszentrale.de
• Hasvold & Wootton: systematic review of automated appointment reminders, Journal of Telemedicine and Telecare (2011) – findable via PubMed
• German National Association of Statutory Health Insurance Physicians (KBV): figures on missed appointments, Q1 2023
• Barrierefreiheitsstärkungsgesetz (BFSG), in force since 28 June 2025 – bfsg-gesetz.de

Der Beitrag “Thank You for Your Order.” And Then: Silence. erschien zuerst auf Intro.

The short version: Error states hit exactly the people who were about to pay, book or submit. They still get designed nowhere: they appear in no concept and no acceptance criteria, so a developer ends up typing them into the code window on the side while actually building the feature. The result isn't a design problem, it's a cost problem that compounds: every incomprehensible message generates support contacts, and Gartner puts the median cost of a live-channel contact at $13.50. Rewriting the message costs twenty minutes, once. The phone call costs you every single time.

Take a proper look at this sentence:

A technical error has occurred. Please try again later.

At that moment the user has four questions:

1. What happened?
2. Was it my fault?
3. Is my data gone?
4. When is "later"?

Zero get answered. The sentence contains exactly one piece of information — that something is broken — and the user already had that before reading it.

Which is precisely why it's the default message: it's the only statement that's always true if you don't want to know anything about the situation. It isn't communication. It's a shrug in the corporate typeface.

And it never appears at a harmless moment. Error messages don't show up while someone is idly scrolling. They show up when someone wanted to do something: submit, pay, book, apply. Error states reliably hit the users with the highest intent. Which is to say: the most valuable ones you have that day.

1. The Part Everyone Skips: What This Costs

I'm deliberately not starting with copy examples. I'm starting with money, because this is where projects look away, systematically.

Bad error communication isn't an ugliness. It's a standing liability. And one you never shed, because it's never paid off: every message nobody understands costs you not once, but with every single user who sees it — in a different cost centre, where nobody connects it back to the source.

That's the difference from a loan. A loan gets repaid eventually. This keeps running, and the amount grows the better your product does.

The instalments are called: phone call, ticket, chat transcript, email to support, question to a colleague, abandonment.

Some defensible numbers.

Gartner puts the median cost of a contact in an assisted channel — phone, chat, email — at $13.50, while a successfully completed self-service interaction lands around $1.84. An earlier survey in the same series put live contact at $8.01 against roughly 10 cents for self-service. Gartner on the cost difference. The exact figure varies by sector and country. The order of magnitude doesn't: a human on the phone costs a multiple of what a self-explanatory screen costs.

Now the calculation you can run yourself.

Say your application handles 100,000 relevant transactions a month. Two percent run into an error state — that isn't much. That's 2,000 cases. A fifth of those contact support because the message didn't help: 400 contacts. At €12 per contact — conservative, measured against the numbers above — that's €4,800 a month. €57,600 a year.

For a handful of sentences nobody ever wrote.

And now the part that appears in no presentation:

These costs grow with your success. More users means more error cases means more contacts. The design work, meanwhile, happens exactly once. So you've traded a recurring, growing expense against a one-off investment — in the wrong direction. Whoever scales, scales the problem too.

And you're paying in several places at once:

• Support. Every contact that exists only because a screen explained nothing.
• Second level and engineering. When the error code means nothing to the user and nothing to support either, the case lands with the people whose hour costs the most.
• Abandonment. The share that never gets in touch and simply leaves. It appears in no ticketing system — the most expensive cases are the ones you never see.
• Repeated failed attempts. Every failed try generates load, logs and sometimes junk data in your systems.
• Trust. Soft but real: a user who lost their input once will not fill in a long form a second time.
• Internal onboarding. In business applications there's an extra layer: every cryptic message becomes part of the tribal knowledge new staff have to acquire the hard way. That's training cost you built yourself.

The bitter part: error messages are the cheapest repair in the entire product lifecycle. No refactoring, no migration, no new architecture. Usually: change the text, attach the message to the right field, add a button. Days, not months.

Ask your support team for the ten most common contact reasons. If at least three of them don't trace back to a screen that explained nothing, I'll eat my notebook.

2. What's Missing From That Standard Sentence

Back to the classic. A usable error message answers four things:

What happened — in the user's language. Not "transaction declined" but "your bank declined the payment." Same fact, entirely different information.

What about my data? The most important and least frequently answered question. "Your input has been saved" removes ninety percent of the panic. One sentence.

What can I do now? Every message needs a next step. Try again, use another route, contact support, come back later — but something. A dead end with an "OK" button isn't communication, it's an eviction.

When, if not now? "Try again later" isn't a time. "In about ten minutes" or "we're working on it, status here" is.

None of this is my invention. At its core it's the ninth of Jakob Nielsen's usability heuristics — users should be able to recognise, diagnose and recover from errors — and the Nielsen Norman Group has turned it into twelve very concrete rules. Error-message guidelines at NN/g.

3. Error Codes: Not the Problem, Rarely the Solution

ERR_5031 is a message to the engineering team that was accidentally delivered to the customer.

Even so, I'm not against error codes. They're useful — in support. A code a user can read out shortens every call. The only question is whether the code is the message or whether it accompanies it.

Wrong: the code is the message.
Right: plain language at the top, the action option in the middle, the code small underneath, copyable.

Two conditions for a code to do its job:

1. Support can look it up — without calling engineering.
2. It's unambiguous. A code triggered by five different causes is decoration.

And HTTP status codes generally don't belong in the interface. "500 Internal Server Error" is about as useful to someone without an IT background as an error message in Latin. It isn't even mistranslated — it simply wasn't written for them.

4. Whose Fault Is It Anyway?

Three states get muddled constantly:

System errors. Server gone, interface dead, timeout. The user isn't responsible and usually can't do anything about it. This is where an apology and a statement of what happens next belong.

User errors. Wrong format, missing required field, invalid combination. This is where instruction belongs, not a lecture.

Expected states. Account locked, item out of stock, slot taken. These aren't errors, they're outcomes. They still get rendered in red, because in the code it was the same branch.

And then there's the category that annoys me most: errors you cause and blame on the user. "Invalid input" for a format you never documented anywhere. The rejected IBAN with spaces in it, even though every bank statement prints it with spaces. The date field that only accepts DD.MM.YYYY and rejects 1.3.2026.

That isn't user error. That's system error with an accusation attached.

5. Tone

Error messages are the one moment your brand speaks to somebody who is already annoyed. Treat the tone accordingly.

What doesn't work:

• The passive voice. "An error has occurred" — spontaneously, apparently.
• Blame. "You have entered an invalid number." Nobody talks like that outside a government office.
• Legalese. "The processing of your request could not be completed."
• Jokes in the wrong place. "Oops! Something went wrong 🙈" — on a failed payment that isn't sympathy, it's mockery. Humour belongs on a 404 page. Not in a payment flow.

What works: factual, specific, no finger-wagging. Not "invalid format" but "the IBAN has 22 characters, yours has 20." The user immediately knows what to do and doesn't feel like an idiot doing it.

One rule that almost always holds: take the word from the label and put it in the message. If the field says "date of birth," the message says "enter your date of birth" — not "required field."

6. The Most Expensive Error of All: Deleted Input

If a form discards input after an error, nothing else matters.

I've seen this repeatedly in projects, usually unintentionally, usually caused by a reload after server-side validation. The user has invested eight minutes, gets a red message and an empty form. From that point it's no longer about usability, it's about whether they come back at all.

The same goes for sessions that expire after fifteen minutes without warning, and for uploads discarded entirely because of one invalid field.

The rule: an error must never destroy work. If you take one sentence away from this whole piece, take that one.

7. Where the Message Sits and When It Arrives

Where: At the field. Not in a red box at the top that the user has to scroll up to, then scroll back down from, guessing which field was meant. On long flows, add an error summary at the top of the page whose entries link as jump marks to the relevant field. The pattern is fully documented in the GOV.UK Design System and the NHS Service Manual, including focus behaviour for screen readers — you only have to copy it. Error summary in the NHS Service Manual.

When: After leaving the field. Not while typing — anyone who sees "invalid email address" after two letters is being told off by their own software before finishing a thought. And not only on submit, because then everything arrives at once.

There's a widely cited study on the effect, by Luke Wroblewski and Etre from 2009: inline validation produced 22 percent more successful completions, 22 percent fewer errors and noticeably shorter completion times. Results at LukeW. In fairness: small sample, one form type, over fifteen years old. I cite the numbers as an indication, not a law of nature — and on a long flow I'd measure it myself anyway.

8. The Screens That Appear in No Concept

Lay out your design files and go looking for: 404. 500. Timeout. Offline. Maintenance window. Session expired. Empty state after a search with no results.

In nine out of ten projects these screens aren't there. Not because someone decided to leave them out — because nobody ordered them. They're in no flowchart, because flowcharts describe the happy path. They're in no acceptance criteria. They get generated at runtime, by the framework's default output.

That's the real finding of this article: bad error states aren't a quality problem with individual people. They're a process problem. Nobody is responsible, so it happens on the side, at two in the morning, by someone who was trying to solve a different problem.

Anyone who wants to change that doesn't need a design philosophy, they need one line in the definition of done: no feature is finished until the error case has been designed.

9. And Since the BFSG, It's Also Mandatory

The Web Content Accessibility Guidelines are quite explicit about errors:

• 3.3.1 Error Identification: a detected error must be described in text — colour alone isn't enough.
• 3.3.2 Labels or Instructions: if input requires a particular format, that has to be stated up front.
• 3.3.3 Error Suggestion: if the system knows a correction, it has to offer it.
• 3.3.4 Error Prevention: for legal and financial transactions, input must be reversible, checkable or confirmable.

Those are conformance levels A and AA — precisely what EN 301 549 and therefore Germany's Accessibility Strengthening Act (BFSG, in force since June 2025) point to. W3C quick reference.

This doesn't necessarily catch the generic server error — often there genuinely is no suggestion to make. But anything involving input, it does: a red-outlined field with no text violates 3.3.1. An "invalid input" where the system knows the expected format violates 3.3.3. Both sit in every second product I look at. At that point it's not just bad communication, it's a checkpoint you fail.

10. What You Can Actually Do

1. Collect your error messages. All of them. In one table. Most products turn out to have between 40 and 300, and nobody in the building has ever seen them together. That list alone is half a day's work and reliably raises the first uncomfortable question.

2. Sort by frequency, not alphabetically. The top ten almost always account for the bulk of the volume. Start there.

3. Build a scorecard. What happened, what about my data, what can I do, how long will it take. Four columns. Any message that doesn't answer all four gets rewritten.

4. Connect the list to your support contact reasons. This is the step that turns a design task into a business case. Most frequent contact reason times cost per contact — there's your funding request.

5. Put error states in the definition of done. Otherwise this all happens again in a year.

6. Measure afterwards. Number of contacts on that topic, before and after. Exactly one slide. That slide decides whether there's budget next time.

Why You Can Take My Word for It

I'm Tobias Adam, a freelance UX designer in Hamburg, more than ten years in digital product development.

I learned the craft agency-side, including at Jung von Matt and deepblue networks. I've worked for BMW, Audi, FIFA, Union Investment, Vodafone, OBI and Deutsche Messe, among others. Over 20 awards, including Webby, ADC and Cannes.

The awards came for the visible work. It always got interesting with the invisible kind. The VisualVest account opening in the Union Investment orbit, for instance: when something goes wrong in a regulated flow, the error message isn't a line of copy, it's the question of whether someone still trusts a financial product with their money. Or a digital future planner, so far unpublished, where the same point sat differently: how much may a system correct before it patronises?

After that it runs through everything: signups, applications, onboardings, internal systems. Error states are the part I most often write down for the first time in a project's history.

Today I work freelance and together with HC Merkle as intro.team — two freelancers for the phase where an idea becomes a testable product: concept, UX, UI, prototype, user testing. Short cycles, senior staffing, no agency apparatus.

The Short Version

1. Errors hit the users with the highest intent. The most valuable ones you have.
2. Every unclear message is a standing liability. It never gets paid off, and the amount grows with every new user.
3. "A technical error occurred, please try again later" answers nothing. Delete that sentence from your product.
4. Four questions need answering: what happened, what about my data, what can I do, how long will it take.
5. Error codes accompany the message, they don't replace it. And status codes don't belong in the interface.
6. Don't confuse user errors with your own. A rejected IBAN with spaces is your problem.
7. An error must never destroy work. No wiped forms, no silent session timeouts.
8. Message at the field, summary with jump marks at the top, validation on leaving the field.
9. 404, 500, timeout and offline belong in the concept, not in the framework's default output.
10. No feature is finished until the error case is designed. Put it in the definition of done.

A product doesn't show what it's worth when things work. It shows it in the moment they don't.

Previously in this series: forms, field count and smart defaults — B2B software and internal tools.

Sources and Further Reading

• Nielsen Norman Group: Error-Message Guidelines – nngroup.com
• Nielsen Norman Group: 10 Design Guidelines for Reporting Errors in Forms – nngroup.com
• Jakob Nielsen: 10 Usability Heuristics for User Interface Design – nngroup.com
• Gartner: cost per contact across live and self-service channels – gartner.com
• Luke Wroblewski / Etre: Testing Real Time Feedback in Web Forms (2009) – lukew.com
• NHS Digital Service Manual: Error summary – service-manual.nhs.uk
• GOV.UK Design System: Error summary – design-system.service.gov.uk
• W3C: WCAG 2.1 Quick Reference, section 3.3 – w3.org
• Barrierefreiheitsstärkungsgesetz (BFSG), in force since 28 June 2025 – bfsg-gesetz.de

Der Beitrag “A Technical Error Has Occurred.” erschien zuerst auf Intro.

The short version: Bad B2B software doesn't survive because it's good enough. It survives because its users are paid to endure it. The same goes for internal tools. The usual benchmark — "that's decent for B2B" — isn't a standard, it's proof that everyone is sitting in the same basement. Comfortable, until somebody stands up. And in Germany, incidentally, ergonomic workplace software isn't a matter of taste. It's occupational safety law.

There's a sentence I hear regularly in projects, usually from someone with budget authority, usually with a faintly apologetic smile:

"Well, it's B2B."

Meaning: it doesn't have to be beautiful here. It doesn't have to be fast. People can learn it. Different standards apply.

True, actually. Different standards do apply. Just not the ones you mean.

In consumer products, the user decides. Bad app, app gone. In B2B, procurement decides and the user gets assigned the outcome. They can't cancel, can't switch, can't even complain without sounding like they're refusing to work. They can do exactly one thing: put up with it. And at the end of the month, they get paid for that.

That's the actual business foundation of a lot of B2B products. Not quality. Compensation for pain.

Exactly the same applies to the second kind of software with no exit: the kind you build yourself. The back office for case handling. The admin panel. The reporting tool. The internal booking system that's been running "temporarily" since 2014. Bought or built is a technical distinction and economically the same case: users with no exit.

And software whose users can't leave doesn't get honest feedback. It gets acclimatisation. Those are entirely different things, though they're easily confused in a status meeting.

1. Why "The B2B Benchmark" Is the Laziest Excuse in the Industry

The reflex, when you criticise a B2B interface, is always the same: compare us to the competition and we don't look bad at all.

Except the competition isn't your benchmark. The competition is in the same basement you are.

If every vendor in a sector has been building the same overloaded screens for fifteen years, the sector average isn't a quality level. It's a collective alibi. "Better than SAP" is about as ambitious as "faster than the post office."

The real benchmark sits somewhere else. Your users aren't only case handlers, dispatchers or buyers. In the evening they're also people who book a train ticket in four seconds, transfer money in two taps and start a film in zero. They don't switch that experience off at nine in the morning. They sit in front of your screen knowing perfectly well that it can be done differently. Consumerization of IT is what the trade press has called it for fifteen years, and it describes nothing more than the expectations your users bring in every morning and have to check at your login screen.

"That's good for B2B" means, in practice: we have successfully trained our users to expect less. That isn't a position. That's a condition.

And the thing about a low bar is that it's very easy to clear.

2. The Calculation Nobody Runs

For customer-facing products, everyone runs the numbers. Conversion, cost per order, cart abandonment. For internal software, nobody does — even though the calculation is far simpler here, because the users are on your payroll.

A few numbers for scale:

Harvard Business Review, working with researchers, observed twenty teams across three Fortune 500 companies over five weeks. Result: people switched between applications and windows roughly 1,200 times a day. The pure reorientation cost added up to around four hours a week — about nine percent of annual working time. The piece at HBR.

Qatalog and Cornell University's Ellis Idea Lab found in their survey that it takes 9.5 minutes to get productive again after a tool switch — and that nearly an hour of every working day goes on hunting for information across systems. Summary at CIO Dive.

Asana's Anatomy of Work adds another layer: around 60 percent of working time goes on "work about work" — chasing status, assembling information, jumping between tools. That leaves 40 percent for the work people were actually hired to do.

Now run it roughly for your own organisation:

200 employees. Each loses 15 minutes a day to a badly designed core application — conservative, measured against the numbers above. That's 50 hours a day across the company. At 220 working days: 11,000 hours. At €60 fully loaded per hour: €660,000 a year.

Every year. Again. Without ever appearing in a presentation, because lost time doesn't have a cost centre.

Against that stands a UX project that costs you — depending on scope — a low five-figure sum, and whose effect you can actually measure: handling time per case, error rate, number of second-level support queries, onboarding time for new staff.

This is, incidentally, the most convenient business case in our field. It needs no market research. You already have all the data in-house — you've just never shown it to anyone who could do something with it.

3. Internal Tools: A Blind Spot With a System Behind It

Why does the internal application look like 2009 while the campaign site for the same product is in the awards annual?

Because internal software belongs to nobody whose bonus depends on it.

External products have a product owner, a marketing budget, KPIs and a board watching the numbers. Internal tools have a functional specification. Requirements come from the department, implementation from IT, design from nobody. There's no conversion, so there's no discussion. There are only tickets.

The typical symptoms — and I'd bet you recognise at least three:

• A screen with 60 fields, because it was "carried over from the legacy system."
• Error messages that give you a number and nothing else.
• Terminology straight out of the data model in the interface, because it was easier to name the field after the column.
• A spreadsheet maintained in parallel to the official system, because the official system doesn't reflect how the work is actually done.
• Training that exists only because the interface doesn't explain itself. Training is expensively purchased compensation for design work that was never done.
• New colleagues who still have to ask after two weeks.

That last point is the costliest and never gets attributed. If your onboarding takes six weeks because the application is illogical, you pay those six weeks on every single hire, forever, and more often as turnover rises. That isn't an HR question. That's a design flaw on subscription.

Then there's the system's silent resignation: shadow IT. When people start organising their work in private spreadsheets, WhatsApp groups and self-built tools, that isn't a discipline problem. That's a usability report. It just reaches you filed as a compliance breach.

4. A Short Legal Section, Because It Comes Up Too Rarely

If the productivity maths doesn't land: in Germany, ergonomic workplace software isn't a friendly gesture. It's an employer obligation.

The Workplace Ordinance (Arbeitsstättenverordnung) states in its annex, section 6, that when operating display screen workstations the employer must ensure the workstation is designed appropriately for the task — and that suitable software systems must be provided. It goes on to require, among other things, that software be adaptable to the knowledge and experience of employees, that it provide information about the respective dialogue steps, and that it describe errors and allow them to be corrected with limited effort. Legal text at gesetze-im-internet.de.

Read that last clause again. "Correction with limited effort." That is, at its core, a design requirement, and it has been in the law for decades — originally in the Display Screen Equipment Ordinance, since 2016 in the Workplace Ordinance.

It's given substance by ISO 9241-110, the interaction principles for dialogue systems — in the 2020 revision: suitability for the user's tasks, self-descriptiveness, conformity with user expectations, learnability, controllability, robustness against user error, and user engagement. That isn't designer poetry, that's a standard works councils and labour inspectorates can point to.

On top of that comes the risk assessment required by section 5 of the German Occupational Safety Act, which explicitly covers the design of work processes and psychological strain at work. An application that makes people fight it for eight hours a day falls squarely into that category — it just never shows up there, because nobody thinks to treat software as a work tool. It is one.

5. The Open Flank: One Competitor Trying Is Enough

Now the part that matters to vendors rather than users.

If you sell B2B software, you probably see the low bar as an advantage. It isn't. It's an unguarded gate.

Market logic has shifted. B2B purchasing decisions haven't been made by procurement alone for a long time: a typical buying group is put at six to ten people depending on the survey — and end users now sit at the table. Their criterion is always the same: is it usable? In G2's buyer behaviour research, ease of implementation, speed to ROI and ease of use sit at the top of the decision list. And here's the sentence that should actually interest you: only around 45 percent of software buyers renew without further thought — more than half actively evaluate alternatives at renewal. G2 Software Buyer Behavior.

Every renewal is therefore a small pitch, and you lose it to whoever can do the same thing while being easier to use. And because your users have been banking their frustration for years, that competitor doesn't need stamina. They need a trial account and a demo that works in the meeting.

Then there's public reviews. The days when user opinion stayed inside the company are over — it's on review platforms now, and buyers read them. Your users can't cancel on you. But they can rate you. These days that's nearly the same thing.

And for the other side, the internal one: McKinsey studied 300 publicly listed companies over five years for The Business Value of Design. Firms in the top quartile of the design index showed 32 percentage points more revenue growth and 56 percentage points more growth in shareholder returns than their peers. More interesting than the number is the distribution: there was barely any difference between the second, third and fourth quartiles. The market doesn't reward mediocrity with a bit of design on top. It rewards standing out clearly. The study.

Translated: being slightly less ugly buys you nothing. The jump only pays once it's noticeable.

6. What You Can Do Without Declaring a Transformation Programme

I'm no fan of twelve-month roadmaps for problems you can start on in four weeks. So, concretely:

1. Sit next to people. Not interviews, not surveys. Sit down and watch someone process a real case. Two days. You'll see things that appear in no ticket — sticky notes beside the keyboard, parallel spreadsheet universes, memorised click paths. It's the most honest requirements analysis there is, and it costs almost nothing.

2. Measure the top five tasks. What does the team do most often? How long does it take, how often does it go wrong? Prioritise on that. Not by volume of complaints, but by frequency times duration. The 30-second task that runs 400 times a day beats any feature at the top of the specification.

3. Take fields out. Same exercise as with customer-facing forms, only with heavier legacy. For each field: who needs this, what for, what happens without it? And no, "it's always been there" is not an answer.

4. Set smart defaults. The most common value is preselected. The current case handler is preselected. Today's date is preselected. Sounds trivial, saves seconds per case and weeks per year.

5. Give it an owner. Internal tools don't fail on capability, they fail on accountability. As long as nobody has the authority to take a field away from a department, nothing happens.

6. Make the number visible. Handling time per case, before and after. Exactly one slide. That slide decides whether there's budget next time.

Why You Can Take My Word for It

I'm Tobias Adam, a freelance UX designer in Hamburg, more than ten years in digital product development.

I learned the craft agency-side, including at Jung von Matt and deepblue networks — where ambition, enterprise reality and deadline all land on the table at once. I've worked for BMW, Audi, FIFA, Union Investment, Vodafone, OBI and Deutsche Messe, among others. Over 20 awards, including Webby, ADC and Cannes.

The awards came for the visible work. I learned the most from the invisible kind: application flows, onboardings, internal systems, signups. The VisualVest account opening in the Union Investment orbit, for instance, where regulatory disclosure requirements and a usable flow had to work at the same time. Or a digital future planner, so far unpublished, where the question was how much a system may take off the user's hands before it becomes paternalistic.

Those are the projects that win no awards and still decide whether a company works efficiently or not.

Today I work freelance and together with HC Merkle as intro.team — two freelancers for the phase where an idea becomes a testable product: concept, UX, UI, prototype, user testing. Short cycles, senior staffing, no agency apparatus.

The Short Version

1. Software with no exit gets acclimatisation, not feedback. Don't mistake that for satisfaction.
2. "That's good for B2B" is not a benchmark. Your users compare you to what they use in the evening.
3. Internal tools are the same case as bought software. Users who can't switch.
4. Do the maths on lost time. 15 minutes a day times headcount times loaded cost. That number is your funding request.
5. Training is paid compensation for missing design. So are second-level tickets.
6. Shadow IT is a usability report, not a compliance problem.
7. Workplace software ergonomics is occupational safety law, not taste.
8. The low bar isn't protection, it's an invitation. More than half your customers evaluate alternatives at renewal.
9. Half-measures don't pay. The market rewards those who clearly stand out.
10. Start with the five most frequent tasks. Not with the roadmap.

Software whose users can't walk away isn't a safe market. It's a market nobody has attacked yet.

Part one of this series looked at forms, field count and smart defaults — the same question, applied to users who very much can walk away.

Der Beitrag Your B2B Software Is Ugly. And You Know It. erschien zuerst auf Intro.

The short version: The form is the checkout counter. You've hidden it behind a door that sticks. One redundant field cost Expedia twelve million dollars a year. One changed default can double a decision rate — with zero media spend. Since June 2025 it's also a compliance question in Germany. The whole thing costs three to four weeks of design work, not a quarter. Anyone saying "no capacity right now" is really saying "we'd rather keep paying."

There's a line in almost every project plan that reads: build the form. One ticket. Maybe two person-days. Usually at the end of the sprint, usually assigned to whoever is cheapest, usually never tested.

And there's a place in almost every product where interest turns into money. The signup. The application. The checkout. The account opening.

Same place.

I've been doing this for over ten years — enterprise work, startups, internal tools, onboardings — and I've never seen a project where the form got as much attention as the homepage. Seven people will spend three weeks arguing about the hero section. Nobody argues about the field where half the users drop out.

Yet the homepage decides whether someone likes you. The form decides whether someone pays you.

This is written for the people who approve budgets. It has numbers, court rulings and sources. And one claim: form work isn't a design question, it's a revenue question. Push it to the end of the sprint and you're not moving a task, you're moving income.

1. Every Field Is a Question You Ask a Stranger

Picture someone walking into your shop. You want to sell. And before selling, you ask: first name, last name, salutation, company, second address line, phone number, fax number.

Fax. Still. I see it every year.

Nobody would do this in a shop. Almost everyone does it in a form — because a form doesn't look like a conversation, it looks like a database table. And database tables come from wherever internal wishes get collected: sales wants the phone number, marketing wants the industry, legal wants the checkbox, CRM wants it mandatory. What you end up with is a form that reflects the needs of eight departments and not a single customer.

That's expensive. Measurably.

Expedia. The most-cited example: the booking form had a "Company" field. Plenty of customers typed in the name of their bank — and then, on the line below, the bank's address instead of their own. Credit card address verification failed, the booking collapsed. Expedia deleted the field. The result, according to their then-VP of Analytics: roughly $12 million in additional annual profit. One field.

The $300 million button. Jared Spool describes a major retailer whose checkout opened with a wall: log in or register. New customers wanted to buy, not get married. The team replaced "Register" with "Continue" plus a note that no account was needed — everyone calls that guest checkout now, back then it was an affront to the CRM department. Purchases rose 45 percent, the first month brought in an extra $15 million, the first year $300 million. The same analysis found 45 percent of customers had registered multiple times, and that the system was fielding around 160,000 password requests a day. The original 2009 piece is still online.

The average. The Baymard Institute has been measuring checkouts for over a decade. Their benchmark: an average checkout presents around 23.5 form elements, of which roughly 15 are actual input fields — about eight would do. Baymard considers a 20 to 60 percent reduction achievable for most shops. Average cart abandonment has hovered around 70 percent for years, and a large share of that is fixable: Baymard puts the conversion upside from checkout usability alone at over 35 percent.

The public sector can do this too, by the way. The UK's Government Digital Service didn't digitise the Carer's Allowance claim — they took it apart. Result: 170 questions removed, nearly half the form. Completion rates afterwards ran above 80 percent, above 90 for returning users.

The point isn't that fewer fields look tidier. The point is that every field has its own drop-off. You've been paying for it for years — you just can't see it, because it doesn't sit in any cost centre. No controller notices money that never arrived.

2. Defaults: The Strongest Lever Nobody Budgets For

If cutting fields is the obvious optimisation, defaults are the invisible one.

A default is the answer your form gives when the user does nothing. And most users do nothing. That's not laziness, it's economics: someone filling in a form wants it over with. Whatever is already there gets read as "probably correct" and as "probably recommended."

The study behind this is a classic by now. Eric Johnson and Daniel Goldstein published work in Science in 2003 asking why organ donation consent rates across European countries differ by almost an order of magnitude — with similar cultures, similar infrastructure, similar religion. The difference wasn't conviction. The difference was the checkbox. In opt-out countries consent sits near 100 percent; in opt-in countries it lands in the low double digits. In their own online experiment, consent was around 82 percent under opt-out and around 42 percent under opt-in — identical question, identical people, different default. "Do Defaults Save Lives?", Science 302, 1338–1339.

Note the magnitude: one checkbox roughly doubled the decision. No copy test, no redesign, no campaign budget gets near that. Behavioural economists call it choice architecture. You call it "that's just how the developer set it."

Why it works is well understood:

• Effort. Every change costs a click and a decision. Both are more expensive than they look.
• Recommendation. People read a preset value as advice from the provider. "They probably know what's normal."
• Status quo. Taking something away feels worse than never having had it. That applies to a checkbox too.

So if your product has a default, you are making a decision on behalf of a substantial share of your users. The only question is whether you're doing it deliberately or whether it came with your framework.

Which is the sentence I say most often to project leads: You don't get to choose whether you set defaults. You only get to choose whether you design them.

3. Smart Defaults: The Hypothesis About Your Users

The term of art is smart defaults — preset values derived from data, context and device rather than from someone's gut. The emphasis is on smart. A default nobody derived isn't a smart default, it's a value from the documentation of a framework that has never met your customers.

Because a default is always a claim: this is what our typical user looks like. Fail to test the claim and you don't save work — you just move it. From your team to your customer.

A few examples from practice, all real, all seen more than once:

The country field. Alphabetically sorted, Afghanistan on top. If the vast majority of your customers are in one country — and in most projects I see, they are — then that majority scrolls past eighty countries on every order. Check your own numbers before you file this under trivia.

The salutation. In Germany this stopped being a matter of taste and became a legal one. The Frankfurt Higher Regional Court ruled in 2022 that a booking form forcing a choice between "Mr" and "Ms" discriminates against non-binary people (case 9 U 92/20); the Federal Court of Justice dismissed Deutsche Bahn's appeal in 2024. Summary at beck-aktuell. But the more honest question is whether you need the salutation at all. If it exists purely so a mail merge can write "Dear Mr", you've built a mandatory field with litigation risk in order to save yourself one line of template text.

The amount. For savings plans, donations and subscriptions, the preset amount is the single most consequential number on the page. Too low and you leave volume on the table. Too high and you lose the people who don't dare to correct it. That number should be derived from your existing data, not from a product manager's instinct.

The payment method. Usually preselected as the one with the lowest fees for you. Rarely measured for what it costs you in abandonment.

The newsletter checkbox. More on that shortly.

The second address line. Needed by one percent of your users. In the way of a hundred percent. Belongs behind a link — that's progressive disclosure, and it costs you precisely nothing.

And the field you think is a preset. Placeholders aren't defaults, but they get treated as such — and far too often they replace the label. The Nielsen Norman Group said this plainly back in 2014: placeholders in form fields do more harm than good. The moment someone types, the hint is gone. Anyone scrolling back to check their answers sees values without labels. For people with visual or attention impairments it's simply a barrier.

Designing for your audience means answering one concrete question: who is the majority, and what is right for the majority? Not: what's convenient for us. And definitely not: what was preselected when we bought the template.

That question is answerable. Existing data, five to eight user tests, a look at the support call log. No fundamental research, no study, no institute. One week of work. You spent longer than that discussing a logo last year.

4. Where the Default Ends and the Dark Pattern Begins

Short section, but a necessary one, or I'll be misread.

Defaults are powerful. Which is exactly why they're regulated.

In 2019 the Court of Justice of the European Union ruled in the Planet49 case that a pre-ticked box is not valid consent (C-673/17); the German Federal Court of Justice confirmed this for Germany in 2020 (I ZR 7/16). Summary at vzbv. Anyone still working with pre-ticked consent isn't optimising, they're collecting legal exposure.

The test I use is simple:

Who benefits from this default if the user doesn't notice it?

If the user benefits, it's good design. If only you benefit, it's a dark pattern — a design that works only as long as nobody is paying attention. The difference between "standard shipping preselected" and "travel insurance preselected" isn't a nuance. One is service, the other is fraud in corporate colours.

And the side effect your finance people will love: deceptive defaults produce cancellations, complaints and support calls. They pull revenue forward and push cost backward. That's not a business model, that's a bow wave with a quarter's delay.

5. Since June 2025 This Isn't a Nice-to-Have Anymore

If the revenue arguments don't land, there's now also a law.

Germany's Accessibility Strengthening Act (Barrierefreiheitsstärkungsgesetz, BFSG) came into force on 28 June 2025, implementing the European Accessibility Act. It covers, among other things, e-commerce services aimed at consumers: online shops, booking flows, contact forms, payment processes, apps. The benchmark is EN 301 549, which in turn points to WCAG 2.1 AA. Fines up to €100,000, plus competition-law warnings. Micro-enterprises are exempt for services.

And what's typically inaccessible about a form? Exactly the things this article is about: missing labels or labels disguised as placeholders, error messages with no connection to the field, required fields marked by colour alone, time limits, blocked autofill, focus orders that jump around.

Put differently: the form overhaul you should be doing for conversion reasons has, for a year now, also been the compliance task you have to do anyway. Two arguments, one budget line. That's rare. I wouldn't overthink it.

And no, a bought-in accessibility overlay is not a solution. It's an invoice with a calming function.

6. What I Actually Do in These Projects

So this doesn't read as principle-mongering, here's the process I run in form projects. It's unspectacular, and that's the point.

1. Field audit. Every field on the table, and one question per field: who needs this, what for, and what happens if it's missing? In my experience a third drops out immediately and another third moves behind a link or into a later step. The hard part isn't the analysis. It's the conversation with the department that ordered the field.

2. Data need versus data cost. Every piece of information you request has a price in abandonment and a second one in data protection obligations. A field that's just "nice for the CRM" is never free.

3. Derive smart defaults, don't guess them. Look at the distribution in your existing data. What do 80 percent choose? That becomes the preset — as long as it doesn't harm the user. Where the distribution is flat, there is no default, there's a deliberate choice. "Let's just take the first one" isn't derivation, that's rolling dice in a nicer typeface.

4. Errors as a design task. Messages at the field, in plain language, with a fix. Validate on leaving the field, not while typing. And never delete input. A form that punishes you doesn't get filled in twice.

5. Test with five people from the actual audience. Not colleagues. Colleagues know the vocabulary. That's precisely the problem.

6. Measure. Per-field drop-off, error frequency per field, time in field. Forms are one of the few design artefacts whose impact can be quantified cleanly. That's your best shot at defending design work internally.

Concretely, this came up for me in the VisualVest account opening, the digital investment offering in the Union Investment orbit. Opening an investment account is the hard case: regulatory weight, lots of mandatory information, identity verification, risk profiling — and still a flow at the end of which someone either invests money or doesn't. Every preset becomes a question of trust there, because a preset amount or a preselected risk profile isn't neutral, it reads as advice. If you set a default in that context, you'd better be able to justify it.

A second project — a digital future planner, so far unpublished — came down to the same question from the other direction: how much can a product decide on the user's behalf before help turns into paternalism?

The rest runs as detail work through nearly every project I do: signups, onboardings, applications, contact flows. Not spectacular. But it's where products are won or lost.

7. The Business Case That Gets This Approved

The most common response to good form work is: "we don't have capacity for that right now." So here's the calculation to put in front of your decision-makers.

Say 50,000 people start your form each year and 60 percent complete it. That's 30,000 completions. You improve completion by five percentage points to 65 — conservative, measured against the numbers above. That's 2,500 additional completions. At €80 contribution margin: €200,000.

On the other side: field audit, redesign, two rounds of testing, implementation support. Realistically three to four weeks of design work.

What you actually need to approve, if you want the line item spelled out:

• one to two days for the field audit, including the conversations with sales, legal and CRM
• access to your existing data — without it, defaults stay opinion
• two rounds of testing with five people each from the real audience, not colleagues
• implementation support, so the decisions don't evaporate into tickets
• one person with the authority to decide which field gets cut

That last point matters most. Form projects almost never fail on design. They fail because nobody is authorised to take a field away from a department.

And one cost block that gets forgotten: every abandonment that lands in your service centre costs a phone call. Every unclear error message produces tickets. Every duplicate account pollutes your CRM and gets expensively cleaned up in a migration project later. Bad forms aren't only a revenue problem. They're an operating cost problem with a long half-life.

Why You Can Take My Word for It

I'm Tobias Adam, a freelance UX designer in Hamburg, more than ten years in digital product development.

I learned the craft agency-side, including at Jung von Matt and deepblue networks — the place where ambition, enterprise reality and deadline all land on the table at once. I've worked for BMW, Audi, FIFA, Union Investment, Vodafone, OBI and Deutsche Messe, among others. Over 20 awards, including Webby, ADC and Cannes.

What interests me about forms is exactly what makes them useless for awards: they're the most honest part of a product. A homepage can claim you're user-centred. A form shows whether it's true.

Today I work freelance and together with HC Merkle as intro.team — two freelancers for the phase where an idea becomes a testable product: concept, UX, UI, prototype, user testing. Short cycles, senior staffing, no agency apparatus. And yes, it's about forms more often than average.

The Short Version for Your Next Sprint

1. Count your fields. Cut every one nobody can name a purpose for. Today, not "in the next release."
2. Don't ask for anything you can derive. City from postcode, card type from the number, salutation mostly not at all.
3. Set defaults deliberately. They're the answer for the majority of your users, whether you like it or not.
4. Make them smart defaults. Derived from data, not from meetings.
5. Test every preset with the benefit question. Who does it help when nobody's looking?
6. No placeholders instead of labels. Ever. Not even when the mockup looks tidier.
7. Errors at the field, in plain language, with a way out. And never delete input.
8. Allow autofill and use correct input types. An afternoon's work, immediately noticeable on mobile.
9. Test with five real users before you ship. Five. Not fifty, not zero.
10. Measure per field. Without numbers, every form discussion is a taste discussion — and those are won by whoever has the bigger title.

Forms aren't a detail. They're the checkout counter. And yours sticks.

Sources and Further Reading

• Johnson & Goldstein: Do Defaults Save Lives?, Science 302 (2003) – science.org
• Jared Spool: The $300 Million Button (2009) – articles.centercentre.com
• Baymard Institute: Checkout Optimization – Minimize Form Fields – baymard.com
• Baymard Institute: Cart Abandonment Rate Statistics – baymard.com
• Nielsen Norman Group: Placeholders in Form Fields Are Harmful – nngroup.com
• Government Digital Service: Simpler Carer's Allowance digital service now live – gds.blog.gov.uk
• GOV.UK Design System: form and question patterns – design-system.service.gov.uk
• CJEU C-673/17 "Planet49" and BGH I ZR 7/16 – vzbv.de
• OLG Frankfurt 9 U 92/20, BGH X ZR 71/22 on gender-neutral salutation – beck-aktuell.de
• Barrierefreiheitsstärkungsgesetz (BFSG), in force since 28 June 2025 – bfsg-gesetz.de
• Luke Wroblewski: Web Form Design – Filling in the Blanks (Rosenfeld Media)

Der Beitrag Nobody Wants to Fill In Your Form erschien zuerst auf Intro.