Most mobile apps fail not because the idea is bad, but because the interface gets in the way users don't understand the app. Users open an app, feel confused or overwhelmed in the first ten seconds, and leave. They rarely come back. UI design is not about making things look pretty. It is about making decisions that reduce friction, build trust, and guide the user toward the action that matters. This guide covers what I have learned building and iterating on a mobile app solo, without a design team, from v1 to v3. No theory, just the principles that changed how I design screens, make layout decisions, and think about visual consistency when every hour counts.
Visual hierarchy: the one rule that fixes most interfaces
If I had to name the single most impactful concept in UI design, it is visual hierarchy. It answers one question: when a user lands on this screen, where does their eye go first? If the answer is unclear, the design is broken.
Visual hierarchy is built through three tools: size, contrast, and spacing. The most important element on a screen should be the largest, the boldest, or the most isolated. Everything else should recede. This sounds obvious until you look at most app screens, where five elements are competing for attention at the same weight.
In practice, this means your primary call to action should always read instantly. Your secondary information (timestamps, categories, metadata) should fade into the background. Your headings should feel like headings, not just slightly bigger body text.
One mistake I made early on was treating every section of a screen as equally important. The task list looked like the focus timer looked like the invocations module. Nothing stood out. Users did not know where to start. Fixing the hierarchy, giving each screen one dominant element, one supporting layer, and one tertiary layer, reduced confusion immediately. If you want to go deeper on layout decisions that affect both design and user behavior, the UX design guide I wrote covers this in more detail.
Spacing and layout: designing with a grid
Spacing is where most solo builders and early-stage products get lazy. Not because they do not care, but because spacing feels invisible until it is wrong. Bad spacing makes a UI feel cheap, crowded, or amateur even when the color palette and typography are solid.
The fix is simple: work with a consistent spacing scale. I use multiples of 4 or 8 pixels for every margin, padding, and gap. 4, 8, 12, 16, 24, 32, 48. Once you commit to this system, every layout decision becomes faster and the result feels more coherent.
Grids matter too. On mobile, content should never touch the screen edges. A horizontal padding of 16 to 24 pixels is standard. Cards, list items, and modals should respect the same internal padding rules. Consistency here is not aesthetic, it is cognitive. When elements are spaced predictably, users scan faster and feel less friction.
Another thing I learned: whitespace is not empty space. It is breathing room. A screen with generous whitespace signals confidence and clarity. A packed screen signals that the designer was not sure what to cut. When in doubt, remove an element or break the screen into two steps instead of cramming everything onto one view.
Typography: fewer choices, stronger result
Typography decisions compound quickly. If you pick three font families, six weights, and eight size variations, your app will feel incoherent no matter how good the individual choices are. The constraint is the discipline.
For a mobile app, I work with one font family, two or three weights (regular, medium, bold), and a defined type scale. My scale for Sunna Planner uses five sizes: a large display size for key moments like onboarding headlines, a heading size for section titles, a body size for readable content, a small size for supporting labels, and a caption size for metadata. Every text element on every screen maps to one of these five. Nothing else.
Line height matters as much as font size. Body text needs room to breathe. A line height of 1.4 to 1.6 times the font size is a safe starting range for most sans-serif typefaces on mobile. Tighter than that and reading becomes effortful. The goal is readability with zero resistance, especially for content users are meant to engage with daily.
One practical tip: test your typography at real device sizes on real hardware early. What looks fine on a Figma desktop canvas can become too small or too heavy on an actual iPhone screen. Your simulator is not enough.
Color and consistency: building a system, not a palette
A color palette is a list of colors. A color system is a set of rules for how those colors are used. The difference matters more than most people realize when they are starting out.
A functional color system for a mobile app has at least four categories: a primary color for interactive elements and key actions, a neutral range for backgrounds, surfaces, and text, a semantic color set (success, warning, error states), and an accent if needed for highlights. That is it. Every color token in your design should map to one of these roles.
The risk without a system is drift. You pick a blue for buttons, then use a slightly different blue for a badge, then a third one for a link. Three sprints later, your app has twelve blues and nothing feels intentional. Defining tokens early, even informally in a shared doc or a Figma style, prevents this.
Dark mode adds complexity. If you support it, every color needs a light and dark variant defined from the start. Do not patch dark mode in after the fact. It will cost you twice the time and still look inconsistent. I built dark mode support into Sunna Planner from v2 and it was one of the decisions I am glad I made early.
Onboarding design: the screen sequence that decides everything
Onboarding is where most apps lose users permanently. The session that should build trust and demonstrate value instead becomes a wall of permissions, form fields, and feature tours that nobody asked for.
Good onboarding design answers one question first: why should the user care right now? Not what the app does in general, but what it does for them, immediately. This means leading with a value statement, not a logo animation or a generic welcome message.
From there, the principle is: ask for the minimum, show value fast. Every permission request, every form field, every choice you force on the user before they have seen anything useful is a drop in motivation. If you need to collect information, collect it progressively, after the user has experienced at least one moment of value.
I restructured Sunna Planner's onboarding three times across versions. The biggest improvement came from moving the profile setup after the first task creation instead of before. Users had already done something useful. They had context. The setup felt earned rather than gated. Retention on the first day improved noticeably. If retention after onboarding is something you are working on, this guide on mobile app retention goes deeper into what happens after the first session.
What building Sunna Planner taught me about design under constraint
When you are building solo, you do not have a design team, a QA process, or a second pair of eyes before shipping. Every design decision is made by the same person who wrote the logic, managed the Firebase rules, and set up the ad campaign. This forces a kind of discipline that is different from working inside a company with specialized roles.
The constraint I found most useful was time-boxing design work. I give myself a fixed amount of time per screen, ship, observe real usage, and iterate. Waiting for pixel-perfect is a way to never ship. The best design feedback I ever got came from watching real users interact with a screen I thought was obvious, and realizing the tap target was too small or the empty state was confusing.
I also stopped trying to be original with UI patterns. Navigation conventions exist because users learned them across thousands of apps. Bottom tab navigation, swipe to dismiss, pull to refresh: these are not limitations, they are free cognitive shortcuts. I use standard patterns everywhere unless there is a specific, user-centered reason not to. Novelty in design only adds value when it removes friction, not when it adds it.
Working with FlutterFlow for prototyping and Flutter for production helped me bridge the gap between design intent and implementation reality. The constraint of what is technically buildable solo shaped my design choices in ways that made the product better, not worse.
FAQ
What is the difference between UI and UX design?
UI design covers the visual layer: layout, typography, color, spacing, components. UX design covers the experience layer: flows, decision points, information architecture, how a user moves through a product. In practice they overlap constantly, and on small teams or solo projects the same person handles both. Separating them conceptually helps you ask the right questions at each stage.
Do I need Figma to design a mobile app?
Figma is the industry standard and worth learning, but it is not mandatory. What matters is having a place where design decisions are documented before you build them. Even a well-organized set of screens with consistent spacing and defined styles in a basic tool is better than designing directly in code with no visual reference. The tool is secondary. The discipline is not.
How many colors should a mobile app use?
As few as possible. A primary color, a neutral range, and semantic colors for states like error and success is enough for most apps. The goal is not a rich palette but a consistent system. Every additional color you add is a new decision point for every screen. Constraint here produces better results than variety. Start with three or four defined roles and only expand when there is a clear functional reason.