Product and experience engineering means building what you offer around the people who use it: following their whole visit, fixing what trips them up, and making it work for people of every ability.
Where did the orange fall?
Pick a guest and follow their day along the paper timeline. Their orange is pegged where they gave up, and it stays there.
A paper timeline of a guest’s day, with an orange pegged at each place a guest gave up
TicketsCapi
In our short film, the park is your app, website or service, the guests are your customers, the best ride is the feature you’re proud of, and an orange falling off a guest’s head is a customer quietly giving up. The paper timeline is the customer’s whole visit, step by step, and backstage is the people, systems and suppliers behind each step.
Worth knowing: A timeline like this comes from watching and talking with real customers, not from guessing at a desk.
Experts call this: customer journey map, service design
Watch · 2 min 7 sec
Rafael’s theme park has one great ride and nobody on it. Capi the capybara shows why: every guest has an orange on their head, and it falls off when they give up. A short, funny film about designing the whole visit, not just the ride.
The idea in plain words
Each one in everyday words first, then the name experts use for it.
Design the whole visit, not just the ride.
01
Customers meet every step, not just your best feature: finding you, signing in, paying, waiting, asking for help. Pin each place people give up on one timeline that every team works from, so customers are less likely to fall between teams.
Experts call this: customer journey map, service design
Worth knowing: A timeline like this comes from watching and talking with real customers, not from guessing at a desk.
02
Design for the person who struggles most and it gets easier for many others too: the ramp built for a wheelchair is used by prams, suitcases and tired feet. On screens: bigger text, read-aloud, keyboard use and clear contrast.
Experts call this: accessibility, inclusive design
Worth knowing: Guidelines help, but the real test is people using it, including disabled people. We check both, and keep checking as things change. Accessibility work supports your legal obligations, but it is not legal advice or a certificate.
03
Show two versions to real customers, each person seeing one. Once enough people have seen each version, keep the one that more people got through. Then ask why.
Experts call this: A/B testing, user research
Worth knowing: A test shows which version more people got through, not why. With too few people it can point the wrong way, so we wait for enough of them, and we also ask. What people ask for is a clue to what they need, not a list to build word for word.
04
Fix one thing at a time, build it so it works on ordinary and older phones, try it with real customers, and keep what helps.
Experts call this: product engineering, continuous discovery
Worth knowing: Small fixes add up only if someone keeps watching, so we help your team build that habit.
Every ability
Three tall steps stand in front of the queue. Each fix is built for one guest first. Switch one on and watch who else it helps, then see what the same fix looks like on a screen.
One lazy capybara, also using the ramp.
Who these fixes help: Bia in her wheelchair, a parent with a pram, a tourist with a suitcase on a weak signal, Grandpa, a man with his arm in a sling and Capi.
Ramp
In the park
A ramp beside the steps
On your screen
Every button works with a keyboard or one hand
Built first for: Bia in her wheelchair. Also helps: a parent with a pram, a tourist with a suitcase on a weak signal, Grandpa, a man with his arm in a sling and Capi.
Experts call this: accessibility
Big, clear signs
In the park
Big signs with strong contrast
On your screen
Bigger text, clear contrast, plain words
Built first for: Grandpa. Also helps: a boy squinting at a phone in bright sun and Capi.
Experts call this: inclusive design, content design
Read-aloud
In the park
A sign that speaks when you press it
On your screen
Screens that work properly with screen readers
Built first for: a woman who is blind and uses a white cane. Also helps: Grandpa and a boy squinting at a phone in bright sun.
Experts call this: screen readers, assistive technology
Works on old phones
In the park
A pay screen that doesn’t spin
On your screen
Steady on older phones and weak signals
Built first for: a girl on an old phone. Also helps: a tourist with a suitcase on a weak signal.
Experts call this: performance
Worth knowing: Guidelines help, but the real test is people using it, including disabled people. We check both, and keep checking as things change.
Worth knowing: Accessibility work supports your legal obligations, but it is not legal advice or a certificate.
Fair tests
At the fork a coin sends each guest one way: to Rafael’s singing mascot, or to a plain arrow. Add more guests and watch the board.
Too early to tell. And two of those were the same capybara.
Then ask why
Why did you give up?
Tiny print scared me.
Also… hot tub, please?
Experts call this: A/B testing
Experts call this: user research
Worth knowing: A test shows which version more people got through, not why. With too few people it can point the wrong way, so we wait for enough of them, and we also ask.
Worth knowing: What people ask for is a clue to what they need, not a list to build word for word.
Sounds familiar?
If two or more of these ring true, the trouble is probably not your best feature.
Seven quick questions. Answer for one journey your customers take.
Answer a question to see where we would look first.
Your answers stay on this page.
Nothing you choose here is stored or sent anywhere unless you email it yourself.
What we help with
Eight pieces of work. Start with the one journey your customers find hardest, or bring them together.
Every step a customer takes, seen through their eyes.
A clear list of where people get stuck, in their own words.
With their permission, we watch and talk with real customers as they use your product, and read what your support team and your numbers already show.
Experts call this: user research, product discovery
One shared timeline of where people give up, and which backstage fix to try first.
Every step a customer takes across app, website, phone and shop, with the people, systems and suppliers backstage at each step.
Experts call this: customer journey map, service blueprint, service design
Also in this area
Clear for the person who struggles most, and easier for many others.
A fix list in order of what matters most, and accessibility built into how new work is made.
We review screens and steps against the published accessibility guidelines and with people who use screen readers, magnifiers, voice control or a keyboard only, then fix what we find. Guidelines help, but the real test is people using it, including disabled people. We check both, and keep checking as things change. Accessibility work supports your legal obligations, but it is not legal advice or a certificate.
Experts call this: accessibility review, WCAG, inclusive design
Screens and words tried with real customers before they are built.
Layouts, buttons, forms and wording that speak the customer’s language, show what is happening and make it easy to go back.
Experts call this: UX and UI design, content design
Ideas checked with people before the big build.
Rough pretend versions tried with small groups of real people, round after round, keeping what works and dropping what doesn’t.
Experts call this: prototyping, usability testing
Also in this area
Fixes built properly, not painted over.
Screens that match from team to team.
One shared set of buttons, patterns and rules, with owners, so every team’s screens match and accessibility is built in from the start.
Experts call this: design system
A steady habit of small fixes, checked with real customers.
We build web and mobile products in small steps, keep them steady on ordinary phones and slow connections, add AI only where it solves a real customer problem with a clear way to reach a person, and keep watching after launch. Small fixes add up only if someone keeps watching, so we help your team build that habit.
Experts call this: product engineering, performance, continuous discovery
Also in this area
Count fairly, ask why, keep watching.
Design arguments settled by what customers do, then explained by asking them.
Fair tests where each customer sees one version, with switches that show a new version to a few people first, and agreement up front on what “better” means. A test shows which version more people got through, not why. With too few people it can point the wrong way, so we wait for enough of them, and we also ask.
Experts call this: A/B testing, experimentation, feature flags
Also in this area
For your technical team: we work with what you already use, for example Figma, React, React Native, Flutter, Optimizely, GrowthBook, LaunchDarkly, Amplitude, axe and Lighthouse.
Ways to start
A ride-along and a timeline of one customer journey, with the places people give up marked and the backstage behind each one.
An accessibility review of one key journey with people and against the published guidelines, a fix list in order, and the first fixes built. Accessibility work supports your legal obligations, but it is not legal advice or a certificate.
One fair two-version test on a step customers find hard, with “better” agreed first. A test shows which version more people got through, not why, so it is followed by conversations that ask why.
How we work
Five steps in plain words, from the first ride-along to your team carrying on.
Follow
With their permission, we watch and talk with real customers through one journey, and read what support and your numbers already say.
Pin
We set out the whole visit and its backstage on one timeline, mark where people give up, and agree with you what “better” means before anything changes.
Try
We try rough pretend versions of the fixes with small groups of real people, keep what works and drop what doesn’t.
Build
We build the chosen fixes in small steps, accessible from the start, steady on ordinary phones, and shown to a few customers first where a fair test helps.
Keep watching
We watch again, fix the next place people give up, re-check accessibility, and hand your team the timeline, building blocks and habits to carry on. We work with your teams one journey at a time. We describe how we work, not a promised result.
Where it fits
Illustrative examples, not customer stories: the kind of work this approach suits.
Good to know
Plain answers to what owners and tech leads ask first. Something else on your mind?
Ask us directlyBuilding your app, website or service around the real people who use it: following their whole visit, fixing what trips them up, making it work for people of every ability, and improving it step by step.
Looks matter, but this is mostly about whether people can get through. A beautiful screen that people give up on is not doing its job.
No. We start with the one place where customers give up most often and fix that first. A big rebuild is rarely the right first step.
We watch them use it, talk with them, and read what your support team and numbers already show. What people do counts as much as what they say, and what they ask for is a clue to what they need.
It starts there, and it helps many others too: someone in bright sun, with an arm in a sling, with older eyes or on a slow phone. Guidelines help, but the real test is people using it, including disabled people. We check both, and keep checking as things change. Accessibility work supports your legal obligations, but it is not legal advice or a certificate.
Where a fair test fits, each customer sees one version, and we wait until enough people have seen each version before deciding. A test shows which version more people got through, not why. With too few people it can point the wrong way, so we wait for enough of them, and we also ask.
Yes. We join your teams, use the tools you already have, and leave behind the timeline, building blocks and habits so your people can carry on.
Only where it solves a real customer problem. We try it with customers like anything else, and make sure there is a clear way to reach a person when it gets things wrong.
Heard it before?
Answer: They will tell you what they want, which is a clue to what they need, not the same thing. Watch what they do too: she asked for a hot tub, she needed a ticket.
Answer: It is easier to build in from the start than to bolt on at the end, and the people it helps first are rarely the only ones it helps.
Answer: With a handful of people a test can point the wrong way. Agree on what better means, wait for enough people, then ask why.
Answer: A fresh coat of paint over the same confusing gate changes little. Small fixes, checked with people and kept up over time, do more than a one-off makeover.
Answer: It is mostly about whether people can finish what they came to do.
Answer: Customers cross every team’s patch in one visit. One shared timeline helps stop them falling between teams.
Tell us about one journey your customers find hard. We’ll suggest where to start, and we’ll walk it with your team.
Or write to contact@algoshred.com
