Verizon Information Architecture · Navigation UX

Router GUI
Navigation
Redesign

A 5-month UX Senior engagement inside Verizon's UX team — redesigning the Information Architecture and navigation system of the Fios Router GUI, working within VDS 3.0 design standards and navigating one of the most complex enterprise constraint environments in telecom.

My Role
UX Senior Designer
Duration
5 Months
Platform
Web / Mobile / Tablet
Design System
VDS 3.0
Information Architecture Navigation UX VDS 3.0 Competitive Audit Taxonomy Matrix Short + Long Term Multi-viewport
Router GUI Initial Structure
5
months of
iterative work
3
navigation
patterns tested
60+
IA items
classified
2
recommendation
tracks
Team
1 Lead Designer · 2 UX · 1 PM · Business Lead
Deliverables
IA Maps · Taxonomy · Recommendation Decks
Constraint
VDS 3.0 · Enterprise tech limitations
Files
Router GUI 3.3 Navigation →

01 — Strategic Context

Inside Verizon's UX Team — From the Inside

Verizon is one of the largest telecommunications companies in the United States. As part of the UX/UI team, we worked on different client-facing projects, including the design system, information architecture, and many navigation-related solutions.

This specific project — Router GUI Navigation — was about designing the information architecture and navigation system for the Verizon Fios Router GUI from a foundation that had accumulated years of inconsistent additions. The platform had grown organically without a governing IA model, resulting in navigation that confused users at every level.

"It wasn't just a complex and large interface. From the start, there was the obstacle of understanding how each item works and defining the main functions, the technology we have, the business needs, and the pain points of users."
What made this engagement different from a typical redesign: We weren't designing new features. We were designing the architecture that would govern every feature — deciding what goes in the Dashboard, what becomes an L1 navigation item, and what lives inside the hamburger menu. Every decision had cascading implications across desktop, mobile, and tablet viewports.
INITIAL ROUTER GUI STRUCTURE — The IA we inherited View in Figma →
Initial Router GUI structure
The original structure we inherited — a flat list of navigation items without clear hierarchy, grouping logic, or mobile adaptation strategy. This was the baseline we had to understand before we could redesign.
The Setup
4 Projects within Verizon
The Router GUI Navigation engagement was Project 4 within our Verizon work — part of a broader engagement that included Discounts Navigation (research & sorting), Elysium Tree Testing, and LTE/5G Flow UX/UI. Each project informed the others, giving us a deep understanding of the Verizon ecosystem before we tackled the most complex IA challenge.

02 — The Challenge

When the PM Proposes a "New Structure"
Without Any Research

The challenge wasn't just the complexity of the router's feature set. The most significant obstacle came from within the team — and how we handled it defined the quality of the final output.

01
A PM with a solution before understanding the problem
We had a project manager who initially proposed a "new structure" without having carried out any study or iteration. This is one of the most common and dangerous failure modes in enterprise UX — someone with authority but without research proposes a direction that "makes sense" intuitively but violates usability principles. We had to educate him on the advantages of doing it step by step, according to usability and UI laws.
02
Competitor audit behind authentication walls
Auditing router GUI dashboards from Netgear, Xfinity, ASUS, and others was technically blocked — these interfaces only reveal themselves to actual customers with configured hardware. Standard competitive analysis methods didn't work. We had to find a way around this without compromising research integrity.
03
60+ features, 3 navigation levels, 3 viewport sizes
The Router GUI has over 60 distinct features and settings — each one needing to be classified across three dimensions: Does it go on the Dashboard? Does it become an L1 nav item? Does it live in the hamburger menu? And every decision needed to hold across desktop, tablet, and mobile viewports simultaneously.
04
VDS 3.0 compliance as a hard constraint
Every design decision had to be validated against Verizon's Design System 3.0 — a comprehensive set of standards governing typography, component behavior, interaction patterns, and brand expression. Proposing a pattern that didn't exist in VDS meant either advocating for a system extension or finding a VDS-compliant alternative.
NEW vs. CURRENT — PM's proposal vs. research-based approach View in Figma →
New vs Current navigation structure comparison
Left: v3.3 (our research-based proposal). Right: v3.2.0.14 (current state). The colored lines show how individual items map between structures — demonstrating exactly what changes, what moves, and what gets restructured. This visualization became the tool that convinced the PM.
How we handled the PM situation: Instead of arguing abstract UX principles, we showed him the "Current vs. New" comparison with explicit mapping lines. The visual evidence made it impossible to argue with — you could see exactly which items were misplaced and why. Data and visuals beat authority every time.

