Why a Wellness Genetics Product Needed a Rewrite Before It Needed a Redesign

A wellness genetics brand came to us with an app that worked and left people flat. You could order a kit, send off a sample, and a few weeks later open the app to a full picture of how your body handles food, how it is ageing, and what you can do about it. Every screen loaded. Every number was accurate. Hardly anyone cared.

The brand promise was already right, and the product had quietly stripped the story out of it.

We were brought in to improve the emotional layer, which is the polite way of saying the product felt nothing like the brand that sold it. Our usual starting point is an audit of the whole experience, and that audit landed on the copy rather than the interface.

So the first job was a rewrite, and the redesign waited behind it. We tested comprehension before we touched anything, rewrote the narrative, pre-framed the moments where people thought the report was broken, then tested again. What follows is the order we ran it in and why that order mattered, including the part at the end where a third-party designer and an existing codebase made the handover harder than the writing.

What the Audit Actually Found

The promise the brand had built was sound. A real inside look at how your body works, how it is ageing, and what you can do to improve it. That is a good promise, well constructed, and people were paying for it. Nothing in the audit suggested changing it.

The product was the problem. It had been built largely by a development team, and the storytelling had gone out of it in favour of functional delivery. People were reading their own genetic data and feeling nothing about it, which showed up directly in retention. A product about your own body should be hard to put down.

What the audit flagged, in rough order of damage done:

• A brand promise that the product never repeated back to the user
• Copy that described the data instead of explaining it
• Too much content arriving on screen at once
• Results that people read as mistakes in their own report
• No sense of who you were inside the product

That last one did most of the damage. People had paid to find out something about themselves and the app gave them values without ever giving them an identity to attach the values to. So the decision we took was to put the narrative back and let people see themselves in their results, rather than redesigning a promise that already worked.

Why a Developer-Built Product Loses Its Story

The development team built exactly what the brief described, and the brief described functions. A field needs a label. A screen needs a title. A result needs a line of text underneath it saying what the result is. Each of those decisions is reasonable on its own, and the sum of them is a product with no voice.

Copy written that way gets written last, by whoever is nearest to the ticket, under time pressure, with no reference back to how the brand speaks anywhere else. Nobody sets out to flatten the story. It just gets flattened one label at a time, and because every label is accurate, nothing in the build process flags it.

On the genetics product this showed up most clearly in the results section, which is where the emotional weight of the whole thing sits. Someone has waited weeks. They have thought about what the test will say. Then the screen tells them a number and moves on.

Data on its own does not hold anyone. People connect to what the data means about them, and that meaning has to be written down by somebody. If no one writes it, the product is functional and forgettable, and the retention numbers follow.

The Gap Between the Packaging and the App

The brand's packaging and online presence were luxurious and aspirational. Becoming a better version of yourself. Reaching your full potential. Everything about the physical product and the marketing around it was pitched at who you were about to become.

Then you ordered a kit, did the test, waited, and opened the app.

The packaging promised a better version of you and the app delivered cold, clinical data.

It was a jarring experience, and the jarring bit came at the worst possible point in the journey. Everything up to that moment had been building. The kit arrives nicely boxed, the sample goes off, the waiting does its own work on your expectations. Then the one touchpoint carrying the actual answer speaks in a completely different voice from everything that got you there.

That mismatch is expensive because it is invisible in any single review. Look at the packaging and it is beautiful. Look at the app and it is competent. Put them end to end as a person experiences them and the whole thing breaks at the handover. We tend to walk the full sequence in order, physical and digital together, because the gaps only show up when you do.

Measuring Comprehension Before Touching the Design

Before we rewrote a single screen we ran focus groups and five-second tests on the product as it stood. We measured comprehension and clarity, which means we asked people what they had just looked at and what they thought it meant about them.

Comprehension came back low. Two things were driving it. There was a great deal of content on screen, so people were reading everything and holding onto nothing. And the product let people fall into what they experienced as error states, where a result did not match what they believed about themselves and they assumed the report was wrong.

