STAT 2’s Design Sprints
How we modernized STAT incrementally through a repeatable design sprint process that kept UX ahead of Dev without sacrificing research, validation, or confidence in our decisions.
Scroll down to view my process
Context
After 14 years of the same design and frontend framework, the UI/UX was now one of our top pain points and costing us clients at a faster rate.
To retain existing clients and close new deals, I convinced the company that STAT needed a full UI/UX modernization and needed to be built on a modern framework to move faster going forward.
A decision was also made to release each section as it was completed (instead of all at once) in an attempt to retain unhappy clients and to demo it to prospects.
Strategy
So with all that, here’s the redesign process we went through for each section of STAT
Step 01
As this rebuild was also an opportunity to simplify and streamline STAT, the first thing I wanted to do was a pass on the current functionality myself. I was looking for anything that jumped out and may need to be updated, or reversely, anything that I liked and should try to keep. This was the start of my list of recommendations to surface to the team.
Anything I felt needed more information gave me some starting questions for research interviews and usability tests.
Step 02
I then dug into the Pendo data for every interaction within each section.
This showed us what features were used the most, and which ones could be cut, modified, or postponed for future sprints.
Step 03
I would go through old interviews and our other repositories and overlay the relevant feedback from them directly onto the screens.
This gave me a better view of everything that could be fixed, and made it easier to communicate the issues and my recommendations to the team.
Step 04
I also conducted a competitive analysis of leading SEO analytics platforms to understand where STAT stood out and where it lagged. By comparing similar workflows, interactions, and visualizations, I identified opportunities for the redesign.
Step 05
Productboard was where we kept the feature requests we had already vetted for impact and effort.
As I went through the design process for each section, I would pull in any low-effort requests found in Productboard and add them to my list of recommendations to review with the team.
Step 06
Working directly in Figma, I would run the team through the user pain points, relevant data, and improvement ideas. This created a shared visual reference for discussions with engineers and PMs and allowed us to begin locking down the deliverables for the section we were working on.
We would create a first draft of the requirements for v1, and anything that needed more information would turn into a question I could ask at our upcoming research interviews.
Step 07
I would then conduct a handful of research interviews in order to answer the questions from my team so we could confidently solidify the remaining requirements for v1.
We did not need many participants as we were mainly looking for insight on why some features that do not have a lot of usage may or may not be important. This would help us refine our scope for v1.
Step 08
I would report the findings from the interviews to the team and we would lock down the requirements for v1.
I then translated everything into proper documentation for the Dev team. This living document aligned the team around what needed to be solved, why it mattered, acceptance criteria, and how we would measure success.
Step 09
Now it was finally time for pen-to-paper.
I would map out user flows and create low-fidelity wireframes to visualize and validate initial ideas. These wireframes served as the foundation for usability testing before evolving into refined high-fidelity designs with consistent UI patterns.
Step 10
As this redesign was a big deal, I made sure we budgeted time for Usability Tests.
For each section, I defined research goals and wrote test scripts, recruited participants, and conducted sessions.
Synthesized insights from these tests directly informed our design decisions, ensuring that our final output truly enhanced the UX of our product.
Step 11
High-fidelity mockups were then built in Figma and then tested one more time with users.
This allowed us to vet the final designs and see if there were any further areas to improve before passing it off to Dev.
Step 12
Dark Mode was going to be a new addition to STAT. This meant we had a lot of colours that needed to meet WCAG guidelines.
The SERP Features tab is a great example of this as I had to go through 144 colours currently being used for the icons and data visualizations. I then had to tweak those colours so they would pass AA standards, then create a whole new set of colours for Dark Mode.
In the end, there were close to 300 different colours on the SERP Features tab alone (that now all pass AA standards).
Before anything was finalized, I would organize audits with our Accessibility Agency who would point out anything we may have missed.
Step 13
Final designs were then broken down into scalable components, complete with interaction specs and annotations for the Dev team. I led asynchronous design reviews with engineers and PMs, addressing edge cases early and collaborating closely during handoff.
Throughout the process, I ensured technical feasibility and adapted designs based on feedback and implementation realities.
Step 14
As each section was built, I then set up Pendo hooks and Microsoft Clarity on everything so we could begin collecting data immediately upon release and monitor usage.
I also leveraged Pendo’s feedback forms to collect qualitative feedback and requests from our users that could then inform updates and fixes.
Et voila!
The Outcome
Since STAT 2.0 was released as a separate product, engagement was extremely low until everyone was forced to move over to the new version. Once that happened:
Bonus UX Outcomes:
STAT 2’s Design Sprints E2Diving into our repeatable design process