03 — The Process — 5 Months of Iterative Work

How a Complex IA Problem
Gets Solved Systematically

This wasn't a sprint. It was a 5-month structured investigation — each month building on the last, with clear deliverables and defined checkpoints. The Figma file (Router GUI 3.3 Navigation) captures all five months of work across: Sandbox, Competitor Audit, Month 1–5, and Archive pages.

Month 1
Audit existing IA
Map all 60+ features
Color-code by hierarchy level
Identify structural problems
Brief stakeholders on methodology
Month 2
Competitor audit (covert access)
Nighthawk, Xfinity benchmarking
Build taxonomy matrix
TRUE/FALSE classification for each item
Dashboard content definition
Month 3
Resolve PM structure conflict
New vs. Current visual mapping
Dashboard / L1 / Hamburger analysis
Define navigation hierarchy rules
VDS 3.0 compliance check
Month 4
Short-term recommendations
Rationale documentation
Multi-viewport mocks (desktop/mobile)
Pros/cons/considerations per option
Label recommendations
Month 5
Long-term recommendations
Final deck production
Appendix (taxonomy, help structure)
Stakeholder presentation
Handoff documentation

The Complete Information Architecture Map

Every feature of the Router GUI classified, positioned, and color-coded. Purple = main navigation. Red = problematic placement. Green = newly positioned or confirmed. Gray = service/edge cases. This map was the foundation for every subsequent decision.

Main navigation items
Problematic / requires action
Confirmed / newly positioned
Service / edge case items
COMPLETE IA MAP — All 60+ Router GUI features classified and positioned Full Figma file →
Complete Router GUI IA map
The complete IA map for Router GUI — every item from Home, Wi-Fi, Devices, Security & Firewall, Network Settings, Diagnostics & Monitoring, and System. Red items flagged for redesign. Green items confirmed. The color system made structural problems immediately visible to non-designers in stakeholder reviews.

Competitor Audit — The Access Problem and How We Solved It

Another big problem: auditing competitors within dashboards that only allow access to clients of the competition. Standard competitive analysis was blocked by hardware requirements. We solved this with well-known people who used similar dashboards with the competition — recruiting a network of users who had Netgear, Xfinity, and ASUS routers at home and conducting structured walkthroughs via screenshare.

COMPETITOR AUDIT — Nighthawk CM2000 / Xfinity router interface View →
Competitor router GUI audit
Nighthawk CM2000 Cable Modem / Xfinity 1.2 GBPS — one of the competitor interfaces audited. Left panel navigation structure, hierarchy model, and dashboard content decisions were documented and compared against the Verizon Router GUI.
COMPETITOR AUDIT — Advanced Sidebar Navigation pattern
Competitor sidebar navigation
The "Advanced Sidebar Navigation Open" pattern — showing how competitors handle the expanded left-rail navigation at different hierarchy levels. This directly informed our Dashboard vs. L1 classification decisions.

The Taxonomy Matrix — The Most Rigorous Artifact

The taxonomy matrix was the most analytically demanding deliverable of the engagement. Every single Router GUI feature was evaluated across 11 dimensions — TRUE or FALSE — creating an objective classification system that removed subjective debate from placement decisions.

