Design is not what it looks like, its what it does

The first version of Sunna Planner shipped in October 2024. It worked and looks 'nice'. Users could create habits, track their day, see a weekly score. But the feedback I kept getting, directly or indirectly through drop-off, was that something felt off. Not broken. Just... unclear.

I spent a long time thinking it was a visual problem. Wrong colors, wrong font, wrong spacing. So I iterated on aesthetics. Changed the palette. Refined the typography. None of it moved the needle.

The real problem was structural. The app did too many things without helping the user understand which thing mattered right now. The planner, the tracker, the discussion groups, the invocations: they were all there, but the hierarchy was unclear. No moment where the app said, here is what you should focus on today.

That is when I understood what design actually is. It is not visual taste. It is information architecture. It is the decision about what comes first, what gets hidden, what gets surfaced. A well-designed screen does not need a tooltip or an onboarding modal to explain itself. It communicates through structure.

When I rebuilt the onboarding for v2 in May 2025, I stopped asking myself what looks good and started asking what does the user need to understand right now, and what can wait. That shift alone changed everything about how I approached every screen after that.

Constraints are not the enemy of good design, they are the source of it

Building with FlutterFlow and Flutter means you work within a framework. You cannot always do the pixel-perfect thing you imagined. Early on I fought that constantly. I had a vision for a screen, the tool or the framework made it hard, and I would spend hours trying to force it.

At some point I stopped fighting and started designing within the constraints instead of against them. And something interesting happened: the product got more consistent. Because when you cannot do everything, you are forced to make real choices. You cannot fill every corner with a feature or a visual element. You have to decide what actually belongs there.

This is something I see a lot of solo founders miss when they talk about design. They treat it as a resource problem. If I had a designer, if I had more time, if I had a bigger budget. But the most coherent products I have seen, especially in the indie space, are often the ones built under tight constraints. Constraint forces prioritization. Prioritization is design.

The Focus Mode in Sunna Planner is a good example. A 25-minute Pomodoro timer with ambient sound themes. It sounds simple because it is simple. I did not add complexity because I could not justify it in terms of user value. The constraint of asking myself does this need to be here, before adding anything, produced a screen that users almost never complain about. It does one thing and it does it clearly.

The moment I started designing for how people actually use apps

There is a gap between how you imagine users interacting with your product and how they actually do it. I noticed this mostly through support messages and through watching how my own usage of the app evolved over time.

I had designed the Planner assuming people would sit down, plan their day carefully in the morning, and check tasks off throughout the day. A structured, intentional workflow. What actually happens is messier. People open the app for 30 seconds between meetings. They add a task while walking. They check something off and close immediately. The app needs to support that, not just the ideal session.

This pushed me to think about design in terms of micro-interactions and load speed more than full flows. What is the first thing visible when you open the app? How many taps does it take to add a task? Is the most important action always reachable with one thumb?

If you are building a mobile app and have not thought carefully about your onboarding in this context, it is worth revisiting. I wrote about some of the decisions I made in that area in this piece on onboarding best practices for mobile apps. The short version: onboarding is not a tour of your features. It is the first design decision you make about what the user needs to know right now versus later.

Designing for real usage patterns rather than ideal ones also meant accepting that some screens I was proud of were barely seen. The vision board in the Projects module, for example, is genuinely useful for some users. For others it is invisible. That is fine. Design is not about everyone using everything. It is about the right people finding the right thing at the right moment.

What I would do differently

I would start with a proper map of user states before touching any visual element. Not a full spec document, just a clear answer to: who is opening this screen, what do they know at this point, what do they need to do, and what would make them leave.

I skipped that for most of v1. I designed screens as isolated units rather than as moments in a journey. The result was a product that worked feature by feature but felt fragmented as an experience. The v2 redesign in May 2025 and the v3 improvements in early 2026 were largely about fixing that fragmentation, which would have been much cheaper to avoid upfront.

And I would have been more ruthless about removing things. Every element on a screen competes for attention. Every icon, every label, every section header is a small cognitive cost. The instinct when you are a solo founder who has built everything is to show everything. Resist that. The best design decision I made across all versions of Sunna Planner was removing the discussion groups in v2 because they were diluting the focus of the entire product. Removal is design too.

There is a concept from Nielsen Norman Group's usability heuristics that I came back to repeatedly: recognition over recall. Users should not have to remember how your app works. Every session should feel intuitive even if it has been two weeks since they opened it. That is a design goal, not a development goal. And it is one of the hardest to achieve when you are deep in the product and know it too well.

Conclusion

Design is not a skill reserved for people with the right job title. It is a way of making decisions, one screen, one flow, one removal at a time. Building Sunna Planner solo forced me to develop that muscle because no one else was going to do it. I am still learning. But the clearest lesson is this: good design is not about making something beautiful. It is about making something that does not need to be explained.