Role
Product Designer
Year
2026
Navigation Rail Redesign
Context
The platform is a suite of three SaaS studio management products built on a shared core, each serving a different vertical, music teachers, tutors, and athletic coaches. Independent teachers and studio owners use it daily to manage their students, schedule lessons, handle billing, and run their business. All three products share the same navigation, with small differences depending on the audience. And over the years, as the product kept growing, the navigation rail quietly became a problem. Every new feature got its own spot in the rail, and nobody ever took anything out. By the time this project started, users were looking at a long list of items, many of which had nothing to do with how they actually worked.
The Problem
The feedback had been coming in for a while. Members were frustrated by features they'd never touched showing up in their navigation every single day. Mileage tracking is a main navigation item that online only tutors will never need. And the problem was only going to get worse. New features were still being added and there was no good way to fit more into a rail that was already too long. On top of that, the way the rail collapsed and expanded had been bothering users for a long time. It only expanded on hover, which felt unpredictable and got in the way more than it helped. That complaint had been sitting in the backlog without a real fix. The navigation also had copyright text sitting at the very bottom of the rail, taking up space in an area that should be working harder.
How I Approached It
The real solution was always going to be full complexity unfolding, hiding entire features from the product based on what each user actually does. But that's a big, deeply architectural change. Some features are so woven into the product that hiding them isn't just a toggle. It would take time to do properly. So I looked for what we could do now that would actually move things in the right direction. Navigation customization felt like the right answer. If users could decide what shows up in their rail, they could clean up their own experience without waiting for a platform wide project to land. It wasn't the full solution, but it was a real one. That shift in framing changed the whole project. Instead of asking "how do we fix the layout," the question became "how do we give users control", and that opened up a much more interesting set of decisions. I ended up proposing three things that worked together: Navigation Preferences to let users manage what's in their rail, a "More" item to give secondary features a home without hiding them completely, and a persistent collapse/expand state so users could set the rail the way they wanted and have it stay that way. One detail that needed thinking through early was how items get placed when a user first encounters the new system. For existing users, the plan was to analyze usage and automatically move items they'd never interacted with into More, so their rail would already feel cleaner without them having to do anything. For new users, sensible defaults would be set, with a future onboarding questionnaire as the next step, asking which features they planned to use and pinning accordingly. That logic meant the feature would feel thoughtful from day one, not like something users had to figure out themselves.
The Solution
The redesign gave users three ways to manage their navigation: pin the things they use every day, move less-used items to a "More" overflow menu, or hide things entirely. Preferences live under the profile menu and can be updated anytime, nothing is permanent. The rail itself can now be locked open or collapsed based on what the user prefers. That state is saved, so it's there the next time they log in. The whole thing was built as a single shared Figma component that works across all three products and both portals, teacher and student, with variant logic handling the differences between them.
Navigation Preferences
Navigation Preferences is a panel in the profile menu where users decide what their rail looks like. They can show or hide any item, or move it to "More", a middle ground between visible and gone. Hidden items aren't deleted. They can always be brought back, which mattered a lot for users whose workflow might change. A teacher who doesn't track mileage today might start doing in-person lessons next year. The option stays there when they need it. The preferences panel also made it possible to give proper navigation entries to sections that had never had one. Some parts of the product were genuinely useful but only reachable through indirect paths, a link on the home page, a shortcut buried in another section. This project created a place for them in the rail for the first time, with users deciding whether to keep them pinned or tucked into More. For the initial rollout, those newly added items were placed in More by default for existing users, keeping their primary rail familiar while making sure More wasn't empty and useless on launch day.
The "More" Menu
"More" sits at the bottom of the rail and holds whatever the user decides doesn't belong in their primary view. Items there are still fully accessible, they just don't take up space the user doesn't want them taking. Clicking More opens a dropdown rather than navigating somewhere, and that created an interesting design dependency. The rail needed to stay open while that dropdown was active, otherwise the interaction would feel broken. That's part of why persistent expand/collapse was so tied to this, without it, the More menu wouldn't work reliably. The underlying idea here was progressive disclosure: show people what they need, and let them reach for the rest when they want it. The navigation should reflect how someone actually works, not every capability the product has ever shipped.
Collapse/Expand & Everything Else That Came With It
Making the collapse/expand state persistent sounds like a small thing, but for daily users it made a real difference. The old hover-only behavior had been a complaint for a long time, it felt unpredictable, and users had no way to set it to how they wanted. Now they can lock it open or closed and it stays that way. It also solved the More interaction cleanly. Since More opens a dropdown, the rail needs to hold its state while that's happening. Persistent expand made that straightforward to handle. A couple of other decisions came together in this project too. The copyright text that lived at the bottom of the rail got moved to an About page under the profile menu, a much better home for it, and it freed up that space for the collapse/expand control. And the entire navigation got rebuilt as a unified component across all three products and both portals, so future changes only need to happen in one place.