TAXONOMY MATRIX — TRUE/FALSE classification across 11 dimensions for 60+ items Full matrix in Figma →
Taxonomy matrix TRUE/FALSE
Each row = a Router GUI feature. Each column = a navigation dimension (Physical equipment, Equipment setting/action, Connected Devices, System setting, Network setting, Account setting, Affects dashboard, Quick link, External link, Support/FAQ, Information). TRUE/FALSE cells created an objective placement profile for every feature — making the argument for placement data-driven rather than opinion-based.
Dimension 1-4
Physical & Setting Classification
Physical equipment, Equipment setting/action, Connected Devices setting, System setting. Determined whether a feature was hardware-adjacent (higher visibility needed) or software-only (can be buried deeper).
Dimension 5-7
Network & Dashboard Impact
Network setting/action, Account setting/action, Affects dashboard. The "Affects dashboard" TRUE/FALSE was the most consequential — anything that changes dashboard state needed L1 visibility.
Dimension 8-11
Access Pattern Classification
Quick link, External link, Support/FAQ, Information. Items that were external or informational (like Open Source Software) got appropriately deprioritized from primary navigation — reducing cognitive load.

04 — Navigation Structure Analysis

The Dashboard / L1 / Hamburger
Classification Exercise

The central question of the entire engagement: what should go where? The exercise of understanding what should go on the main Dashboard, what should go as L1, and what should go inside the hamburger menu. Three different levels of visibility — each with a different cognitive cost for the user.

DASHBOARD / L1 / HAMBURGER ANALYSIS — The classification exercise View in Figma →
Dashboard L1 Hamburger analysis
The exercise that defined the hierarchy: Router vs. Extender in rows (each with Basic/Advanced Toggle), and navigation levels (Dashboard, L1, Tab-content) in columns. What can be a Visible L1? What lives only in the hamburger? This framework replaced intuition with classification rules.
Navigation Level: Dashboard
Equipment/Affective — what changes the dashboard display
Dashboard content = whatever is affected by the top-level equipment context (Router vs. Extender). Home is the lowest level L1 that affects the dashboard. Router GUI has no "Account" or "Profile" settings — a key insight that removed a major source of navigation clutter.
Navigation Level: L1 / Visible Links
What can be exposed as a primary navigation item
Home (Level 1, with dashboard). Wi-Fi Networks (consideration: is this a lower level than Home?). All Devices. The classification principle: items that require immediate access based on frequency of use and time-sensitivity of the action.
Navigation Level: Hamburger Menu
Quick links for frequently-needed but non-primary features
Sign out, Reboot router/extender, Change router/extender password, Adding sign-out, Help, Open Source Software. The hamburger menu principle: actions users need occasionally but would find disruptive if permanently visible.
The key insight about "Visible L1s": No Account or Profile. Router GUI experience has no "Account" or "Profile" related settings or actions. This reduced the L1 navigation to its true functional scope and eliminated a pattern that would have created confusion between the router GUI context and the broader Verizon account management context.

Current vs. Proposed IA — The Definitive Comparison

The most important single artifact of the engagement — showing exactly what changes, what moves, what gets added, and what gets removed between the current v3.2.0.14 structure and the proposed v3.3 structure. This was the document that aligned all stakeholders.

CURRENT vs. PROPOSED IA — v3.2.0.14 → v3.3 (for PrplOS) Full comparison in Figma →
Current vs Proposed IA comparison
CURRENT v3.2.0.14 → PROPOSED v3.3 (PrplOS) — Navigation Structure
CURRENT v3.2.0.14
Home Dashboard
Wi-Fi
Devices
Security & Firewall
Network Settings
Diagnostics & Monitoring
System
PROPOSED v3.3 — PrplOS
Home Dashboard
Wi-Fi networks
All devices
Security
Network settings
Systems
Tools ← NEW GROUP
Name changed
Item removed
Item added
Placement changed
Top: Current v3.2.0.14 structure with 7 main navigation groups and the problems they create. Bottom: Proposed v3.3 structure (for PrplOS) with reorganized groupings. Legend: Name Changed (yellow), Item Removed (pink), Item Added (green), Placement Changed (blue). Every single change is justified and traceable.

