I confused features with experience

When I launched the first version of Sunna Planner, I was proud of the feature list: Adhkar, habit tracking, a weekly planner, calendar, a pomodoro timer… it felt complete. What I did not realize is that a complete feature list and a coherent user experience are two entirely different things.

Users were landing on the app and not knowing exactly where to start. The onboarding was basically non-existent. I had assumed that because the use case was clear to me: a Muslim who wants to organize their day around their faith and their goals, it would be equally clear to someone downloading the app for the first time. It was not.

The first real signal came through retention data. People were installing, then dropping off after few weeks. Not because the features were bad, but because the entry point was confusing. There was no moment that said: here is where you begin, here is why this matters for you specifically.

What I learned is that UX starts before the user touches a single feature. It starts with orientation: do they know where they are, why they are here, and what to do next? Every screen is a decision point. If you dont design that decision deliberately, users will make it for you by leaving.

I ended up rebuilding the onboarding from scratch, cutting three steps down to one clear action. Retention improved within weeks. Not because I added anything because I removed friction I had not even seen as friction before.

Feedback is not opinion, It's data with emotion attached

Early on, I had a complicated relationship with user feedback. Some of it felt mad about pricing. Some wanted more features such as prayers times. Another said I wanted to get access to this features but cannot, but actually she could.

What changed my approach was treating feedback not as a vote on whether my choices were right, but as a signal about where the experience was unclear or incomplete. A user saying 'I do not understand how to create my own task' is not telling me to redesign all the app. They are telling me that something in the flow, an instruction, a label or a missing empty state, is not doing its job.

I started reading every message with that lens. What is the actual moment of confusion here? What did the user expect to happen, and what happened instead? That shift made feedback actionable instead of overwhelming.

Good UX work is not about taste. It is about understanding the gap between intention and perception. Feedback, when you learn to read it properly, makes that gap visible. And once it is visible, you can close it.

Constraints forced better design decisions

I built Sunna Planner using low code and Google Cloud Platform. I had no design team, no UX researcher, no front-end developer. Every design decision was mine, working within the constraints of what the tools allowed.

At first, I saw this as a limitation. In retrospect, it was one of the best things that could have happened for the product's UX. Because I could not build everything I imagined, I had to prioritize ruthlessly. Every feature I wanted to add had a real cost: in time, in complexity and in the cognitive load it would add for the user. That forced me to ask, every single time: does this actually improve the experience, or does it just make the product feel more complete to me?

There is a version of UX thinking that is about polish: micro-animations, pixel-perfect spacing, design systems. That matters, but it comes later. The foundation of good UX is simpler: does the user know what to do, can they do it without frustration, and does completing the action feel worth the effort?

Working with constraints pushed me to focus on that foundation instead of getting lost in the surface. Some of the cleanest UX decisions I made were not about adding something but about removing a step, simplifying a label, or defaulting to the most common use case instead of trying to accommodate every possible one.

Constraints, when you work with them honestly, are a UX tool. They force clarity.

The experience extends beyond the app

Something I underestimated for a long time: UX does not begin when the user opens the app. It begins the moment they see your content on social media, read your description on the App Store, or land on your website. Every touchpoint shapes the expectation they bring into the product itself.

When I was running Meta Ads for Sunna Planner, I noticed something. The ads that performed best in terms of clicks were not always the ones that led to the best retention. Some creatives were attracting users who had a fundamentally different expectation of what the app was and when the product did not match that expectation, they left quickly.

That was a UX & messaging problem, not a product problem. The gap was between what I was communicating externally and what the product actually delivered. Closing that gap meant being more honest and more specific in how I described the app even if that meant reaching fewer people with my content. Better-fit users stayed longer, used more features, and converted to paid subscribers at a higher rate.

UX thinking applied to acquisition changed my entire approach to growth. I stopped optimizing for installs and started optimizing for informed installs: users who knew exactly what they were getting before they downloaded. It is a slower approach, but it compounds. You can read more about how I think about performance indicators in this context in this piece on KPIs and performance tracking.

What I wish I'd known earlier

If I could go back to the first week of building Sunna Planner, I would tell myself one thing: talk to users before you build, not after.💡

I spent months building what I thought users needed. I had strong intuitions, I was myself the target user, and I was convinced that was enough. It is not. Being a power user of your own product gives you deep knowledge but terrible blind spots. You stop seeing the product the way a newcomer sees it. You stop noticing the friction because you have learned to work around it.

I also wish I had been less precious about my design choices early on. The first version of anything is a hypothesis, not a product. The faster you treat it that way, the faster you build something people actually want to use. And if you are looking for a structured way to think about your planning and iteration cycles, this article on digital planning and weekly organization covers a framework I use regularly as a muslim business owner.

End of the story

User experience is not a phase in your product roadmap. It is the continuous work of closing the distance between what you built and what people actually need. You will never fully close it. But the willingness to look honestly at that gap through feedback, observation and through your own constraints, is what separates products people use from products people abandon. Start there. Stay there.