Unblocking My Team With Design

Background

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

• 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

This topic always makes me think of my time working for a non-profit (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. I 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.

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

So there I designing in the Figma file for this navigation restructure, trying to decide if one of the legacy menu options actually needed to exist at all, when I sent a question to my engineering squad:

“Has anyone actually ever clicked this? What do our analytics say?”
“Oh, we have no idea. We never set up instrumentation on that.”

SIGH. This was not a one-off occurrence.

“Oh I have the main nav, but none of the secondary items inside.”
“We know when a screen changes, but not the entry point used.”
“No, no timestamps, so we can't know if a user immediately bounced.”

I know that all metrics are a proxy to measure actual user goals, but c’mon now. Give a girl some options!

Without reliable analytics, I led our team to adopt alternative measures that spoke to the quality of the work we were delivering and how well it supported user needs. Each of these measures came with their own disadvantages, and on reflection I still today would have preferred something that captured actual user behavior instead of sentiment or lagging proxy metrics.

That said, I believed it was important for our team to have something concrete we could actually work toward and test:

• 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%.

Lastly, I never again wanted to be in the position where I was fighting to learn basic information like "has anyone ever clicked this." So, as part of this new navigation redesign, I 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.

And when a designer doesn’t know something, that means it's time for discovery!

In January 2024, I sent a survey to ask the engineering team about their perceptions of working with design and what they’d like to see in the future. I followed this up with a retro where we could discuss the anonymous results as a team and plan together for a better way of working across engineering and design.

What I learned was 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.

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."