How to push the limits of a design system
Partnering with product teams to evolve Polaris
To keep up with the demand, a design system needs to evolve continuously. Ironically, the evolution of design systems seems to be a bit of a chicken and egg problem.
The team working on the system can’t evolve without knowing what product teams need. On the other hand, most teams play within the existing boundaries of the system, which doesn’t help pushing it further. It’s a stalemate.
In the Polaris team we want to break that stalemate, so we made our move…
Bridging the gap
To prevent Polaris becoming stale, we knew we had to get closer to the product. So we started an initiative we called PolarisLab, a series of workshops and pairing sessions with product teams over the course of several weeks, focused on a specific topic. The goal was simple: work closely with product teams to:
- Help teams find the best possible solution to their problem.
- Build a better understanding on how we should evolve our design system.
Our first focus was Layout because we started to notice more and more pages in our experience felt like they weren’t specifically designed for a problem. Instead, they rely on established templates (in the form of a page layout component) that are fairly generic, but aren’t always the best solution to a unique problem.
The overuse of such templates may make it seem like pages are visually consistent, but contributes to making the experience feel unintentional and lacklustre. By following a rigid template, the content has to adhere to the page
The overuse of templates may make it seem like pages are visually consistent, but contributes to making the experience feel unintentional and lacklustre.
layout rather than the other way around. This can make it hard to read and navigate through a page, requiring a lot of effort from users to figure out where to look, and what to do next.
We also noticed that our Layout components were too rigid because teams often break away from Polaris to do very simple layout tweaks, and this contributes to the increase of hardcoded solutions. At this point, we knew what we wanted to solve, and even had a name, but we were missing the most important piece.
Finding a team
We were hoping to find teams that were interested in collaborating with our team to improve Layout, but even more importantly, teams that were keen in evolving Polaris. Luckily, there was no shortage of teams that fit the description.
We met with seven different teams, and after connecting, and getting an idea of their problem space and timelines, we decided to move ahead with the amazing folks working on B2B Customers because they checked all the right boxes:
Impactful problem to solve ✔
Potential to be relatable and inspiring to other teams ✔
Pressing deadline (meaning that this collaboration has to produce something we can ship soon) ✔
Super excited to get started ✔
From there, we defined the scope of our collaboration and got started shortly after. The set up was simple:
Step 1: Understand the problem
Step 2: Diverge and explore
Step 3: Converge and calibrate
Step 4: Repeat 2 and 3 until satisfied
Step 5: Build it!
Understanding the problem
We got a better understanding of the problem through a series of workshop activities.
We started by asking the team to do a context dump. Simply by dropping a series of screenshots and designs on a Figjam, and walking us through the problem, and the solution they landed on.
Together, we realized that this B2B customer page was mostly an aggregation of everything that relates to a business customer, but it wasn’t doing a great job at helping merchants to understand this particular customer with a quick glance. The content lacked a clear hierarchy, so ended up competing.
To start making sense of this, and having a better idea of what were the most important things, we identified and wrote down all the jobs that experience was trying to accomplish. Then we moved the sticky notes around to figure out priorities. This is where we landed:
- Observing purchasing behaviour
- Placing orders for customers
- Quick access to location and contacts
- Evaluate how locations are performing against each other
- Changing terms across multiple locations
- View and troubleshoot issues/changes
We discussed as a group, and made sure we all agreed on the order. Then we followed that by taking a stab at writing an hypothesis to make sure we were all on the same page, and then voted on the one that felt most accurate, which was:
“If the information displayed is focused on a single lens, merchants will be better equipped to act. We can measure this by the amount of time spent on accomplishing a particular task.”
All this work wasn’t meant to produce an actual deliverable, but instead to enable everyone to:
- Ramp up context, so everyone is on the same page.
- Start critically prioritizing content because we can’t achieve a more intentional layout just by moving elements around. We need to start from the information layer, and build up from there.
To take everyone one step further, the following exercise was to sketch as a way to ideate potential solutions to the problem. The goal here wasn’t necessarily to find a solution, but instead to set the tone for the exploration ahead.
Everyone participating in the workshop was encouraged to sketch, no matter if you’re an engineer or a designer. Some sketched on Figma, but most just grabbed a piece of paper and a pen, and once they were finished, took a picture and dropped it into the FigJam.
By getting people to sketch freely, without the constraints of a design tool or a Figma library, we’re more likely to encourage creative solutions to the problem that don’t necessarily follow pre-existing templates. After a bit of
By getting people to sketch freely, we’re more likely to encourage creative solutions to the problem that don’t necessarily follow pre-existing templates.
time sketching, everyone shared what they came up with, and we realized something interesting. Whilst sketching, people started to think of the purpose of the page as a whole, rather than focusing on individual pieces of content and then assembling them together following a template.
This is great, because merchants will experience the page a whole, so that’s how we should be designing.
After everyone shared, we discussed and voted on the most promising ideas, which set the stage for the next step.
Diverging and converging
We had a few more workshop sessions which included a product manager and a couple of engineers, to align and discuss, since the bulk of the exploration was happening async. We spent some time ahead of the meeting fleshing out ideas, then we came together to review and calibrate.
After the workshops, designers continued collaborating. It was a tough balancing act because we wanted to get out of the boundaries of the system, but we needed to be aware that this solution must still look and feel like Polaris. With any new element we introduce we have to question its purpose, but also understand if it actually feels like it belongs in the product, and could be reused by other teams.
As we explored different ways to display the organization, we realized the importance of having a strong underlying grid that makes sure there’s a level of consistency across different pages, even if the information is organized differently.
We didn’t just look at the page as a whole, to establish hierarchy we also had to zoom in and find ways to make better use of color, space, and typography. We added visual weight to the most important elements, to make them contrast with the rest, and give the eye elements to gravitate towards. We did this by using color tactically and by exploring larger options from our type scale.
We also reduced the amount of cards in the page, leaning more on space to group and separate information.
As we gained confidence we started pulling product and engineering into the conversation. And we ultimately landed on a solution everyone was excited to build.
With the redesign, we made it easier for merchants to understand a B2B customer with a quick glance.
Instead of simply collecting the information in a page, and hoping merchants do the hard work to decipher it, we now curate the content of the page. We emphasized relevant insights and downplayed information that only needs to be accessed sporadically. Ultimately, making the important things easy, and everything else possible.
Making compromises
It’s not all sunshine and rainbows though. Due to the tight deadline I mentioned in the beginning, we had to break down our solution so we could ship it iteratively.
It’s rare to build anything without having to make some compromises, especially if you’re on a tight deadline. This is just a fact of product development, but that doesn’t mean you should compromise on quality.
However, to be able to do that, you need to understand what are the technical constraints, and why.
That’s exactly what the B2B team did. For instance, getting metrics and insights was hard, but instead of giving up on the idea, they fought to introduce whatever was achievable because they knew this would still be incredibly useful for merchants, and moving forward we can iterate and improve upon it.
Creating solutions that can scale
As this was happening, we had started working on new layout foundations in the Polaris team. Throughout the collaboration, we learnt that our layout components were too restrictive, so we built a grid component that makes it easier to build custom layouts without having to break away from the design system.
The grid component guarantees layout consistency across the admin, without forcing teams to use a template. It does have some constraints, but it enables much more flexibility.
Thanks to this collaboration, the B2B team was the very first team to use this component, which enabled them to ship a new layout without the need of breaking away from Polaris.
Teams want to innovate, but they need constraints, and sometimes also permission.
This collaboration showed me there’s no lack of ambition and skill, what is lacking is knowing how far to go, and when you don’t know the limits, sometimes you just play safe. And playing safe is a dangerous habit to develop.
Having the system team actively exploring and collaborating helped give permission to go a bit further, but this is not scalable, so we need to find ways to incorporate this permission in the system.
The column grid is a good example of design constraints — with permission to innovate. We need more like this.
Technically teams can build anything without Polaris, but that leads to inconsistency, UX drift, and a lot of hardcoded solutions that make the system harder to maintain, update, and scale.
Polaris is a tool. We use it to our advantage, but we can’t forget to maintain and evolve it. If a knife becomes blunt, you don’t need to get a new one, you need to sharpen it.
This collaboration was a lot of fun, but also highly impactful because we made improvements in the product and the system. We didn’t just ship a new layout together, but we also identified ways to improve the system as a whole. It was especially rewarding to see this work being featured in Editions, and I can’t wait to see B2B shipping the full vision, and other teams using our new foundations we built.
It should go without saying, but this would be very hard without the amazing initiative and dedication of our very first Lab partners. So let me take a moment to celebrate all these amazing folks that contributed to this:
Aaron Casanova, Chelsea Leathley, Joe Thomas, Kristina Pyton, Kyle Durand, George Yacoub, Jay Laiche, Nathalie Poirier, Pablo Vallejo, Pamela Hicks, Scott Meadows, and Winter Wei.
A brief chat with Winter and Kristina evolved to a fruitful collaboration, where I have to give a special thanks to Chelsea for being an excellent design partner. 🙏
How to start?
If like the B2B team, you’re looking to push your design system forward, I can recommend one of two ways:
Option A: Partner with the Design System team
Consider reaching out to your Design System team if you’re working on a problem where you’re hoping to push its boundaries, and see high potential for influencing design patterns across the whole product.
A design system team will likely want to avoid unique solutions, but they’re likely very interested in learning how to make the design system more relevant. Especially if there’s a potential benefit for other teams across your organization.
To prove that point, I can tell you that I’m already working with another team, on a different problem, and I only expect collaborations like these to happen more, as their benefits become more visible.
Unfortunately, I know a design team can’t stretch to partner with everyone. But that should never stop you from innovating, there’s another way:
Option B: Mobilize your team
My team’s main job when collaborating with a product team is to inspire and encourage.
That’s also why I’m sharing this case study. To show you what we made, how we made it and why, hoping this inspires you, but also gives some of the instructions to repeat the recipe.
The key thing to keep in mind is that it’s really difficult to innovate on a silo, so look for partners that share your enthusiasm. If you need a jump start, you can even run the workshop I described above using a template I created.
And when you’re done, don’t forget to contribute to your design system.
