Unfreeze

AI tooling Concept Self-initiated Branding
RoleSolo designer
Duration2 weeks, 2026
ToolsClaude, Desk research

Turning moments of feeling stuck into one small, achievable next step

What if a productivity app helped you start instead of asking you to organise?

Overview

Unfreeze is a mobile concept for people who know what they need to do but cannot begin.

I designed the product end to end from proposition and information architecture to 31 screens and a working prototype. The project explored a simple question: can a product help someone take one small step without adding more decisions, pressure or guilt?

A second question shaped the prototype: does this experience actually need AI? I built three coaching models to the same standard — structured, rules-based and AI-enhanced — so I could compare where AI earned its place rather than assume it did.

The problem

Most productivity tools assume you're ready to plan.

They ask you to define tasks, organise them, choose priorities and decide what to do next. But when starting is the problem, those decisions can become another barrier.

So I reframed the product question:

When starting feels impossible, can something help someone understand what is blocking them and take one small step, without adding cognitive load?

This wasn't a conventional research project. I had no participants and no fielded research. Instead, I used published research on task initiation, avoidance and self-compassion to form design hypotheses, and explicitly labelled a fabricated synthesis as such. It was used only to pressure-test the information architecture, not presented as user evidence.

The resulting model is therefore a hypothesis, not a validated representation of users.

Prototype

Unfreeze

States, not personas

The obvious approach was to create five personas. Instead, I explored five conditions that the same person might move between potentially several times in a day.

That changed how I thought about personalisation.

A user's needs could depend more on their current state than on a permanent profile. That led to my first significant subtraction: I removed the support-style preference question from onboarding.

The question captured someone's state when they installed the app, then treated that answer as permanently true.

If the product is supposed to respond to how someone feels now, storing that preference didn't make sense.

The first real design decision was removing something from my own brief.

Designing for low capacity

The states model changed the journeys too.

Decision paralysis
The original journey asked users to make three comparative judgements before receiving help. I changed this so the system evaluates silently and presents one recommendation to accept or reject.

Overwhelm
The original journey asked users to dump tasks, group them and then review priorities — effectively recreating the organising work the product was supposed to remove. I changed this so the system groups the input and presents one focus.

Low energy
The original journey treated success as making an attempt. I changed this so rest could be a legitimate outcome rather than evidence that the user had failed.

The principle was consistent:

Move unnecessary decisions away from the user when capacity is low.

One step, not one more decision

Every journey eventually converges on the same interaction: the step.

The product doesn't present a task list, a dashboard or three things to choose between. It recommends one thing to do next.

The step is deliberately:

  • Small

  • Reversible

  • Clearly worded

  • Easy to reject

  • Free from pressure or countdowns

For a stalled tax return, the recommended step might simply be:

Open the login page.

Nothing is submitted. Nothing else is expected.

If that still feels wrong, the user can adjust the step one option at a time: smaller, more reversible, different, or not today.

“Not today” holds the task without automatically resurfacing it tomorrow.

I explored whether reversibility itself might make a task easier to start. I couldn't find published research that transferred cleanly to that question, so this remains a design hypothesis rather than a validated finding.

3 coaching models, not one AI solution

Considering user research conducted in other projects where users were asked how AI functionality could aid or impact their comfort and journeys when inputting or using potentially personal information, multiple participants had expressed the need to be informed on what information was being collected, how it would be used or stored and how much control they had over it.

Rather than making AI the default, I built three complete coaching models around the same journey.

01 — Structured

No AI

Fixed questions guide the user through a blocker. The final step is based entirely on their own answers.

02 — Rules-based

No AI

The same underlying questions are reordered according to what the user identifies as their main blocker.

03 — AI-enhanced

Generative AI

The user describes what's getting in the way in their own words, and the system generates a suggested next step.

The three models are switchable in the prototype so they can be compared rather than discussed theoretically.

This created a useful product principle:

Where rules can perform as well as AI, rules win on cost, predictability and trust.

The AI version is deliberately constrained. Suggestions are labelled as suggestions and users can edit or ignore them. The system can infer things about the task, but not make behavioural judgements about the person.

For example:

“That's a guess from what I can see, not a fact about you.”

I deliberately excluded behavioural inference from the MVP.

What I deliberately didn’t build

The product became clearer as I removed things.

I didn't build:

  • A task list as the home screen

  • Streaks or counts

  • Progress bars

  • Three-or-more-option decision screens

  • A full-screen validation stage

Validation became a sentence rather than another stage in the journey.

The aim wasn't to make a more minimal productivity app. It was to remove interactions that didn't help someone start.

Accessibility is part of the product

Cognitive accessibility wasn't treated as a layer added at the end.

The prototype includes:

  • Reduced motion

  • No timed interactions

  • Resumable onboarding

  • No requirement to retain information across screens

  • “I don't know” as a first-class answer

  • Four recognition intensities: warm, neutral, practical and silent

WCAG 2.2 AA was the accessibility floor for the prototype.

One unresolved issue remains: the primary button colour currently fails the required contrast ratio. The initial token measured 2.84:1, while the darkest available option reached 4.46:1, still below the 4.5:1 AA threshold.

I’m treating that as a prototype limitation to resolve rather than presenting the accessibility work as finished.

What I took from it

The most useful work was subtraction.

Removing the onboarding preference question, the extra organising screens, the second capacity assessment and the third option from decisions all made the product more coherent.

Building three coaching models to the same standard was equally useful. It gave me a way to ask a more important question than “Where can AI be used?”

Where does AI actually earn its place?

Unfreeze is still a hypothesis. The states model, the step interaction and the AI approach all need real-world testing.

The first thing I'd test is the step itself — whether one small, reversible action actually helps someone begin.

There's also a larger unresolved problem: someone who is completely stuck may never open the app in the first place. That makes entry points such as widgets, share sheets or deep links just as important as the experience inside the product.

Research & References

Barkley, R. A. (1997). Behavioral inhibition, sustained attention, and executive functions: Constructing a unifying theory of ADHD. Psychological Bulletin, 121(1), 65–94.

Sirois, F. M., & Pychyl, T. A. (2013). Procrastination and the priority of short-term mood regulation: Consequences for future self. Social and Personality Psychology Compass, 7(2), 115–127.

Neff, K. D. (2003). Self-compassion: An alternative conceptualization of a healthy attitude toward oneself. Self and Identity, 2(2), 85–101.

Cheng, A. L., Gou, C. Y., Martin, A., Hartz, S. M., & Abraham, J. (2026). Design preferences for mental health apps among nondigitally native adults with chronic pain: Qualitative analysis. JMIR mHealth and uHealth, 14, e87358.