Running the test first does two jobs. It gives you a baseline, so the second round of testing means something rather than being a round of opinions. It also settles arguments later. When a client prefers one version and the testing prefers another, a measured starting point is the only thing in the room that is not somebody's taste.

Run your comprehension test on the live product before you brief any changes. A baseline you collected after the redesign started is not a baseline, and without one every later result is arguable.

The tests were cheap and fast. Five seconds on a screen tells you what someone takes away when they are not trying hard, which is how people actually read a results page.

Pre-Framing Error States Instead of Fixing Them

The most useful change we made on the genetics product was not a better error message. We stopped the error from happening in people's heads at all.

Someone reads a result about how their body handles caffeine, or how fast a certain system ages, and it does not ring true for them. Left alone, they decide the report is wrong, and from that point every other result is suspect too. So we rewrote the copy around those results to say the variation was expected before anyone saw it. Everyone is different. This is normal. Here is why your result sits where it does.

Written that way, the surprise becomes part of the story rather than a fault in the product. The Baymard Institute found that 98% of sites, 2024 do not use specific, adaptive error messages that say exactly what is wrong and how to fix it, which tells you how weak the recovery layer usually is. Better to not need it.

We used the same thinking years earlier on a financial application that was heavy with information and quietly full of anxiety, depending on what people were saving for or spending on. Education carried the fix there too. Frame what someone is about to see, tell them where they are, and the feeling changes before the data arrives.

Calibrating Medical Language for Anxious Readers

Anyone opening a genetics product is already carrying some anxiety. They have paid to be told something about their body that they cannot unlearn. The language you meet them with sets how that lands.

The band you have to hit is narrow. Go too simple and people stop trusting the product, because simple language reads as though there is no real science underneath it. Go too medical and people switch off and do not finish. Both failures look like disengagement in the data and they have opposite fixes, which is why guessing is a bad idea.

Our plan was plain language and real-world analogies as the first layer, with the medical and scientific depth sitting underneath for anyone who wanted it. The client preferred full medical detail as the default, reasonably enough, since that is where their credibility came from. User testing supported stripping it back. Comprehension went up, anxiety came down.

Genetics content has a long habit of pitching high. An analysis of direct-to-consumer genetic testing websites published in PMC, 2010 put their mean SMOG readability level at 14.7, a post-secondary reading level.

Write the first layer for someone reading it on their phone, slightly worried, on their lunch break. Keep the depth one tap away for the person who wants to check your working.

Introducing the Science After Understanding, Not Before

We went into this product assuming science early meant credibility early. More references, more mechanism, more proof of rigour. Testing said the opposite.

When we led with the science, credibility dropped. People could not follow it, and what they cannot follow they cannot trust. The rigour we were showing off read as a wall.

People do not trust what they cannot understand, however correct it is.

So we reordered it. Give people the result in plain terms first, let them understand what it means for them, then bring the science in behind it as confirmation of something they already grasp. In that order the science does what we originally wanted it to do. It backs them up rather than testing them.

This is layering rather than cutting. Oversimplifying is the common mistake, where a team reduces cognitive load by deleting content and ends up hiding things people need. Progressive disclosure gives you both. The person who wants the mechanism, the marker, the paper, can go and get it, and the person who wants to know whether to change their breakfast gets an answer in one sentence.

Depth matters because it is rare. In that same analysis in PMC, 2010, only 38% of these sites provided scientific evidence for the markers they tested. Having it available is a real advantage, as long as it is optional.

What the Second Round of Testing Showed

After the rewrite we ran a second round of focus groups and user testing against the same measures. The changes themselves were subtle. A reframed sentence here, a result explained before it appeared, a narrative thread running from the first screen to the last. The movement in the scores was not subtle at all.

Purpose was the one that mattered most to the brand. People in the first round could tell you what a screen said. People in the second round could tell you why they were being shown it and what they were supposed to do next. That is the difference between a report and a product you come back to.

