--- title: 'Workiva: Enterprise Navigation Structure' url: 'https://jessmeister.com/my-work/shell-redesign' markdown: 'https://jessmeister.com/my-work/shell-redesign.md' date: '2024-08-05' description: "Background Contents Background Getting Buy-in Defining Success Building the Thing When I joined the Workiva's architecture team as their lead designer in 2024, the team was already halfway through redesigning the platform navigation structure with a lot…" taxonomy: category: - portfolio tag: - 'info architecture' - 'design docs' - leadership - B2B --- # Workiva: Enterprise Navigation Structure [](#)# Workiva: Enterprise Navigation Structure ![](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/shell-banner-1920x640.png)## Background ### Contents 1. [Background](#background) 2. [Getting Buy-in](#buy-in) 3. [Defining Success](#success) 4. [Building the Thing](#build-it) When I joined the Workiva's architecture team as their lead designer in 2024, the team was already halfway through redesigning the platform navigation structure with a lot of things going well: - The opportunity had come directly from user satisfaction surveys that pointed to difficulty navigating the platform. - The company had prioritized this work as one of that year’s OKRs. - The product manager, researcher, and previous designer had explored a few early concepts with positive customer reception. And yet, progress had ground to a halt. **Why?** This case study describes how I diagnosed and overcame the challenges with leadership buy-in, strategic direction, and engineering collaboration that had stymied the team's momentum. My approach resulted in improved quality outcomes for the product we shipped and significant acceleration of delivery for my cross-functional team. ## Key Outcomes [ ![](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/shell-outcomes-1.png "As of September 2024: 1. Completed audit of all available/missing analytics 2. 80% of known desired analytics now in place 3. Moving forward, analytics now a part of all release process.") ](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/shell-outcomes-1.png) [ ![](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/shell-outcomes-4.png "As of September 2024: Exceeded target goals for usability, 88.9% participants indicated the Global Nav is easy-to-use and meets their needs, ") ](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/shell-outcomes-4.png) - Gained leadership approval on proposed design direction that had previously stalled for three months. - Enabled engineering to build a functional prototype in **one day** after months of "not being able to start." - Improved engineering assessment of design collaboration to "Going great" by every measure. - Achieved 89% ease-of-use score (quality target = 70%) on new design, with <0.33% Daily Active Users opting out. ## My Approach > “It is a truth universally acknowledged, that a product team in possession of a good idea, must be in want of the permission to build it.” Jess Meister 2026 Starting off, I noticed that there were several barriers that were preventing the team from moving forward: product and design leadership had yet to sign off on the work (this will definitely stop you in your tracks!), the team had no shared goal of what they were actually building or what success looked like, and my engineers were saying they did not have what they needed to get started. I felt confident there were two things I could do to help our team regain momentum. First, I needed to establish buy-in and trust from leadership to unblock our path. And second, I needed to define a measurable outcome our team could rally around. And, I needed to figure out what the heck engineering was missing to let them start building, immediately. ## Establishing Leadership Buy-In ![](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/jenna-14oz.jpg) Favorite mug at my non-profit job. It's 14 fl oz! This topic always makes me think of my time [working for a non-profit](https://jessmeister.com/my-work/oha-ux) (quick detour!). One day, I was lamenting to our Fundraising Officer that simply doing good work was never enough: I always had to *sell* it to our funders. Her response has stuck with me for years: > “Jess, there are two parts to trust. One: do they trust the quality of work itself? And two: do they trust you, as a person?” This fully upended my perspective on design: for good work to happen, you had to design *both* a high-quality product *and* design the way people are meant to encounter and think about it. Back to 2024 and the navigation redesign, it was evident that my team had demonstrated neither. We had to move quickly. When I inherited this work, the planned delivery release was **only 8 weeks away**. That’s a massive problem if your CPO and VP of UX are *not* on board with what you are doing. So what did I do? #### 1. Built trust in the *work* - Completed a competitive analysis of our work to ground our decision-making in the context of industry standards and increase our level of design rigor and evidence. - Gathered the few analytics I could (more on that later) to demonstrate architectural change rationale. - Polished the visual UI to establish a quality-first impression with customers. - Presented to leadership our design rationale, connecting each decision directly to user insights or other data. ![](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/nav-competitive-1000x173.png)FIGURE: Snapshot of items in my competitive analysis, used in part to inform architectural changes to the new navigation structure. #### 2. I built trust in the *team*: - Kicked off a recurring series of design reviews with leadership to invite feedback and uncover blockers. - Shared my design project plan, connecting it to the delivery plan to prove our ability to execute against the estimated delivery timeline. - Posted regular progress updates and my design iterations on Slack for higher visibility. #### Outcomes: Leadership Buy-In Evidence of trust can often be more of an *absence* of activity than anything else. The number of times the CPO reached out on Slack to inquire about the project went from every day to only once a month or so. My design manager stopped hearing concerns from the VP of UX on the health and quality of the project. And—most importantly—leadership gave us a green light to move forward! ## Defining Success Metrics When I joined a team, I asked my engineers a question that I thought would have been incredibly easy to answer: *“Has anyone actually ever clicked this? What do our analytics say?”* *“Oh, we have no idea. We never set up instrumentation on that.”* Unfortunately, this was not a one-off occurrence. The team did not have reliable analytics. This made it harder for us to make decisions and define how we knew if this project were successful. I believed it was important for our team to have *something* concrete we could actually work toward and test, so I set the following measures for us: - Quality Goal: 70% or more of our early adopters would say the new navigation was “easy to use.” - Adoption Goal: Less than 2% of users would opt out or revert to the legacy navigation. - Business Impact: Tickets with negative sentiment on “navigation” or “findability” would decline by 40%. I also **never** wanted to be in the position where I did not have access to basic information like "has anyone ever clicked this?" and partnered with our researcher and resident data nerd (complimentary) engineer to implement robust instrumentation on our new navigation design, for the next time we would need it there. ## Building the Damn Thing Unlike my sensing around stakeholder needs and strategy that guided our success measures, **I had no idea** why our engineering team didn’t feel confident moving on this work. Time for discovery! In January 2024, I sent a survey to engineering team on their perceptions of working with design and led a retro to discuss the results and plan for a better way of working across engineering and design. I saw that the most urgent areas I needed to address (inclusive of leading into the navigation delivery work) were the quality of the design documentation, level of visibility and collaboration from UX, and timeliness of ad-hoc support received. ### Design Documentation After months of delay and stalling out on progress on the navigation, my engineering team organized a week-long jam to build a proof-of-concept for our new navigation structure. And I was invited to join! Knowing that my team had identified design documentation as a challenge, I fully rebuilt the Figma file, adding robust architectural documentation and comprehensive interaction annotations. It felt like a bit much, but I elected to lean more maximalist given my short tenure with the team and the team survey results. We kicked off the jam with me spending 10 minutes walking through my design documentation on the new navigation structure and giving my engineers a high-level introduction to Figma DevMode. #### Outcome: Design Docs By the end of Day 1 of the engineering jam, the team had built **a fully functioning prototype** of the new shell navigation based solely off of my Figma mocks and documentation. This had followed two full months of the engineering team expressing that they did not have the right information to start. [ ![](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/shell-2024-all.png "Navigation design docs: full page, marked as ready-for-dev") ](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/shell-2024-all.png) [ ![](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/current-vs-new-png.png "Navigation design docs: demonstrating major visual differences at-a-glance") ](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/current-vs-new-png.png) [ ![](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/figma-annotations.png "Navigation design docs: snapshot of annotation detail, including logic, interaction design, and design system guidance") ](https://jessmeister.com/user/pages/03.portfolio/15.shell-redesign/figma-annotations.png) ### Design Rituals & Support I am someone who believes strongly in the power of process, but only when it demonstrably serves a need or improves outcomes. My new architecture team was surprisingly hungry for standardized rituals around how/when they saw design work, so I established a few practices to support that need: - I kicked off a weekly UX/eng sync, where I would show WIP design and engineers could ask whatever questions they wanted about anything, really. - I attended the refinement sessions for work that was based on my designs. - I ensured I was responsive to Slack questions within a day or two, and updated all design documentation if need be. #### Outcome: UX/Engineering Collaboration After six months working with the team, I sent out the same survey I had at the start to see how things were going. I’m incredibly proud of the results I had with my team: every aspect of collaboration between engineering and design had increased from "Not good/OK" to "Going Great." --- ## Navigation - Parent: [My Work](https://jessmeister.com/my-work.md) - Previous: [Tooth Wisdom: Health Education for Seniors](https://jessmeister.com/my-work/tooth-wisdom.md) - Next: [John Deere: Dealer Service Management](https://jessmeister.com/my-work/dealer-mgmt.md)