A screen shot of Shopify’s Billing experience.

The journey behind creating a local design system for Billing

An interview with the Shopify Billing UX team about their human-centered approach

Hayley Hughes
Published in
7 min readNov 18, 2020

--

The Billing UX team recently added Billing Experiences to our Polaris design system. I spoke with UX manager Jen Bombis and senior product designer Greg Petiquan about why they created this local design system, the different steps in the process they used to build it, and the benefits they’ve noticed of grounding a design system in user journeys.

What is Polaris for Billing?

Jen: It’s a set of experience guidance around the jobs that merchants do in billing (for example, adding a new payment method, or approving a charge). It represents the best thinking of the entire team. But it’s also meant to be revised and evolved over time.

Why did you create it?

Jen: When I joined, there was really only one person on our team who had all of the Billing context, and that context needed to be distributed. Billing is built on a legacy system, with many different components which had been created separately by multiple teams. This caused a lot of inconsistencies, which amounted to frustrated merchants.

As a result, we wanted to provide teams at Shopify a better foundation to drive consistency and build more trust with merchants. Like it is at many large companies, Billing experiences had been built by various teams at various points in time.

Other teams also needed to connect to billing for various reasons. Sometimes teams would come to us to understand some context or for consulting to understand the system if they are creating a new product. We were a sort of a bottleneck, as it takes some expertise to work with the billing system.

Our hypothesis is, if we build trust early on in the merchant journey, we open up the possibilities for more innovative experiences for merchants in the future.

How did you start building a foundation for Billing?

Jen: We created a journey map, which captures merchant experiences across a few different stages of business maturity. By understanding merchants’ context and needs, we identified the opportunities for improvement. A few of those opportunities have since become product ideas.

A 7-step journey map built by the Shopify billing team.
The user journey for Shopify’s Billing experience.

Greg: The map can inspire product features for the team to iterate on or innovations — things we can create on top of the Shopify system that we can patent, and that might be helpful for our merchants. Or it could be an opportunity to actually say, “Hey, this isn’t something within Billing, but maybe we should go and talk to that team and partner with them.”

Jen: It’s been pretty foundational, not only to the design system, but also for our team’s alignment and communication with other teams.

You used a journey as inspiration to start your design system? That’s fascinating! Why did you choose to start with that over, say, patterns or components?

Greg: If we just documented our UI components without the bigger picture as to why the components exist in the first place, it would become really hard to challenge the status quo. We weren’t just looking to build upon what we had already, but really starting to shake things up.

This meant looking at the full merchant experience — not just point A, but point A to point B — by answering merchant questions like, “What am I paying for, and how much am I getting charged?”

With a global vision, now we actually see different opportunities. It makes so much sense in terms of building the system out in this way. You see your blind spots and edges a lot easier looking at it from a higher level, instead of just a single page.

Was the journey map helpful to teammates in disciplines other than design?

Jen: It really provided value for our product managers, helping them to identify where to invest. It provided insights into new product opportunities for our merchants.

Our product managers use the journey to answer questions like:

  • Where does the journey start to overlap?
  • How can we collaborate better with other teams?
  • Within our journey, what do other teams need to monetize?

Greg: Bringing the developers along for the journey as we went through the design process also really helped the whole team ground their work in empathy for the user. They gained deeper context for why we are building for experiences, not just product features.

How did you start to systematize Polaris for Billing?

Jen: We started by interviewing other teams who had recently developed their own design systems. These conversations were really useful, and helped us to define the scope of our project. The team started diving deep into just a few focus areas: viewing past bills, maintaining payments, and approving new charges. These became the targets for a series of design sprints and reviewed our ideas with other teams to make sure the prospective designs met their needs. It was definitely an iterative, non-linear process.

What do you think the impact of Polaris for Billing is today?

Jen: The MVP version of the system has absolutely sped up our development time going forward. What we’ve been able to do is pivot now and use that information to build and execute quickly. It’s really exciting how the project has quickly paved the way for us to redesign Billing.

The many conversations that we’ve had as part of this project helped to build stronger relationships with our partner teams at Shopify. We want them to know that we’re here to support them, whether by consulting or by partnering to develop new features for the billing platform.

“I appreciate you sharing this context … it’s very necessary for us to know the context behind it [the UX decisions]. Thank you so much for asking us to collaborate, it’s amazing.”

— product designer, Start Launch team

Greg: The biggest impact for merchants is that their billing experiences will be much more consistent over time. It solves a lot for merchants because we’ve tied it back to merchant frustrations. And a lot of projects are actually spinning out of Polaris for Billing now.

What surprised you most about working on the system?

Greg: There were many surprises! Early in the process, we found that it really takes time to understand the full Billing journey. We wanted to be able to answer the question “What does the billing team own?” In the end, it took us about four months to truly get a sense for that, and build out an MVP.

Jen: Working on the system actually brought our team much, much closer together. Not that we weren’t close before, but it did it in a way that none of us really expected. We feel tighter as a group because we built this thing as we figured it out together.

What was the hardest part?

Jen: It wasn’t easy, that’s for sure. The ambiguity was very high in the beginning. I think the hardest part was knowing where to go next, but we had a lot of support. We had great support from the Polaris team, other Shopify teams, and our leadership.

Greg: In my opinion, the hardest part was that this was the first time we truly collaborated on a project as a whole team, together. Learning through iterative prototyping was crucial. It really helped us shape all sprints and future projects going forward.

A screenshot of the Billing Overview page of the internal-only version of Polaris.
A page for building context about the Billing experience, on an internal-only version of Polaris.

What can someone learn or do by exploring your system today?

Jen: They can learn how Billing works! The system includes all of the wonderful research that the team has done over the last year. So it lets teams really understand our merchants, as well as highlighting the best practices when it comes to building experiences.

In the past, there was no single source of truth for the Billing experience, and it was a big question for other teams who were building features that integrated with the billing platform. Our principles have been really helpful for third-party developers. One comment we received was, “This is great. I love that the experience section grounds you in the user’s world.”

What’s the most interesting insight you published to your system?

Jen: People don’t want billing surprises, they want transparency. Most people view their bills to see their charges and try to make improvements. We’re actually not trying to do something outside the box in terms of why people go there.

What’s the most important UX decision you’ve made for the billing experience so far?

Greg: It’s about organization. Content and information should be laid out clearly to help merchants make informed decisions about their expenses. When possible, offer them personalized insights that help their business. Ask yourself, “what do merchants expect when they’re looking for information?”

Jen: Make sure that we’re surfacing the right information at the right time, in the right way. This ties back to “no billing surprises.”

What’s the most important piece of advice you would give to teams who want to create experience foundations for their system?

Greg: Really determine what jobs the merchant’s trying to do. In our work, we found that merchants come to Billing to make sure nothing’s going wrong. They only come here if they have a reason to come here. Today the Billing experience is reactive. How do we serve merchants proactively? We’d like to be able to say, “Oh, it looks like you can save some money here.”

Jen: I’d highly recommend starting with user journeys. Honestly, don’t try to build it all in one day. Learn from others, collaborate, and find a targeted path forward centered around your highest pain points.

Document, document, document. Then, socialize with internal teams and gather feedback along the way. Make sure you test and validate your assumptions and recommendations with real projects that have a defined outcome. That way you can balance important foundational work along with shipping value to your clients.

Great advice! Thanks for taking the time to share your journey with us.

Thanks to Rory Tanner and Gene Shannon for their help with this post.

--

--