Innafor. A drinking log without the judgment.

The problem

In our survey, 94.5% of respondents said they drink alcohol, and very few had a real sense of how much. The existing apps didn’t help. Services like Drikkevett felt judgmental, and Reframe is American, built for a different drinking culture. We wanted to create a tool that speaks to you like a friend who just happens to be good with numbers: honest, helpful, never judgmental.

My role

My team and I designed the survey and analyzed the results, built personas based on the data, mapped out the flow and interactions in the prototype, and designed the login, profile, statistics, and navigation. We designed the concept and the main feed together as a group.

Insights first

We sent out a survey and received 398 responses from people aged 18 to over 80. The findings shaped everything that followed:

• What actually limits people’s drinking is health (53%) and finances (42%), not rules and guidelines.
• 25% would use such an app themselves, and an additional 6.5% would use it to keep an eye on someone else.
• The most requested feature was personal statistics (38%), ahead of tips, health comparisons, and safety features.
• The open-ended text field gave us the best ideas in the entire project, including the blood alcohol content calculator that estimates when you can legally drive again.

That last point became a lesson I’ve carried with me ever since: we conducted the survey to get numbers, and the most valuable thing it gave us was words.

From data to people

I used the survey to define four groups that reflect how Norwegians actually drink: everyday drinkers, heavy drinkers, health-conscious drinkers, and new drinkers. Then I created eight personas, two per group, so that no group was reduced to a single stereotype. When we discussed features later in the project, it was usually the personas that determined the outcome.

Design for intoxicated users

My favorite part of the project. Our users aren’t always sober when they use the app, which makes universal design the core requirement rather than just a checklist. Large clickable areas. High contrast, verified against WCAG AA. Text and clear symbols next to each color indicator. Nothing that requires precision at one in the morning. Accessibility guidelines usually focus on permanent disabilities, but designing for a user with a temporary and potentially severe impairment made the entire app better for everyone.

The gray one or the purple one

Late in the process, we had two directions: a clean, gray, and safe version, and a colorful purple one with a friendly mascot. We chose the purple one. The category was full of apps that felt clinical or patronizing, and personality was exactly what was missing. Distinctiveness was a strategic choice here, not a stylistic one. This is the project I point to when I say that user-friendly and playful aren’t opposites.

The safe gray directionWhat we chose

Testing

We tested the prototype in four moderated sessions, with one user per target group, on a phone with Figma installed. People figured out the navigation bar, understood how to log a unit and switch between stats views, and praised the login flow and the design. The more vague feedback also taught us something: we tested before the prototype was completely finished, and half-finished prototypes give you half-finished answers.