The Problem
Astra’s original front-end used a Bootstrap theme called Metronic. Unfortunately, it was so outdated there was no easy upgrade path. It was difficult to work with for our team of mostly backend engineers, and much of the technology it relied on was either no longer supported or outright deprecated.
It was also a major contributor to Astra's usability issues. Astra's front-end was inconsistent, inaccessible, and an eye-sore.
The Challenge
From a design perspective, my biggest concern was resourcing. A major overhaul was clearly warranted, but as a design team of one supporting two product squads, I was cautious about taking on such a large project.
With that in mind, I started looking at component libraries we could leverage to de-risk a potential redesign. I narrowed down a long list of possibilities, then created a ranking system to help us make a decision as a team. After some healthy discussion, we chose TailwindUI as our system's base.
Getting started
With our base selected, I started experimenting with visual treatments. Wunder had never invested in a brand, so I facilitated a mini brand sprint with the founding team to establish some general guidelines.
I translated those guidelines into a few UI mood boards and shared them with the Head of Product. We considered the needs of our users and the constraints of our team to land on a visual style that was (1) well-suited for dense pages with lots of data, and (2) simple enough for non-designers to work with safely.
Design approach
To structure the system, I chose the Foundations model described in Andrew Couldwell's phenomenal book Laying the Foundations. With Tailwind taking care of most of the foundational styles for me, I started building out the basic components – buttons, inputs, navigation, etc.
Because I was building for a small team with limited Figma experience, I kept the component structures as simple as possible (although I did go a little ham on the Buttons). That said, I was careful to avoid configurations that would make adding new variants a pain down the line.
Implementation strategy
While I was building out components, I worked with a PM and Senior Engineer to agree on what the rollout should look like. We decided to go one page at a time, with exceptions for key flows that were spread across multiple pages.
We used a simple framework – traffic plus technical complexity – to organize pages into batches, and then prioritzed those batches to minimize risk by (1) giving us time to catch and fix bugs in a production environment, and (2) minimize disruption to critical business flows. That prioritization looked roughly like this:
- Low traffic, low complexity pages
- High traffic, low complexity pages
- High traffic, high complexity pages
Speed enables focus
As Apollo reached a critical mass of components and patterns, I started seeing the benefits to my design workflow right away. I began using Apollo components to quickly shape and sketch solution concepts, making improvements as I found opportunities for them.
With Apollo in place, I was able to spend far less time worrying about cosmetic details and more time focused on finding the right solutions to Astra’s toughest problems. I was thrilled. 😍