Nothing in the visual design had changed at that point. Same layouts, same type, same colours, same build. All of the movement came from the words and the order they arrived in, which is worth sitting with if your own fix is currently scoped as a redesign.

Handing the Rewrite to the Design and Development Teams

This is the part of the project that cost the most time, and none of it was writing.

Our work went to the client, and a third-party designer in between turned it into visuals. What came out looked genuinely luxurious, which was the point of the exercise. Then it reached the development team, who had a functional existing codebase and no clear sense of how that new interaction layer sat on top of what they already had. There was considerable back and forth before it worked.

Putting a new interaction and emotional layer over existing code is possible. It needs careful management, and every extra person between the intent and the build adds distance. Our designs went through someone else before they reached the people implementing them, so the reasoning behind each decision had to survive two handovers instead of one.

Get a developer from the existing codebase into the room when the new design is being reviewed, not when it is being handed over. Ten minutes of their time at review saves weeks of rework.

What travels best through a handover is documentation that explains feeling rather than layout. We produce emotional arc documents mapping how someone feels at each stage of a journey, alongside brand personality documents covering how the brand talks. Those give a developer something to check a decision against when we are not there.

When a Rewrite Is the Wrong Fix

A rewrite fixed the genetics product because the underlying promise and the underlying data were both sound. Where the structure is wrong, better words paper over it.

We worked on a dating app where the client put a lot of weight on onboarding, verification and validation, and we did deep discovery there. Messaging was treated as a known quantity and built generically. The result was a product that argued with itself. All that effort proving people were real at the front door, and then a messaging feature that allowed exactly the fake, automated behaviour the onboarding existed to stop. No amount of copy in the message screen fixes that. The feature needed the same discovery the front door got.

So before scoping a rewrite, check which of these you have:

• People understand the product and feel nothing about it, which copy can fix
• People misread results as errors, which pre-framing can fix
• One part of the product undoes another, which needs discovery, not words
• The promise itself is wrong, which needs the brand looked at before the product

The genetics project was the first two. The dating app was the third. Running a rewrite on the third type gives you a nicely written contradiction.

How to Run This Sequence on Your Own Product

The order is the method. Running these steps out of sequence is how teams end up redesigning something that needed rewriting.

1. Walk the full journey in order, packaging and marketing included, and note where the voice changes.
2. Define the brand as a person first. In workshops we play a game called the dinner party, picturing the product as someone and asking how they dress and how they talk, which gives you a human benchmark to hold any line of copy against.
3. Test comprehension and clarity on the product as it stands today, using short five-second tests.
4. Find every result people read as a mistake, and write the context in before they get there.
5. Rewrite the first layer in plain language with real-world analogies, and move the medical depth one tap down.
6. Test again against the same measures before any visual work starts.
7. Hand over emotional arcs and brand personality alongside the designs, with a developer in the room.

Steps three and six are the ones people skip, because testing copy feels like a luxury next to shipping a redesign. They are also the cheapest two steps on the list. Focus groups and five-second tests cost very little against a build, and they are the only thing that tells you whether the rewrite earned its place.

Conclusion

The wellness genetics product we were brought in to fix did not have a design problem. It had a promise that worked, a development team that built the functions faithfully, and nobody left in the process to write what any of it meant to the person reading it. Putting that back raised comprehension, clarity, purpose and retention, and the screens looked the same while it happened.

If you are sitting with a data-heavy product that feels colder than the brand selling it, the question to ask is whether anyone has actually measured what people understand when they open it. Teams reach for the redesign because a redesign is visible and a rewrite is not. The rewrite is usually faster, cheaper, and the thing the redesign needs underneath it anyway.

And if the words turn out to be fine, you have lost a fortnight of testing and gained a baseline. That is a reasonable trade against rebuilding the wrong layer.

We do this work across beauty, wellness, food and drink and anywhere else people are handed information about themselves and asked to care. If something in your product feels flat and you cannot yet say why, let's talk about what your users actually understand.

Frequently Asked Questions