Screen Shot 2026-02-23 at 3.58.49 PM.png

Homebase- Information Architecture

The Navigation Problem That Was Really a Trust Problem

The surface symptom

Homebase's navigation had drifted over time in the way most long-lived products drift: features ended up scattered based on when they shipped, not how people actually work. Labels were inconsistent. Switching between manager and employee contexts created constant "wait... where am I?" moments. Support burden was rising. Task success was declining.

I was the Senior Product Designer on the effort, partnering with the Head of Product and a Design Lead. I owned the IA strategy end to end — workshops, task mapping, sitemaps, wireframes, and tree testing.


The real structural problem wasn't "too many menu items"

The biggest issue wasn't clutter. It was scope confusion — and specifically, a product that had never committed to what "location" meant.

There was a location picker in the top-right of the web app. Users naturally assumed: "I picked a location, now I'm looking at that location." Except that wasn't consistently true. Some areas honored the location filter, others silently ignored it, and some introduced special cases like "Company View" or "Company Level" sprinkled in to explain the mismatch.

Over time, the UI taught users a bad lesson: you can't trust the context you're in.

That kind of inconsistency is brutal in workforce software. Managers move fast — checking yesterday's numbers, approving requests, fixing timecards, resolving exceptions. If the system silently changes scope depending on where you are, users burn mental energy just figuring out what they're looking at before they can act on it.

side by side comparison of the current navigation structure and the areas highlighted in red are the key areas of focus for improvement in the proposed IA structure

Why this mattered beyond usability

Location had historically been central to the product because it was tied to billing. But the business was moving toward employee-based pricing at the company level, which meant location would become less structurally important over time. That made it even more critical that the IA could scale toward company-level clarity instead of relying on location-driven exceptions forever.

I framed the entire effort around one principle: make context explicit and predictable — role, scope, and intent.

Mapping out the current state of the web application and identifying problematic information architecture structures

Anchoring on what people actually do

Instead of debating menu names in the abstract, I grounded the IA around high-frequency tasks for each role.

Managers were trying to: monitor sales and labor from the previous shift, track no-shows, approve trade and cover requests, resolve timecard errors, send announcements. Employees were trying to: see upcoming shifts with context, act on clock-in timing, request and track trades, view announcements, review previous shifts.

When we mapped it out, the product was asking both audiences to navigate the same maze. The IA needed to reflect that these are two different modes with two different mental models.


The direction: make "where am I?" unmissable

We aligned on success criteria that were intentionally practical: fewer clicks to key tasks, less confusion when switching roles and locations. The IA principles followed directly: separate manager and employee spaces with explicit mode switching, group navigation into scalable modules, organize by intent on mobile ("My Work" vs. "My Money"), and use role-specific landing experiences — managers land on monitor-and-act, employees land on what's-next-and-clock-in.

I pressure-tested the structure through role-separated IA proposals, module grouping variants, navigation model explorations, and wireframes focused on hierarchy, labeling, and task paths — all before committing to visual design.


What we recommended (and why)

We converged on an IA that did four things consistently:

  1. Reduced reliance on location exceptions
    We didn’t try to erase location overnight, but we stopped letting it behave like a global filter in some places and not others.

  2. Made role mode obvious
    Users shouldn’t have to infer whether they’re acting as a manager or an employee based on the menu items they see.

  3. Shortened paths to high-frequency actions
    The structure prioritized “I need to do this now” tasks, not “here’s the full taxonomy of everything we offer.”

  4. Created a scalable foundation
    As billing and organization moved toward company-level logic, the IA wouldn’t collapse under the weight of exceptions.

Proposed IA structure for manager facing web application


What tree testing confirmed (and what it caught)

We ran a tree test focused on high-frequency manager and employee tasks. The results confirmed the overall structure — 35% improvement in task findability versus the existing navigation — and the misclick patterns told us exactly what needed iteration: labels that were too internal or abstract, overlapping modules where users had to guess which bucket to try, and duplicate pathways that created uncertainty.

Based on those patterns, I renamed ambiguous labels, consolidated duplicates, and moved items to reduce "either/or" category decisions.

What would have happened next

If this had moved to delivery, the path was straightforward: first-click testing on the proposed navigation and landing patterns, role and location comprehension checks, and a phased rollout by module to minimize disruption. That phasing mattered — navigation changes feel like "the product moved" even when they're objectively better. Gradual rollout reduces shock and gives the team room to learn.

Why this project was deprioritized — and why the work still mattered

After we completed discovery and a validated IA proposal, the project was deprioritized due to shifting business priorities. That's a normal reality in high-velocity product organizations, and I'd rather be honest about it than pretend everything I design ships.

What the work produced was durable: a test-backed IA direction, a shared understanding of the scope/context problem, and a structural framework the team could return to when priorities shifted back. It also influenced how the team thought about IA decisions in subsequent feature work — the principle of making context explicit became part of the team's design vocabulary even without a formal navigation rebuild.

Impact

  • 35% improvement in task findability in tree testing versus existing navigation.

  • Shortened paths to high-frequency actions for both manager and employee roles.

  • Eliminated role-context confusion by making the manager/employee mode unmissable.

  • Produced a test-backed, reusable IA direction the organization could return to when timing was right.