Mobile Navigation Redesign
What is the goal?
Restructure the mobile navigation to reduce the number of taps required to reach core features. User testing revealed that 40% of mobile users cannot find the diary creation flow within 10 seconds. The current hamburger menu buries key actions behind two levels of nesting. We need to surface the top 3 actions (new entry, view diary, insights) within one tap while keeping the interface clean.
Solution brainstorming
Replace the hamburger menu with a bottom tab bar containing 4 items: 1. Home (dashboard/diary list) 2. New Entry (prominent + icon) 3. Insights 4. Profile The New Entry tab is visually elevated with a floating action button style to draw attention. Secondary actions (settings, manage questions, share) move to a profile/settings screen accessible from the last tab. On tablets, the tab bar is replaced with a sidebar that shows labels alongside icons.
Research
Problem Definition
Define the problem clearly
What is the problem you're solving?
Mobile users cannot find core features quickly. The hamburger menu hides everything behind a tap-and-scan interaction that breaks the user flow. Users open the menu, scan a list of 8+ items, try to find what they need, and often tap the wrong thing first. The navigation structure was designed for desktop and adapted for mobile as an afterthought rather than designed mobile-first.
Who experiences this problem?
All mobile users, but especially those who use the app primarily on their phone (about 55% of total active users based on analytics). The problem is worst for newer users who have not memorised the menu structure. Power users have adapted but still report frustration in feedback surveys.
When does it happen?
Every single session on mobile. The user opens the app, sees the dashboard, and then needs to navigate somewhere. The hamburger icon is in the top-left corner and competes with the back button on Android. Users tap it, wait for the slide-out animation, scan the list, and tap their destination. This adds 3-5 seconds to every navigation action.
Problem Clarity
Understand what the user is trying to accomplish
What is the user trying to accomplish?
Users want to quickly jump between viewing their past entries, creating a new one, and checking their insights. These three actions represent 90% of what mobile users do. They want navigation to be invisible -- to feel like the app anticipates where they want to go.
If your design could only do ONE thing well, what would it be?
Make creating a new diary entry accessible from anywhere in the app with a single tap. This is the most important action and it should never be more than one tap away, regardless of where the user currently is in the app.
What exactly is the user struggling with right now?
Users are struggling with orientation. After opening the hamburger menu and navigating to a sub-page, they lose track of where they are in the hierarchy. The back button behaviour is inconsistent -- sometimes it goes up a level, sometimes it closes the menu, sometimes it goes to the previous page. There is no persistent indicator of the current section.
User & Context
Features don't exist in isolation
Who is the primary user for this feature (not the product)?
Mobile-primary users who access the app on their commute, during lunch breaks, or in quick moments between meetings. They are typically mid-career professionals (28-40 years old) using iOS or Android. They use the app in short, focused bursts of 2-5 minutes and have low tolerance for navigation friction.
What's the job they're trying to finish when this feature appears?
They are trying to capture a design reflection while the thought is fresh. They just finished a meeting, a design review, or a user testing session and want to log their observations before they forget. Speed is critical -- every second of navigation overhead increases the chance they will defer the entry and eventually forget.
Product Intent & Leverage
Why this feature exists for this product
How does this feature reinforce the product's core value?
The product champions thoughtful, friction-free reflection. A confusing navigation experience is the opposite of that. By making the mobile experience intuitive and fast, we demonstrate that we practice what we preach -- good design that respects the user context and reduces cognitive load.
If we removed this feature later, would users revolt or barely notice?
If we reverted to the hamburger menu after users experienced the tab bar, there would be significant backlash. The tab bar becomes invisible infrastructure -- users would not praise it, but they would immediately notice and complain if it disappeared. This is a foundational improvement, not a feature.
Success Definition
If you can't measure it, you're guessing
What user behaviour should change if this works?
Users should create entries more frequently on mobile because the friction is lower. We should see the mobile-to-desktop session ratio shift from 45/55 to 55/45 as mobile becomes a first-class experience. Time from app-open to entry-creation should drop from 12 seconds to under 4.
What does "success" look like in one week? One month?
One week: Navigation-related support tickets drop by 50%. Task completion rate in usability testing exceeds 95% for finding core features. One month: Mobile session duration increases by 20% (users are doing more per session because navigation is faster). Mobile DAU/MAU ratio improves.
What metric moves because of this feature?
Mobile entries created per user per week (from 1.2 to 1.8), mobile session duration (from 2.4 min to 3.1 min), mobile bounce rate (from 18% to under 10%), and navigation-related support tickets (from 15/week to under 5/week).
Constraints & Trade-offs
Designing is choosing what not to do
What constraints are you working within?
iOS and Android have different navigation conventions (iOS favours bottom tabs, Android uses a mix). We need a solution that feels native on both platforms without maintaining two separate navigation systems. The tab bar cannot have more than 5 items per platform guidelines. We also cannot break deep links that existing users may have bookmarked.
What design debt might this create?
Moving from hamburger to tab bar means we need to categorise every feature as either tab-worthy or secondary. Features that lose visibility (like sharing and manage questions) may see usage drops. We are also committing to a tab-based architecture -- adding a 5th or 6th core feature later will force a redesign of the tab bar or the introduction of a "more" tab, which recreates the hamburger problem at a smaller scale.
Discoverability & Learning
A feature unused is a bug
How will users discover this at the right moment?
The tab bar is persistent and always visible at the bottom of the screen. The New Entry button is visually distinct (larger, elevated, different colour) to draw the eye. Users who are accustomed to the hamburger menu will see a one-time tooltip on first launch explaining the new navigation layout.
How will they understand it without reading?
Each tab uses an icon paired with a short label (Home, New, Insights, Profile). The icons follow platform conventions -- a house for home, a plus for new, a chart for insights, a person for profile. The active tab is highlighted with the brand colour and a subtle underline. No explanation needed for users familiar with any modern mobile app.
Pre-Mortem
Imagine your design failed
What went wrong?
The tab bar works well for the current 4 core features, but 6 months later the team wants to add a collaboration feature and a templates library. There is no room in the tab bar. We add a "More" tab that becomes a dumping ground for everything that does not fit, recreating the exact hamburger menu problem we solved. The navigation architecture was designed for today but not for the product roadmap, and now we face a costly redesign that affects every screen in the app.
Want to create your own design diary entries?