Designing the Ideal User Experience

Most UX process starts one step too late — after a concept has already been chosen. Blue-sky thinking is the step before that: an unconstrained look at the actual problem, before anything gets narrowed down.

What blue-sky thinking actually is

It’s thinking without practical limits — budget, feasibility, “how things are usually done” — set aside on purpose, so ideas can be judged on merit before they’re judged on constraints. The point isn’t that every idea survives contact with reality; it’s that you generate a wide enough pool of genuinely different ideas that the good ones don’t get filtered out before they’re even considered.

In practice, that means questioning the brief itself, not just the solution; deliberately generating more ideas than feels comfortable; and holding off on feasibility questions until after an idea has been properly explored, not before.

A case study: rethinking the health app brief

At Career Foundry, I tutored students who each picked one of four project briefs — one was always a health app. Every single one opened the same way: “people are too busy and stressed.” Nobody questioned it, and nobody dug into why.

That’s exactly the kind of assumption blue-sky thinking is for. Being busy and stressed is a symptom — the more interesting question is what’s actually causing it, and whether the product should treat the symptom or the cause. For a remote worker, for instance, losing a commute can hand back two or three hours a day. What a design does with that time — and whether it even acknowledges it exists — is a genuinely different starting point than “reduce stress with reminders.”

Design for how people actually behave, not how you’d like them to

Four patterns show up constantly in early-career UX, and all of them are easy to fix once you see them:

People won’t enter data they don’t have to. If a design asks time-poor users to log meals, workouts or moods manually, most of that data simply won’t get entered. Wearables, calendars and photos can supply most of it automatically — manual input should be for fine-tuning, not for setup.

Motivation isn’t one-size-fits-all. Gamification — badges, streaks, rewards — works brilliantly for some people and does nothing for others, who respond far better to a plain trend line or a comparison against their peer group. Age matters here too: a rising trend line suits someone building fitness from scratch, but for a user who’s naturally declining — managing a long-term condition in their 60s or 70s, say — a flat or falling line isn’t a failure, it’s real life, and it won’t motivate anyone. A comparison against others their age and type does the same motivational job without setting a bar nobody in that position could reach. User research is what tells you which group you’re actually designing for, not a personal assumption about what’s motivating.

Habits run on chemistry, not just willpower. The same reward loop that keeps people checking social media — a small, slightly unpredictable payoff for a small action — is what makes streaks, badges and milestone messages effective for building a habit too. Used deliberately, that’s a legitimate design tool: quick, honest feedback right after a real action, rather than something manufactured to create urgency.

Health compounds day by day, not in long-term averages. Today is shaped most by yesterday, still meaningfully by the past week, and only lightly by anything from years back — but every day still adds to the total. That’s why the strongest health products keep the focus on “what to do right now” rather than a distant average the user has no way to act on.

Where AI genuinely helps with this — and where it doesn’t

AI is a fast way to stress-test an idea once you already have a strong, specific question to ask it. Asking an AI model how dopamine and user-flow design interact in a fitness app, for example, surfaces useful, specific mechanisms — milestone feedback, social proof, personalisation — that are easy to miss when designing from memory alone.

What it doesn’t do is choose the right problem to solve. That still takes research, domain knowledge, and judgement about which of the ten plausible ideas is actually the right one. AI is a fast way to widen the pool, not a replacement for picking from it.

What a genuinely good health experience could look like

A user who exercises most weekdays around 10am, wears a smartwatch, and prefers vegan food.

App: You jogged 5km in 36 minutes — how did it go? User: I kept stopping to stretch, my hamstrings were tight. App: Try this hip and hamstring session tomorrow, then jog again the day after. Your trainers are also two years old — worth logging a new pair here.

User taps “Trend lines.”

App: Keep up 3 x 5km runs, 2 x 30-minute yoga sessions and one 2-hour bike ride a week, and you’ll be carrying 2% less body fat within a month — with cardio fitness around 70% above the average for your age group.

App: A brunch of orange juice, dried fruit muesli, fruit salad, vegan yoghurt and cinnamon would balance out today’s intake well — or tap here for other options. User photographs their actual breakfast and uploads it instead.

Almost none of this needed the user to type anything. Every suggestion comes from data the app already had, plus one honest check-in. That’s the standard worth designing towards — not more screens for the user to fill in, but fewer they ever need to.

How to run a blue-sky session yourself

1. Write the brief’s core assumption down in one sentence — the thing everyone building this would agree on without thinking twice. For the health app brief, that’s: “People are too busy and stressed to look after their health.”
2. Ask “why” of that assumption three times, out loud or on paper, until you reach something that feels like a real cause rather than a symptom.
   • Why are people too busy and stressed? Work and commuting eat most of the day, leaving little time or energy left for health.
   • Why does that stop them looking after their health? Health admin — planning meals, logging workouts, booking check-ups — takes spare time and mental effort they don’t have left.
   • Why does it take so much time and effort? Because most health tools assume the user will manually plan, log and decide everything themselves, instead of working from data they’re already generating passively.
3. Generate ideas against that cause, not the original brief, with feasibility questions banned until step 5.
4. Flag any idea that relies on the user doing manual work, and redesign it to pull from data the product can already access.
5. Only now apply constraints — budget, timeline, technical feasibility — to narrow the pool down to what’s actually buildable.

This is what real UX is about — not an interface bolted on top of an unquestioned brief.

If you’d like a second pair of eyes on a brief or a project, I offer 1:1 sessions for exactly this kind of thinking.