05 — Recommendations

Short-Term & Long-Term —
Two Tracks, One Strategy

The recommendations were structured as two parallel tracks — not because they were separate projects, but because they had different implementation dependencies. Short-term changes could be applied immediately. Long-term changes required platform migration work that the tech team needed to plan separately.

This two-track framing was a deliberate strategic choice: it prevented the "we can't do it all at once" objection from blocking the changes we could do immediately.

SHORT-TERM Implementable immediately — no platform migration required
No-exposed L1s in navigation — reducing the visible navigation links to only what's necessary, with rationale documentation for each decision
Top navigation cleanup — clean nav bar since links are already prominently displayed in the Left menu panel. Reduces duplication.
Help link updated to VDS 3.0 standards — opens the "Help" modal giving customers access to multiple support destinations
Mode as radio button dropdown — Basic/Advanced considered as "states" not tabs. Tabs switch between related content; states change the entire interface context.
Left menu panel retained — guides the customer through all features and capabilities. Removing it would increase discovery friction.
Hamburger menu on mobile — appears when Left menu panel disappears on tablet/mobile so users can continue navigating features
Label recommendations with rationale — each label change documented with the usability principle it serves
LONG-TERM Requires platform migration — planned for future development cycles
Left rail items as Nav L1s — moving the current left panel structure into the top navigation bar for alignment with Verizon's broader customer experience standards
Verizon Wordmark as nav anchor — the Red Checkmark or future Verizon Wordmark as the home anchor. Clicking opens Verizon.com in a new tab (web version)
Gnav links in top navigation — left menu panel structure moved to top navigation. Left-aligned, spaced appropriately from Verizon icon per brand standards
Equipment dropdown as top-level selector — selects between different equipment (Router, Extender). Changes the Home screen and all Gnav link options dynamically
Advanced mode toggle on dashboard — "Basic / Advanced" moved from top navigation to the dashboard. Boolean attribute, not a destination. Hidden for extenders (no advanced mode).
Desktop and mobile viewport mocks — full responsive implementation with expanded view documentation for edge cases

Short-Term Recommendation — Rationale

Every recommendation came with explicit rationale — not "this looks better" but "this is why, grounded in usability principles and VDS 3.0 standards."

SHORT-TERM RATIONALE — Numbered component decisions with design logic View in Figma →
Short-term recommendation rationale
Top navigation, Help modal (VDS 3.0), Mode as radio dropdown, Left menu panel, Hamburger menu — each numbered and documented. Left: old design. Right: short-term recommendation with annotated components. The red/pink highlight system shows exactly what changes and why.

Long-Term Recommendation — Rationale

LONG-TERM RATIONALE — Top navigation migration with Verizon brand standards View in Figma →
Long-term recommendation rationale
1. Verizon icon (Red Checkmark or Wordmark). 2. Gnav links — left-aligned, consistent with Verizon brand standards. 3. Equipment dropdown — drives context for entire dashboard. 4. Advanced mode toggle — boolean state, not navigation destination. Each decision references specific VDS 3.0 requirements.

06 — Key Design Decisions

The Calls That
Defined the IA

Information architecture decisions sound dry until you understand the user impact. These are the moments where we had to choose between technically-correct options — and the reasoning that made one choice clearly better than the other.

