Lighthouse Redesign
Reorganizing an information dense landing page
Team: Solo Project
Role: UX Designer and Researcher
​
Timeframe: Three Weeks
Tools: Wireframes, Figma, Adobe Illustrator, Prototyping, Usability Testing, User Flows, UI Design
Intro
For group administrators managing their company's benefits through Beam, the first thing they see when they log into Lighthouse is the landing page. It is the front door to everything: enrollment status, plan details, member management, billing, and more. In theory, it should orient them quickly and help them get to what they need.
In practice, it was doing the opposite.
​
The Lighthouse landing page had accumulated information over time in a way that many product surfaces do: incrementally, without a governing organizational principle, and without a clear sense of what users actually needed to see first. The result was a page dense with content that felt more like a data dump than a dashboard. Group admins were spending time hunting for information rather than acting on it, and the cognitive load of parsing the page was getting in the way of the work they had come to do.
​
When a product manager and I began conducting research across our group-facing tools, this pattern surfaced quickly and consistently. Through user interviews and affinity mapping, we heard the same feedback from group admins repeatedly: Lighthouse felt unwieldy and hard to navigate. It was not that the information was wrong or missing. It was that the page made it unnecessarily difficult to find what mattered, understand it at a glance, and move forward with confidence.
The opportunity was straightforward but meaningful: redesign the Lighthouse landing page so that it reflected how group admins actually think about and interact with their benefits portal, rather than how the information had historically been organized internally.
​
This case study documents that redesign process, from research and discovery through usability testing and final handoff.
Research
​
Before putting anything on the canvas, I needed to understand how other products handle the challenge of presenting a large amount of information without overwhelming the user. This is not a new problem in product design, and I wanted to learn from what the broader industry had already figured out rather than invent from scratch.
​
I looked at a range of products that serve a similar administrative context: platforms where users arrive with a specific task in mind, need to quickly orient themselves within a complex information environment, and then navigate efficiently to take action. The common thread in the best of these experiences was not that they showed less information. It was that they imposed a clear mental model on the information they showed, giving users a reliable framework for understanding where things lived and why.
One product stood out as a particularly strong reference point: Rippling. Their tabbed navigation approach to dense administrative content was exactly the kind of pattern I had been looking for. Rather than presenting everything on a single surface and asking users to parse it all at once, Rippling uses a tabbed architecture to chunk related information into discrete, scannable categories. Users always know where they are, what belongs in each section, and how to move between them without losing their place. The cognitive load is distributed across the interface rather than front-loaded onto a single overwhelming page.
This pattern resonated immediately with what group admins had told us in research. The problem with the existing Lighthouse landing page was not the volume of information itself but the absence of a clear organizational logic that users could internalize and rely on. A tabbed approach offered a way to preserve access to the full breadth of content while giving users the structure they needed to navigate it with confidence
.
Rippling became a north star reference as I moved into ideation, not as something to replicate, but as proof that this class of problem had an elegant solution worth building on.
Design​
Armed with research insights and a clear directional reference in Rippling's tabbed model, I moved into the design phase with a specific goal: transform the Lighthouse landing page from an undifferentiated wall of information into a structured, navigable experience that group admins could orient themselves within immediately.
The first step was an audit. I catalogued everything that currently lived on the landing page and asked a fundamental question about each piece of content: what is this, who needs it, when do they need it, and how often? This exercise was less about aesthetics and more about information architecture, understanding the relationships between content categories and identifying where the existing page had conflated things that belonged separately and separated things that belonged together.
My initial pass at a tabbed structure produced nine tabs: Basic Info, Contact Info, Employment Info, Coverage, Wage History, Terminate Employee, Dependents, View Card, and Elections. On the surface, this felt like progress. The information was no longer presented as a single undifferentiated mass, and the tab labels gave users a navigational vocabulary they had not had before.
But nine tabs introduced a new problem. The navigation bar itself was becoming a source of cognitive load, asking users to scan and evaluate too many options before they could take action. Some of the tabs were also conceptually redundant, housing information that could reasonably live together under a single label without sacrificing clarity.
​
​
So I went back through each tab with a more critical eye, asking not just whether the content was organized but whether the organizational structure itself made intuitive sense to a group admin. Through this consolidation process, I identified several opportunities to simplify. Contact Info, for example, could be absorbed into Basic Info without any meaningful loss of findability. Terminate Employee, View Card, and Elections were actions and utilities rather than information categories, which meant they belonged in a different part of the interface entirely as global items accessible regardless of which tab a user was on, rather than competing for attention alongside content-driven tabs.
​
The result of that consolidation was a five-tab structure: Basic Info, Employment Info, Coverage, Wage History, and Dependents. Each tab now represented a genuinely distinct and coherent category of information that group admins think about in discrete contexts. The navigation was simpler, the mental model was cleaner, and the page as a whole felt dramatically more manageable than either the original design or my own first pass at a solution.
​
The reduction from nine tabs to five was not about minimalism for its own sake. It was about recognizing that good information architecture is not just about separating things. It is about grouping them in ways that match how users actually think, and then getting out of their way.
Conclusion
​
The Lighthouse landing page redesign was, at its core, a problem of respect. Respect for group administrators' time, their mental bandwidth, and their need to arrive at a tool and immediately feel oriented rather than overwhelmed. The original page was not broken in any dramatic sense. It contained the right information. It simply presented that information in a way that treated users as people who had unlimited patience for hunting, parsing, and piecing things together. They did not, and they should not have to.
​
What this project reinforced for me is that information architecture is often the most invisible and most impactful design work on a given project. The visual changes between the original Lighthouse landing page and the redesigned version were meaningful, but the change that users actually felt was the structural one. When group admins tested the redesigned experience, what they responded to was not how it looked. It was how quickly they could find what they needed and how confidently they could move through the interface without second-guessing themselves. That outcome lives in the bones of the design, not the surface of it.
The research process was equally instructive. The pain point we ultimately designed around, that the page was unwieldy and hard to navigate, was something users had been experiencing quietly for some time. It took dedicated outreach and structured affinity mapping to bring it into focus as a design priority. That experience deepened my conviction that user research is not just a validation tool to be deployed after the design work is done. It is the mechanism by which the right problem gets identified in the first place.​
​
The consolidation from nine tabs to five also reminded me of something that is easy to forget in the middle of a complex design problem: simplicity is not the starting point. It is the destination you arrive at after doing the hard work of understanding what actually belongs together, what belongs elsewhere, and what does not belong at all. The first version of a more organized experience is rarely the right one. Getting there requires iteration, critical distance, and the willingness to question your own initial decisions.
Finally, this project demonstrated the value of grounding design decisions in external reference points without losing sight of the specific context you are designing for. Rippling's tabbed architecture was a genuine source of inspiration, but the five-tab structure I arrived at was not Rippling. It was a solution shaped by what Beam's group admins told us they needed, refined through usability testing, and built to fit the specific information landscape of the Lighthouse platform. Inspiration and imitation are very different things, and the distance between them is where the actual design work happens.