Bruma
An app that solves immediate relief without giving up sustained support. The research knocked down half our hypotheses and changed the product.
View the prototype- Role
- Product Designer, shared role
- Duration
- 2 weeks
- Platform
- Mobile app
- Sector
- Emotional wellbeing
- Status
- Academic project · validated prototype
Outcome
The prototype was validated with users from the archetypes we had defined. What changed were not styling details but the three decisions the product rests on, and one of them went against my own proposal.
A two-week academic project, so there are no production metrics here. What can be measured is how much the research changed the product, and that is what this case is about.
Targeted metrics
The business metrics the product aimed to move, and under each one the value moving it would have.
Drop-off before the first use
The category has forms up to 18 steps long. Whoever leaves there never becomes a user, and getting them as far as the download already cost money.
Recovering those who leave out of impatience
The research separated those with no patience from those who reject the idea of regulating. The first group is far larger, and it is market reachable through design.
Retention without streaks or penalties
A broken streak turns wellbeing into a debt. Retaining without adding guilt is the difference between opening the app again and uninstalling it.
Time to first relief
In the research, speed weighed more than achievements: it is the real criterion by which someone picks an app in this category and stays with it.
The whole category designs for the calm user.
People between 18 and 30 go through frequent episodes of everyday emotional distress (stress, anxiety, anger, sadness, fear, frustration) that need immediate relief and sustained support at the same time.
Existing digital solutions are built for the second and fail at the first: they ask for too much information before delivering value, create friction exactly when the person is looking for calm, and end up feeling like one more obligation. In the benchmarking we found forms up to 18 steps long before you could use the app.
How do you design for someone arriving agitated and out of patience, instead of the steady, calm user these apps assume?
Two designers with equivalent responsibilities.
We worked together on the hypotheses, the survey questions, the interview script and the data analysis. Each of us interviewed two people and analysed the same number of apps. When we disagreed and there was no time to argue, we tested both versions and chose fast.
- · I defined the project methodology and the route of work, with the deadline as the first constraint.
- · I crossed three sources instead of trusting one: the survey for volume on the target, the interviews to hear how people talk about the subject in their own words, and the benchmarking to know what was already solved and what was not. A survey alone does not tell you how the user expresses themselves, and without that material the solution would have been a bet.
- · I used AI for what it does well: turning the hard data from surveys and interviews into fast, comparable statistics. Reading what each number meant, and which hypothesis it killed, was on us.
- · In UI each of us started from our own proposal, and we built the final direction together. I took the lead on the entry question, the log, the breathing flow and Talk to Bruma, always with her input on top.
What my teammate owned: she directed the benchmarking, which we analysed between the two of us, and she also built the branding and carried the weight of the UX writing.
Half the hypotheses did not survive intact.
We started from six hypotheses about why young people do not use wellbeing apps and tested them against 32 survey responses, 4 in-depth interviews and a benchmarking of six apps in the category.
The whole process, from the first hypothesis to the iterated prototype, took two weeks between two people. That constraint defined the scope: a small sample, synthesis accelerated with AI tools, and absolute priority to the questions that could change product decisions over the ones that merely described the user.
We thought people did not know how to regulate. They do, they just do not name it.
66% use music and 41% have active, conscious responses, like moving or talking to someone. The behavior is not missing: recognizing it as a strategy is. The opportunity stopped being teaching regulation and became organizing what they already do.
We thought the rejection was of the app. It was of the wait.
61% would not use a wellbeing app in a crisis, and that number looked damning until we opened it up: 36% do not use it out of impatience, not rejection. Only 25% actively reject the idea of regulating. That distinction turned most of the "no" into a solvable design problem.
We thought gamification retained. Progress retains, streaks do not.
44% want to see progress, but the surface gamification of streaks and badges only motivates 31%. The decisive figure: speed (34%) weighs more than achievements (25%). The app has to be fast first and playful second, never the other way around.
And the figure that frames everything: 91% have no active wellbeing app. Of the 11 people who had been users and left, three reasons directly attributable to design friction (boring, asked for too much information, felt like going to therapy) added up to 6 mentions. More than half the drop-offs are not explained by a lack of interest in wellbeing, but by how the apps were built.
Two behaviors, not two people.
The same user can be one or the other depending on the emotional moment, and that nuance changed how we structured navigation: the app does not ask who you are, it offers both entrances at once.
Access with no sign-up, even at the cost of personalization.
You enter and use the app without creating an account or answering questions first. What we ruled out was the personalization onboarding, which would have let us adapt content from the first use.
That 36% who leave out of impatience are only recovered if the app delivers value in the first seconds. Any question up front, however useful later, spent the only patience budget available. Personalization was postponed until the user had already received something in return.
Progress without streaks.
We show continuity and progress, but without day streaks, punishments or competition. What we ruled out was the standard pattern of the category, which is exactly what almost every app we analysed does.
The user wants to see progress, but a broken streak turns wellbeing into a debt. In a mental health app that backfires: it adds guilt to someone who came in looking for relief. The rule we took from the research: continuity should say "you can come back here", not "you failed by not coming back".
Tone as a design decision, not a content one.
We treated the wording of every instruction as part of the interaction design, with explicit tone review.
One interviewee made it clear that an obvious instruction can generate more stress. In emotional wellbeing, a correct feature fails if the tone feels condescending or disconnected from the state of whoever is reading. The register was not decoration on top of the interface: it was the interface.
Five entrances, and none that demands being fine.
The architecture prioritizes simple entry points and immediate support routes: the person quickly finds what they need according to how they feel, whether that is breathing, listening, writing, talking or reviewing their trail.
When the team does not agree, you test.
We ran usability tests of the MVP with users inside the defined archetypes, and A/B tests to settle design disagreements on evidence instead of preference.
The clearest case was the sound companion. I framed it as a single looping sound; my teammate, as a mix of several sounds the user could combine freely. Both positions were defensible: mine prioritized entering fast and decision-free, consistent with the finding that speed weighs more than options; hers prioritized control and personalization, consistent with the explorer archetype.
Hers won. Users preferred building their own mix, and the result qualified my reading of the research: speed rules for getting in, but once inside, having control over the experience is part of the relief and not a cognitive load. Holding on to my version out of conviction would have cost a worse feature.
What the project leaves me with.
Research is worth it when it forces you to change your mind.
Several hypotheses were adjusted or dropped against the evidence, and that turned into concrete decisions: access without sign-up over personalization, and streak gamification dropped for the risk of adding pressure. Had the research only confirmed what we already believed, it would have been a waste of time.
Designing for the crisis is a different problem from designing for the habit.
None of the six apps analysed handled the acute moment well; all of them assumed a user with time and calm. It is a clear case of an entire category optimizing for the wrong scenario.
What a real product would need before it could exist.
Bruma does not replace therapy and cannot diagnose, and that is stated explicitly inside the "Talk to Bruma" flow. Even so, a real product would need clear referral protocols for signs of severe crisis, something beyond the scope of an academic project.
The AI in the prototype is entirely simulated: it stayed an interaction concept, not a functional system. A real implementation would require defining the limits of its answers, its referral flows to professional help and its behavior in edge cases, validated by mental health professionals before any launch. On top of that come serious privacy considerations, given how sensitive the data the app invites you to share is: notes, conversations and emotional states.
This is an academic project. The prototype was validated with users, but never reached implementation.