DECISION 01 — Most Impactful
Tabs vs. Radio buttons for Basic/Advanced Mode
The current design used tabs to switch between Basic and Advanced mode. This seems intuitive — until you apply VDS 3.0 and standard interaction principles. Tabs switch between related content of equal status. Basic and Advanced are not related content of equal status — they're states of the entire interface.
CURRENT (WRONG)
Basic / Advanced as tabs in the top navigation. Problem: tabs signal "here are two views you can easily switch between" — but Advanced mode changes the entire navigation structure, not just the content panel.
VS
PROPOSED (CORRECT)
Basic / Advanced as a radio button dropdown on the dashboard. Signals: "this changes your mode of interaction with the whole system." Consistent with VDS 3.0. Hidden for extenders (no advanced mode exists for extenders).
VDS 3.0 reference: The Verizon Design System explicitly defines tabs as "used to quickly switch between related content." Basic vs. Advanced mode is not content-switching — it's context-switching. The distinction sounds subtle but affects user mental models significantly.
DECISION 02 — Most Contested
Keeping the left menu panel vs. moving everything to top navigation
The long-term direction moves navigation to the top bar (Gnav pattern, consistent with Verizon's broader customer experience). The short-term recommendation retains the left menu panel. This created tension: if the long-term direction is top navigation, why not start there immediately?
Why the phased approach was correct: The left menu panel, despite not matching the long-term Gnav pattern, actively guides users through a complex feature set that most users access infrequently. Removing it immediately — without the supporting Gnav implementation — would have left users with a navigation vacuum. The phased approach protected the user experience during the transition period rather than optimizing for architectural purity.
DECISION 03 — Most Research-Intensive
What qualifies as a Visible L1 navigation item
The taxonomy matrix was built specifically to answer this question objectively. After classifying all 60+ features across 11 dimensions, the L1 eligibility criteria became: items that are Equipment-affecting OR Dashboard-affecting AND frequently accessed by a broad user segment. Features that were TRUE only for "Information" or "External link" were systematically removed from L1 consideration.
What this removed from L1 that "felt" like it should be there: Open Source Software (TRUE for External link only — not a navigation destination), Help (moved to modal via hamburger — not a page destination), several diagnostic tools that are rarely accessed and not time-sensitive.
DECISION 04 — The PM Situation
Pushing back on the PM's unsupported structure proposal
The PM's proposed "new structure" was created without research, without a taxonomy framework, and without competitor reference. Accepting it would have been easier. It had executive backing. But it would have produced a navigational system with no defensible rationale — and would have failed usability review.
THE EASY PATH
Accept the PM's structure, build mocks, ship. Avoid the conflict. Let usability testing fail it later.
VS
THE RIGHT PATH
Build the evidence. Create the visual "Current vs. New" comparison. Let the data argue for the correct approach. Accept the short-term friction for the right long-term outcome.
What made this work: We never argued against the PM directly. We showed the mapping. The colored lines connecting items between structures made the structural problems visible without requiring anyone to understand IA principles. Visual evidence is more persuasive than verbal arguments in stakeholder environments.

07 — The Figma File

5 Months of Work —
All in One File

The Router GUI 3.3 Navigation Figma file contains every artifact from the engagement — organized by month, with archive pages for discarded directions and a competitor audit section documenting the research that informed the final recommendations.

ROUTER GUI 3.3 NAVIGATION — Figma file overview Open Figma file →
Figma file overview - Router GUI Navigation
The Figma file structure: Pages include Recommendation Deck [May 20...], Recommendation Deck [July...], Sandbox, Competitor Audit, Month 1–5, and Archive. Month 2 is shown — containing Dashboard mocks, Visible L1 analysis, and Hamburger menu classification. The layered structure captures the full 5-month process.

Final Deck Presentation

The final stakeholder deck captured the complete journey — from IA audit to short-term and long-term recommendations, with full rationale for every decision and an appendix containing the taxonomy matrix and help structure documentation.

FINAL DECK — Router GUI Nav. Recommendations Open deck →
Final deck presentation overview
The final deck structure: Frame (cover) → Current vs. Proposed IA → IA Review → Navigation Changes → Short-term recommendation → Rationale → Long-term recommendation → Update & viewports → Expanded view → Design phases → Appendix (Taxonomy + Help). Every section flows from evidence to recommendation to rationale.

08 — Obstacles & Resolutions

What Tried to
Break the Project

Obstacle
PM-proposed structure with no research basis
A project manager proposed a new navigation structure based on intuition rather than research. It had organizational momentum. Rejecting it required evidence, not opinion — and the political skill to present that evidence without making the PM defensive.
Resolution
Built the "Current vs. New" visual mapping with colored lines showing exactly what was changing and why. Made the structural problems visible without requiring IA expertise to understand. The data argued for us.
Obstacle
Competitor dashboards behind authentication walls
Standard competitor analysis was impossible — router GUIs only appear after hardware configuration. We couldn't create Netgear accounts on a test basis; the interface requires physical router setup.
Resolution
Recruited people in our network who already had competitor routers at home (Nighthawk, Xfinity, ASUS). Conducted structured walkthroughs via screenshare with a defined audit protocol. Turned a research blocker into a user interview.
Obstacle
60+ features with no agreed classification framework
Before the taxonomy matrix existed, every placement decision was argued individually. There was no shared language for "this should be L1" — everyone had intuitions, nobody had criteria.
Resolution
Built the taxonomy matrix with 11 dimensions before making any placement decisions. Once the framework existed, placement decisions became mechanical — apply the criteria, get the answer. Removed opinion from the process.
Obstacle
Short-term and long-term recommendations requiring different tech capabilities
The best long-term navigation solution required a platform migration (PrplOS). Presenting only the long-term direction would have created a "we can't do this now" impasse. Presenting only the short-term would have ignored the right answer.
Resolution
Explicitly split the recommendations into two tracks — labeled clearly as "Short-term: implementable now" and "Long-term: requires migration." This prevented the roadmap from being blocked by implementation constraints while keeping the long-term vision intact.

09 — Impact & Learnings

What 5 Months Inside
Verizon Taught Me

60+
Router GUI features classified across 11 dimensions in the taxonomy matrix
3
Navigation levels definitively classified: Dashboard, L1, Hamburger — with objective criteria
2
Recommendation tracks delivered — short-term (immediate) and long-term (migration-dependent)
01
Visual evidence beats verbal argument in enterprise environments
The PM conflict was resolved not by a better argument but by a better artifact. The "Current vs. New" mapping with colored lines made the structural problem visible to someone who had no IA background. In large organizations, the designer who can translate complex reasoning into visible evidence wins the room. Verbal arguments get forgotten; visual evidence gets shared.
02
Build the framework before making the decisions
The taxonomy matrix took time to build. Every hour spent on it saved three hours of individual placement debates. Once the classification framework existed, placement decisions became near-mechanical. Building the framework is the work — not a preliminary to the work. This is what senior design looks like: investing in the structure that makes all subsequent decisions faster and better.
03
Research constraints are problem-solving opportunities
When competitor dashboards were blocked by authentication, the instinct might be to skip that part of the research. Instead, we turned it into a user research session — structured walkthroughs with actual router owners. This produced richer data than a solo audit would have, because we were capturing real mental models and real pain points, not just screenshots. Constraints force creativity.
04
Two-track recommendations prevent implementation paralysis
Presenting short-term and long-term recommendations together, explicitly labeled, solved a common enterprise UX problem: the "perfect is the enemy of good" impasse. By giving stakeholders an immediately-implementable path and a future-state vision simultaneously, we prevented the long-term recommendation from blocking the short-term improvements. Both tracks advanced. Neither blocked the other.

Explore the Full Figma File

The complete Router GUI 3.3 Navigation file — all 5 months of work, all artifacts, full taxonomy matrix, recommendation decks, and appendix.

ROUTER GUI 3.3 NAVIGATION — Interactive Figma file Open full file ↗
Router GUI 3.3 Navigation — 5 months of IA work. Navigate through Month 1–5, Competitor Audit, Recommendation Decks, and Appendix pages directly in the embed.
Explore the Full Work
Router GUI 3.3 Navigation Figma file — all 5 months, taxonomy matrix, IA maps, recommendation decks, rationale, and appendix. Plus the final stakeholder deck.
Open in Figma View Final Deck ← Back to Portfolio