Product design · iOS app
Listen to the page.
Keep your place.
ReadHalo is an iOS app designed to make listening to an article feel connected to the page — marking what's being spoken, and helping you stay oriented as the article moves.
Read-aloud works.
Following along doesn't.
I like listening to long articles while I do something else. My phone can already do this. Safari and Chrome both read pages aloud.
So I used them. And I kept giving up.
Not because the voice was bad. Because every time, I had to hunt for the word being read.
The spoken content isn't marked
Nothing on the page shows which sentence, or which word, is being read. The audio and the article run in parallel — never together. The voice knows exactly where it is. The interface doesn't say.
The page doesn't stay with the voice
The article sits where you left it. Once the reader moves past the bottom of the screen, you're looking at one thing and hearing another — and the only way back is to guess and scroll.
Listening to an article isn't like listening to a podcast. Your eyes are still in it — catching a name, re-reading a number, checking a heading. That's the part the built-in readers don't account for.
The read-aloud feature
wasn't missing.
The following-along was.
The obvious move is to build a better text-to-speech app. I think that's the wrong problem — phones already carry decent voices, and a separate app means moving the article somewhere else first.
What I wanted wasn't better speaking. It was a working link between three things that read-aloud keeps apart.
Audio
The voice knows exactly which sentence and which word it is on, the whole time. That information already exists.
The spoken word
On screen it looks identical to every other word. Nothing separates what is being said right now from what was said a minute ago.
Your position
So you hold the place in your head — and lose it the second you look away. That's the gap ReadHalo is built to close.
What it decided
Not a separate reading app you paste links into — an extension, working on the page that's already open. The design effort goes almost entirely into one interaction. And it has to work on pages I will never see.
Two highlights, and a page that follows along.
This is the main idea of ReadHalo. Everything else is built around it. Here's what I decided, and why.
A little company for your reading. Hear the words, follow along, stay on the page. Tap any sentence to begin there.
Highlight both the word and the sentence
Why: The word alone jumped too fast to follow. The sentence alone didn't show where the voice was. Together, you get both.
Use one colour in two shades
Why: Two colours made the page look like a marked-up document. One colour looks like a single highlight with a focus inside it.
Scroll the page for the reader, until they scroll
Why: Readers shouldn't lose the sentence. But the moment they scroll, the page is theirs again.
Let the reader choose the colour
Why: I tried amber, then green. No single colour works on every article, so the choice goes to the reader. The two shades stay the same, whatever colour they pick.
Pick a ring to see what it is.
Scrolling pauses the follow, not the voice.
Decision: When you scroll, the page stops following, but the voice keeps reading. A Resume following button appears. Tap it, and you're back at the sentence.
Why: If the page kept following, it would snap back every time you looked away. If scrolling stopped the voice, you'd have to find play again just to check a heading. This way you can look around without losing your place.
This is the decision I'd defend hardest.
Pick a ring to see what each part is doing.
Before refining the visual language, I worked out how the thing should behave.
Pen and paper, kept as they were. Structure first — colour, type and polish came a long way after.
Two things came out of these that survived into the product. The first is that onboarding should be one idea at a time, with the Settings errand at the end rather than the front. The second is the speed slider running 0.5 to 2.5 — it was there in pen before it was anywhere else.
What changed most is the settings page. On paper it was one long form with everything on it. In the product it broke apart, and the preview stopped being a box on a page and became the practice article.
A product built to stay out of the way of its own best idea.
Three groups of decisions: how you control it, who reads to you, and where it's allowed to appear at all.
Controls & pace
Make play big; keep voice and speed small.
Why: Pausing is the one thing you need right away, like when someone talks to you. You set voice and speed once.
Show the speed on the button (1.25×), not the word "Speed".
Why: You see the current speed without opening anything.
Offer presets and a slider.
Why: Most people want a common speed in one tap. Some know their exact speed.
Label the ends unhurried and brisk, not slow and fast.
Why: Speed is a reading style, not a machine setting.
Pick a ring to see the reasoning.
Setup
The app is there to set up the Safari extension.
On iOS, a Safari extension has to come inside an app. So the app's main job is to explain ReadHalo and help you turn it on.
Explain first, ask for Settings last.
Why: Nothing works until it's turned on in Settings, so people need a reason to go there.
Show "1 of 4" at the top.
Why: People know how long setup takes before they start.
I wasn't designing the page.
I was designing around it.
ReadHalo runs on other people's articles. I don't control the page, the layout, or the browser. So every decision had to work on pages I've never seen.
The article isn't mine
Every site looks different. The highlight has to look right on all of them.
Shaped Decision 01
The page height isn't mine
Sticky headers and pop-up banners move things around. Keeping the sentence on screen works differently on every site.
Shaped Decision 01 and Decision 02
The scroll belongs to the reader
Auto-scroll is only borrowed. The reader can take it back anytime.
Shaped Decision 02
The browser owns the frame
My controls have to sit where Safari's toolbar and menus won't cover them.
Shaped the controls
The platform owns the voices
ReadHalo uses the voices already on your phone. No account, no limits, and it works right away.
Shaped Setup
Permissions shape the first run
You choose which sites ReadHalo can use. The design assumes you haven't said yes yet.
Shaped Setup
I wasn't designing for a handoff.
I was designing alongside implementation.
A highlight that looks right in a file can behave completely differently on a real article. The only way to know is to hold it.
Design the behaviour, not the screen
What it does over time, and what it does the moment the reader interrupts it. Most of ReadHalo's decisions are about time, not layout.
Check what's actually reliable
Some things are possible but unpredictable across pages. Those turn out to be design problems, not engineering problems.
Use it on real articles, on a real phone
On pages I hadn't picked in advance. This is where most of the useful feedback came from.
Change the design, not the expectation
When something didn't hold up, the answer was a different interaction — not pushing to force the original one through.
One that went round twice
Onboarding, second pass
The clearest case of the loop above producing something different from what I first drew.
What I built first. A single page that listed the Settings steps, offered a practice article, and kept a troubleshooting note below. Everything the person needed, in one place.
What was wrong with it. It opened with admin. The first thing anyone saw was a three-stop errand through iOS Settings, before they had any reason to believe the errand was worth it. The practice article — the one thing that could have made the case — sat underneath the instructions.
What I changed. I split it into four screens and inverted the order. Three screens explain and show the highlight working, in an illustration that needs no permissions. The Settings steps became the fourth and last screen, at the point where someone has already decided.
The content barely changed. The sequence did all the work.
The product is live in my own hands and still moving.
None of this is built yet. It's where the work is going next.
- 01
Let people choose the highlight colour
The mark sits on top of an article I'll never see, read by someone whose eyes aren't mine. Amber then green was me guessing twice. The structure — one pale level, one strong level — should stay mine; the hue shouldn't.
- 02
The controls sitting on top of content
The cluster floats over the article, and on some pages it lands on something — a comment count, a footer, an image. I want it to move out of the way rather than be placed and hoped for.
- 03
Premium voices without losing the free path
They're the clearest quality gap and the easiest way to spoil what's good about the product. The question is how to offer them without making everyone else feel like they're on a trial.
- 04
Setup friction
I can't change the browser's path, but I can keep rewriting the steps around the point where people actually fall off it.
- 05
Page compatibility
Long documents, newsletters, unusual layouts. Each one breaks the highlight in its own way, and each one makes it more durable.
- 06
Keeping your place between sessions
ReadHalo holds your position while you're reading. Holding it until tomorrow is the obvious next step for something whose whole line is "keep your place".
- 07
Putting it in front of other people
Everything here comes from designing it and using it. The next real test is watching someone who isn't me set it up and read something.
Read-aloud was never the missing feature. Knowing where you are was.
ReadHalo is still being refined — what's shown here is current, not final.