SurveyMonkey, 2025
Status: in development
Duration: 1 year to date
Role: Project Design Lead
Headers
Goal
The goal of this project was to deliver a simpler and consistent header experience across all of SurveyMonkey’s surfaces. This project was part of a larger effort to improve SurveyMonkey's overall navigation experience.
Outcome
We developed a new header framework that reduced 17 distinct headers down to just 4, applied across all surfaces. Each of these 4 new headers was built using a single, shared header component. In addition, we introduced a new subheader component to support navigational pathways that align with the key user jobs of each surface. One of my proudest personal achievements during this project was gaining cross-functional senior leadership buy-in for the new header framework.
Results to date:
Reduced landing page load time by 7 seconds — from 10s to 3s — for logged-in users clicking the SurveyMonkey logo, by implementing the new header component
Saved header real estate and increased monthly account menu clicks by 14.7% — from 950,598 to 1,090,434 — by replacing the user email address with an avatar in headers that previously displayed the email address
4 new headers, built using a single header component. Top to bottom: Marketing header – logged-out, Marketing header – logged-in, Product header – logged-out, and Product header – logged-in.
User problem
Over the years, product and marketing teams at SurveyMonkey built their own headers to meet their individual project needs. The lack of a holistic view and vision resulted in 17 different headers across 8 surfaces. Each header was different in terms of behavior, controls, content and visual design. This inconsistency, combined with a complex platform architecture, created friction for customers and interfered with their path to value.
SurveyMonkey’s 17 different headers at the start of this project.
All surfaces and their headers.
Business problem
The headers existed in different repos across several teams, and were built using custom code. Because of this, we were not able to implement and ship changes quickly: it took about 8 weeks to ship a change to a single header. Amplitude was partially implemented for a few headers, but it was unclear how so we didn't have confidence in the data. By reducing engineering overhead and implementing tracking across all headers, we would be able to move faster and make decisions informed by accurate data.
Solution
There were two parts to our solution: a new header framework, and a new header component.
New header framework
We've created a new header framework that reduced 17 headers down to just 4, applied across all surfaces:
Marketing header – logged-out
Marketing header – logged-in
Product header – logged-out
Product header – logged-in
User jobs were at the heart of the new header framework, as any navigation experience should be guided by what users are trying to accomplish with their software product. We re-organized all user jobs across our platform into two categories: Marketing jobs and Product jobs. Marketing jobs focused on exploring our product offering, while Product jobs focused on survey building and analysis. We considered these two job categories foundational to our platform. Each category contained both a logged-out and logged-in header, designed to support the respective user jobs for each state.
The new header framework.
By only supporting Marketing and Product headers, we significantly simplified the user's perceived structure of our platform — reducing it from 8 distinct surfaces to just 2: our Marketing surface and our Product surface. Perceived, as we didn't consolidate surfaces, but replaced the headers of each surface using the new framework.
Example of the header framework applied to one of the 17 headers: the logged-out Help Center header. The primary users of the logged-out Help Center are visitors arriving from Google, searching for answers to specific questions. This behavior fits well within the Marketing jobs category. Showing the Marketing header may encourage exploration of our product and help drive sign-ups.
Another example of the header framework applied to one of the 17 headers: the logged-in App Directory header. From the App Directory surface, users can manage their connected apps and browse for new ones. Integrating SurveyMonkey with other apps helps users get more out of our platform — both during survey building and during analysis. This aligns best with the Product job category, making the logged-in Product header the appropriate choice.
New header component
All 4 headers were built on a newly created, shared component — one that previously didn’t exist in our design system. This component incorporated smaller design system controls, such as buttons and tabs, and was designed to responsively adapt across all screen sizes. We also introduced a new subheader component to support navigational pathways that align with the key user jobs of each surface.
We're currently experimenting with the logged-in product header. We recently implemented Amplitude tracking and replaced the user email address with an avatar to free up space — this update is now live on production.
Part of the new header component specification.
Challenges
One of the most challenging aspects of this project was understanding the setup of our own platform — and, with that, grasping the scale of the problem we were trying to solve. Every few weeks, we would uncover a new header, often by accident, as some were only visible to certain accounts and unknown to our team. Ownership was often unclear, as many headers had been created years ago by teams that no longer existed. Once we had established a roughly 90% accurate view of all headers and their interactions, we defined governance rules around ownership and change management, before moving to a new solution.
Another key challenge was managing the impact of header changes on multiple fronts: ensuring key metrics remained stable despite significant changes needed for consistency, coordinating with teams whose roadmaps were disrupted by required updates, and aligning a wide range of stakeholders — including senior leadership, PMs, designers, and developers — throughout the process. We addressed this by establishing a fixed, recurring alignment with leadership and individual teams, ensuring they were part of our thought process and involved in decision-making along the way.