The impact of design at Shopify

I recently asked Cynthia Savard Saucier, Director of UX at Shopify and author of Tragic Design, to discuss the design process, its impact on Shopify’s business outcomes, and how to improve communication between designers and developers. Cynthia is presenting a keynote on The impact of design: How design influences outcomes at the O’Reilly Velocity Conference, taking place Oct. 1-4 in New York.

1. Describe your design process and an example of the impact it’s had on business outcomes at Shopify.

Describing the design process is quite difficult since every project and team finds their own. Not every designer sketches, or creates clickable prototypes; it wouldn’t be appropriate in all cases! However, there are some commonalities across all teams at Shopify.

First, design doesn’t work in isolation from other disciplines. We have multidisciplinary, product-based teams. This is even visible in the architecture of our offices! The floor plan is pretty much a representation of our roadmap. Also, every project has a multidisciplinary trio of leads (product, engineering, and UX). They make decisions together, and ensure a good team alignment.

Second, we often start the design process with a design sprint, inspired by Google Ventures. During that sprint, we make sure members from a variety of disciplines, expertise, and locations attend and contribute. This diversity of thought, from the beginning, is very valuable. We aren’t following Google Ventures’ proposed methodology religiously, as we found it wasn’t entirely relevant to the way we work. We adapted the activities, keeping what worked best for us, like the use of a war room, the four-step sketching process, and the voting system. We care just as much about how people work as the deliverable itself. A lot of effort goes into tweaking our processes so they work for the project, people, and product.

Third, we believe that research with real users leads to real insights. This seems quite obvious, but I know from experience that surprisingly few UX professionals ever get to meet their users. That being said, we don’t always do user testing or interviews. We are constantly researching what our merchants want and need (two very different concepts). We join unofficial merchant groups, and read what is posted on forums. We also listen to customer support calls, to learn the pain points and major complaints that our users have. Finally, everyone (regardless of their discipline) is encouraged to spend a day with a merchant. Observing their work, helping them with their business, learning how to process orders, deal with inventory, use the POS, helps build empathy and understanding for what our users go through.

For example, a merchant shared their process for dealing with shipping update requests with us. Replying to emails takes time and effort, both things we could lessen by leveraging our confirmation page differently. So we did. By presenting the order status on this page, we benefited both our merchants and their customers. It’s a significant result—they don’t have to answer the same emails over and over again, and can spend that time in a more valuable way.

2. Why is it important for engineers to start thinking about design’s impact?

Let’s start with a simple statement. Developers and designers are doing the same work: solving problems for their users. They simply use complementary tools to get there. To use a biology reference: designers and developers are not in a neutral relationship (where both entities simply live together), but rather a mutualist association (where they benefit from each other). 

To quote Yonatan Zunger:

Engineering is not the art of building devices; it’s the art of fixing problems. Devices are a means, not an end. Fixing problems means first of all understanding them — and since the whole purpose of the things we do is to fix problems in the outside world, problems involving people, that means that understanding people, and the ways in which they will interact with your system, is fundamental to every step of building a system.

Developers have the power to impact the user experience in ways that are not always obvious to the designer (like security, performance, reliability, accessibility, exceptions handling). For example, while designers understand the importance of a good error message, they might not think of all the potential use cases. Chances are that the developers will be making most of the error and exception handling design decisions. We might think that error management is not as important as other pieces of the interface. However, as I explain in my talk, a good error message can make the difference between an unfortunate event and a crisis scenario.

Finally, history has taught us that poorly designed products can anger, sadden, exclude, and even kill people who use them. The existence of a user experience designer on a team doesn’t mean that developers aren’t equally responsible for the user’s well being.

3. How do you measure the effect your design has on business outcomes?

We utilize Shopify-wide metrics that generally reflect our goal of making commerce better for everyone. This, however, can mean a lot of different things. We use a variety of long-term and short-term qualitative and quantitative success metrics depending on what area our project lives in. Our UX researchers will make sure we meet our qualitative metrics, and our data team takes care of the quantitative side of things.

We obviously do A/B testing and experiments to answer some questions. We do some user testing, but also collect feedback from surveys, chats, and customer support phone calls.

4. What can designers and developers do to communicate better with each other?

There is a golden rule to every interaction: always assume good intentions. No one is intentionally trying to make your work harder. That being said, we must bridge the gap between the two disciplines by offering actionable, specific, and direct feedback. On that subject, I recommend the book Radical Candor by Kim Scott.

Another way to improve the communication is by building trust between the two teams. If you’re a designer, invite developers to your design feedback sessions and vice versa. They will learn about the restrictions and complexity of your decisions. They will understand the rationale behind specific interactions and, as a bonus, will learn the language used to describe your work.

Involve each other early in the decision process and be intentional about creating overlaps in knowledge.

We often read or hear that designers should learn to code. I disagree. I mean, it’s great if a designer wants to learn to code, but it is not a requirement. However, designers should learn how developers work. They should seek feedback and be interested in their tools, techniques, and methods. A designer shouldn’t feel intimidated to attend a standup meeting. On the other hand, developers should go the extra mile to explain things in a way that is understandable to designers. Learn about the right level of abstraction required to offer an answer. Learn how to draw diagrams using a visual vocabulary. Read about the right way to give design feedback: it all comes down to focusing on the problem perceived, not the solution. While designers value feedback, understand that technical arguments aren’t always more important than UX considerations. Be flexible and always defer to what’s best for the user.

Finally, don’t use phrases like “my designer.” While this might seem small, it gives the impression that designers are at your service, instead of actual and legitimate team members.

5. What sessions at the O’Reilly Velocity Conference in New York are you looking forward to attending?

To make the most of every conference I attend, I try go to talks in three categories—at least one that is quite removed from my day-to-day or core expertise, one that contributes to my leadership skills, and one that is related to my craft. For Velocity NY, these are:

• Out of my comfort zone: Carin’s Meier’s keynote Unconventional programming paradigms for the future now
• Making me a better manager: Kellan Elliott-McCrea’s talk You are not an architect, this is not a bridge we’re building: Leading technical decision making for high-performing teams
• Advancing my craft: John Le Drew’s talk Pay attention! Why you should care about psychological safety