Shopify’s Amy Thibodeau on the importance of interface content
Getting potential users to try your product is challenging. Guiding them to success once inside is even harder.
So how do you better help new users understand what actions to take with your product? In many ways, interface content – the words that build our product – does the heavy lifting here, and joining me on our podcast to explain why is Amy Thibodeau, Content Strategy Lead at Shopify.
Amy recently helped build Polaris, Shopify’s publicly accessible design system, which focuses heavily on the role content and tone of voice play in creating a great product. Amy’s also working on a book, From Button Copy to Bots, to be published next year by Rosenfeld Media, and going back a bit, was one of the first members of Facebook’s product content strategy team.
Our chat covers the many ways unclear copy can lead users to frustrating, unintended actions, how her team went about building Polaris, the problems personality presents in UI, and much more. If you enjoy the conversation check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of our conversation. Short on time? Here are five quick takeaways:
- Without thoughtful content an interface is essentially just a series of buttons, lines and boxes. It’s the content that helps convey meaning and provide clarity for users.
- Interface content is not just about people consuming information, but also how they find their way through an experience. If you aren’t very careful about word choice dark patterns are bound to unintentionally appear.
- Design systems and how they’re represented in a style guide should be a reflection of how a company works and what it values. This is why Shopify’s Polaris system integrates the disciplines of design, content strategy and front end development.
- Style guides are built to be living documents, and Polaris has a publicly available GitHub repository for the greater community to submit issues and suggestions.
- There is a real desire in companies to sound friendlier and more human, which is positive; however, doing so requires deeply considering the edges of tone scale. How will it be perceived in sensitive use cases?
Elizabeth McGuane: Amy, welcome to the show. Let’s start with your story. Where has your career taken you so far, and how did you become a content strategist?
Amy Thibodeau: My story is common in the sense that people have such circuitous paths to content strategy. I’m originally from Regina, Saskatchewan, basically middle-of-nowhere Canada. I started my career working in communications for museums and art agencies. Then I moved to the UK because I had a couple of grandparents that were from there and that enabled me to move there under an ancestry visa.
I started working at a digital agency as the Head of Communications. This is really when I changed my career and started working on interface content. The main product of the digital agency was a content management system, and while I was working there the team was redoing that content management system. Because I was the end user of that system I ended up giving a lot of feedback about the experience, working really closely with the product designer to say, “As somebody who would use this product, this doesn’t make sense or you might want to change this language.”
That’s really how I started working in product content strategy. I left that agency and decided to travel for a year and do some consultancy. About a month before I left I read a post by Rachel Lovinger from Razorfish all about content strategy. At the time it was a fairly new term, and it was just all of the things that I enjoyed about my job and none of the stuff that I didn’t enjoy.
I officially decided to call myself a content strategist and that year while I was traveling I was picking up little projects here and there and writing about them on a blog I kept, Contentini. The blog was me thinking out loud and trying to sort through all the questions I had about the work that I was doing. At that time there really weren’t many people writing about interface content and that’s how Facebook found me. I was there for four years, then took a year and a half off to freelance, and now I’m at Shopify as a content strategy lead.
What’s under the interface content umbrella?
Elizabeth: You focus primarily on interface content. What do you mean by that phrase, interface content. What does it cover?
Amy: It’s the content that people encounter within an interface or within a product that they’re trying to use. It includes things like the content that is on buttons, things like settings and the content that people experience when they’re onboarding in a new product. An example I can use from Facebook is the first time that you sign up for Facebook you will see certain content in the interface that helps you to understand what Facebook is, how to use it and some of the basic things that you’re supposed to do to get started. It’s all of those things. It also includes some hairy bits like privacy settings. How we communicate privacy in an interface is really important and that’s a big part of interface content.
Elizabeth: Things like button copy can be perceived to be relatively low value. Do you think that’s changed recently and if so, why?
Amy: It’s changed in the last few years. I see this real growth in the community of content strategists who are focusing on interfaces. When I first started at Facebook we were trying to grow our team and it was really, really hard to find anybody who had interface content experience. Now I feel like there’s a thriving community around this practice.
The reason for that is companies are realizing that without thoughtful content an interface is essentially just a series of buttons, lines and boxes, and it’s really the content in that experience that helps people to understand what they’re supposed to do, how they’re supposed to think about it and what their next steps are.
Without thoughtful content an interface is just a series of buttons, lines and boxes.
For example a button can teach somebody what’s going to happen next. It helps to give them the power to make the decision of whether they want to click or not. A button that is unclear results in an unclear experience for users. They see this button, and they’re not sure what’s going to happen if they click. In some darker pattern experiences it can result in people taking actions they didn’t intend to take. It can cause them to reveal things they didn’t want to reveal, so the way that we think about and label interface elements is really, really important. It’s not just about people consuming information, but it’s about the way that they find their way through an experience. I we believe that these digital experiences we’re building matter to people, and I think that they do matter to people, I think it’s really incumbent on us to clarify those experiences. The best way to do that is through language.
When language leads to dark patterns
Elizabeth: It really sounds like you’re describing the building blocks of the user experience and connecting people from one part of the experience to another. You mentioned dark patterns which is a pretty weighty concept. Is there potentially a danger for people to have accidental dark patterns if they don’t pay attention to content or to language at this level? And if so, how do they mitigate it other than the obvious thing, which is to hire a writer?
Amy: The whole purpose of the book that I’m writing is really to help well-meaning people who were not necessarily trained to write to think about how language works in an interface, because I do think that the vast majority of people who are working on these experiences have good intentions. They just often don’t know where to start.
Here’s a really simple example that I don’t think anybody means any harm by but happens all the time: You’ll often see links in an interface that just say, “Click here”. The problem with that kind of a link is it’s unclear what’s going to happen when you click on it. Anything could happen if you click on something that says, “Click here.”
It’s also a problem from an accessibility perspective. Somebody who’s using a screen reader doesn’t have any context about what’s going to happen if they click. People often end up taking actions that they didn’t intend to take or find themselves lost in a different part of the interface because of a badly labeled link. It’s just an example of somebody writing interface content who doesn’t know how to think about it. They’re not necessarily intending to fool the user into doing the wrong thing, but they just don’t know any better. All of the writing and talking and thinking about interface content is as much for writers as it is for those people who just find themselves at a startup or building their own product and they just don’t know how language works.
They’re not necessarily intending to fool the user into doing the wrong thing.
Another example is an error message. We see a lot of really bad error messages in software. It’s more important for somebody who’s writing an error message to understand what an error message is supposed to do than necessarily how to write perfect prose in an error message. As long as somebody understands that an error message should communicate what happened and how to fix the problem to the user, the specific language that they use is less important as long as they know how to communicate those two concepts. You see a lot of error messages online that just say, “There was a problem,” or “Error 40456”. That’s an example of people writing content who just don’t know how to think about it.
Elizabeth: You also see, “Oops, something went wrong,” which is an attempt to make something that was unclear a little friendlier, but it’s still super unclear as to what’s actually happened.
Amy: Definitely. Another example is 404 pages. 404 pages are a breeding ground for quirky content, and I think that’s really interesting. Essentially what has happened is an error. Somebody is trying to use your software or website to do something or to find something. They’ve hit a wall, and instead of helping them find their way, many companies use that as a moment to joke, which is a really strange thing. Again, it all comes back to well-meaning people who just don’t really know the purpose of the content they’re writing and aren’t thinking about what the user needs. They’re thinking more about what they want to do.
The role of content in a design system
Elizabeth: At Shopify you’ve been part of the team that developed Polaris. Is “design system” the correct term for that project?
Amy: Absolutely. I’m a Content Strategy Lead on what we call the Patterns Team. It’s sort of the Design Systems Team at Shopify, and I led the Polaris Style Guide Project. The style guide is the current manifestation of our design system. If you think about a design system as a bunch of building blocks, the style guide is the piece that explains how to put those building blocks together into an interface.
Elizabeth: What kind of things does the style guide cover in the Polaris System? Is it language and interface? Does it extend to code?
Amy: The Polaris Style Guide is a representation of Shopify’s principles. It includes a section on how to write for interface content. It includes a section on visuals, which is really about the visual look and feel of our interfaces. All of these different disciplines come together at the component level, and we’ve also published a component library, which is a range of building block components for Shopify. For every single component we’ve written UX guidelines. We’ve written content guidelines for any component that has a content element, and we’ve also included each component’s purpose. What is the purpose of a button in Shopify for merchants? What are we trying to enable by using buttons over links? Why would we use a checkbox over a set of radial buttons? By including information about the merchant needs and UX guidelines we wanted to not just show people the code behind our components, but also show them how we think about them and how they should think about them if they’re building experiences for Shopify.
One of our guiding principles in putting the style guide together was to really think about how could we help people build better quality experiences in Shopify and how could we also help them work more quickly. Those were the two things we were thinking about when we put the style guide together and when we decided what we would launch in our first version, which came out at the end of April.
Elizabeth: It’s really impressive piece of work. One of the things I love about it is how front and center language is. It has pride of place on the homepage and it seems very clearly defined. Was that something that came organically from the content strategy team? How mature were those ideas when you set about trying to pull it all together?
Amy: I started at Shopify in January and there was already a solid base of internal standards. There were already some voice and tone guidelines. We already had an internal library of components, for example, but what we didn’t have was this system that brought all of these things together.
Shopify is genuinely the most integrated UX team I’ve ever worked on. Design systems and how they’re represented in a style guide really should be a reflection of how a company works and what they value. Shopify is a very, very integrated UX team. It includes design, content strategy, research, front end development and some other disciplines like illustrators and icon designers.
The way we tackle projects is very much from an integrated, multidisciplinary model. We even have a role at Shopify called a UX Lead. That person is essentially responsible for the entire experience in a product, which means they have to be accountable for the content quality, the design quality, elements of front end development, etc. They have to integrate all of those disciplines in a really smart way to result in a better experience. So because that’s the way that we work, we really wanted that to be reflected in how we put together the Shopify Style Guide.
Elizabeth: That sounds like a beautiful Utopia. What was the trickiest design decision you had to make with the team?
Amy: The hardest decision was deciding what was inside of scope and what was outside of scope for our April deadline. We actually only had 10 weeks to pull this all together.
Back in February we had a design sprint where we talked about how we would turn all of this raw material and way of working into a style guide that we would share publicly. At the end of that design sprint we had this slide that said something like, “Build a good component library and also include some guidelines about how to use the components.” Yeah, easy. No problem.
We were working under some heavy constraints and those constraints were driven by the fact that at the end of April we held Unite, which is our annual developer conference. We wanted to make our style guide available at Unite, which meant that we had a very hard deadline to work towards.
The reason that we wanted to make it available at Unite is because Shopify has this whole community of partners and these are people who develop apps and themes and different experiences that plug into Shopify. We wanted to make this available to them, because we wanted to enable them to also build the way we build so that when merchants are using Shopify, they don’t have this sense that they’re moving between different experiences that are built by different people. That we’re using the same design system, that we’re using the same design language. That we’re thinking about content in a consistent way, and that we’re all working towards the same design principles and goals. That’s why we had that hard deadline.
One of the trickiest things about this project was pulling all of that together with a multidisciplinary team in 10 weeks. We definitely had conversations along the way about taking certain things out, but the team was really committed to representing that multidisciplinary practice that we have at Shopify in the end product. It wouldn’t have felt right to have shipped a component library without those UX guidelines and without those content guidelines included.
Elizabeth: I imagine that’s something that Shopify had dreamed about doing for a while. How many resources were devoted to it, and then how did it feel for the team to finally ship it?
Amy: It was a team of 22 people who were working on this full-time in those 10 weeks. We had representation from front end development, design and content strategy. The content strategy team at Shopify has done a really good job of documenting and advocating for content standards for quite a long time. We definitely weren’t starting from scratch.
Even as we were revising and, for example, were looking at content guidelines at the component level, I had the support of the entire content strategy team so I was able to get them together for a two-day sprint to work with me on fleshing out and developing some of those UX and content guidelines for components. We had the full support of the entire UX organization at Shopify, and they continue to be really enthusiastic supporters of not just this product, but also this multidisciplinary way of working.
It sure felt good to launch. The week leading up to Unite we were very, very busy. We were putting in some very long hours and definitely had a few moments where we were looking at each other thinking, “Are we going to be able to get this done in time?” The content alone, without any of the visuals, was 180 pages in a Google Document. That’s where we developed it and worked on it and edited it. You can just imagine, even from a purely tactical perspective, the volume of that work was pretty intense.
Taking the design system public
Elizabeth: What kind of feedback did you get? It sounds like you had a really clear sense of who your audience was and the objectives that you had in delivering this to them so that they could get a coherent sense of the whole system, but has that really resonated? Have people been using it in the way that you imagined they would?
Amy: We’ve had some really great feedback. Our partners are excited that we’re making this kind of a resource available for them. One of the goals, as I mentioned earlier, is to help people to build better experiences more quickly. In the case of partners, they can only do that if we give them the tools.
A lot of our partners are just one person who is building apps for Shopify, or they may be larger agencies of 150 people who are building for Shopify. Providing them with not only this insight into how we work, but also this very specific information and code base to be able to build Shopify experiences more quickly has been really exciting for them.
We also have a publicly available GitHub repository for Polaris so we can allow our partners, or anybody in the community, to submit issues to us. If they notice that something is missing or isn’t working properly, they can submit an issue into GitHub and we can look at it and decide how to proceed. That’s really important because this design system and the style guide is not complete. It’s a work in progress. From our perspective it’s the first version of it. It’s really important for us to get that community to put in feedback so we can really understand how to evolve it.
Elizabeth: A lot of our listeners are early-stage startups who don’t have the scale or size of Shopify. Many of them don’t have content strategists or writers. Do you think developing a design system is something they should think about approaching, or is it something they should wait to do?
Amy: It always helps to document standards, best practices and importantly, principles. What are the things that you care about as a company when you’re developing experiences for humans to use? Having those conversations and documenting them does actually help you to work more quickly.
I don’t think that people necessarily need to develop fully fledged style guides. I’ve worked with startups in the past who create them as they have the conversations, but it’s nice to have a central place where those decisions, conversation results live and standards live because it helps speed up your work. Even things like, how do you capitalize headings? People will debate that, and if they don’t have a place to record their decision they just keep having the same debate over and over and over again. Even if it’s keeping a Google Document where you’re recording these types of decisions and conversations, it’s really useful.
Toward building better bots
Elizabeth: You’ve written some great posts about bots and personality that resonated with us here at Intercom. In particular you talked about avoiding personality for its own sake and focusing on user needs over any kind of overt personality. Is that a fair summary of your point of view?
Amy: Absolutely. I started to write about bots because when I left Facebook and did some freelancing for about a year and a half, I just saw this huge increase in requests from companies and people who wanted me to work on bot content. The first question I always asked them was, “Why are you building this experience? Why do you think this is the right kind of interface for your customers?”
It was really interesting how often they didn’t have an answer to that question. They hadn’t really thought about it. It was just that bots were this new thing, lots of people were talking about them, and so they wanted to build one. This is actually connected to the desire a lot of companies have to sprinkle their interface with whimsy or quirk.
I blame MailChimp and Slack for this because they do it so well. They have found a way of integrating this prominent, present brand voice into their interfaces, but what companies don’t realize when they look at companies like Slack and MailChimp is that their practice for doing that is actually very thoughtful. They’re not just sprinkling content in their interface. They have a whole practice around developing their voice and thinking about the edges of their tone scale.
The chatbot phenomenon is an extension of a company’s desire to have this big personality and to engage with their users in this way that feels really human and meaningful. Just like the personality in interfaces, if it’s not really well considered and if you’re not prepared to invest in thinking about the experience it doesn’t work very well.
Most people aren’t going to a piece of software to get their social, friendly interaction.
The other interesting thing about chatbots is we like to think of them as being a unique experience, but in most cases they’re not actually intelligent experiences. They are just phone trees. If you’ve used many bots in Messenger you’ll probably notice that they don’t actually let you respond using natural language. They present you with a range of menu options and then they ask you to pick one. This isn’t actually that conversational. It’s not that different from an experience where you might interact with a modal on a website and have to pick one of the options.
There is this real desire with companies to be friendlier and be human. It’s good to harness that instinct and I think that’s a good instinct, but the way we do it is important. I don’t think bots are always the right answer.
Elizabeth: It seems to me that instinct really doesn’t have that much to do with bots. It has to do with this desire to, as you say, sprinkle personality in. That probably predates bots, predates interfaces, and maybe comes from the idea that older companies had to outsource creativity to advertising agencies as opposed to integrating a creative or thoughtful approach to tone of voice into the rest of the organization.
Amy: That’s absolutely true. What we’ve seen with interfaces, with a little bit of the research that has been done, is that customers don’t always want big personality to get in between them and their experience. They just want to get a task done. Most people aren’t going to a piece of software in order to get their social, friendly interaction. They’re going there to actually do something that matters to them.
Whether that is checking in for a flight or trying to transfer money between their different bank accounts, sometimes the big personality can actually get in the way, be distracting and not allow the person to accomplish the task they’re trying to do as quickly as they would like. It’s just another example of companies thinking about what they want and what might be nice for them and their brand. Also as designers it feels really nice to have a quirky, fun personality in our interfaces. But if we really step back and think about what our customers need, most of the time in an interface our customers just need us to get out of the way and help them to do the task that they want to do.
Writing the book on interface content
Elizabeth: What’s next for you at Shopify?
Amy: I’m really excited to continue to work on Polaris. We’ve got big plans for our design system and for how we evolve our style guide. Because we developed it so quickly we don’t have a great governance model in place for how we can communicate new releases or how we ship new components both internally or externally.
Governance is actually a really big piece of this and anybody who has managed a big project like this, with a lot of moving pieces, knows that generally you shouldn’t be thinking about governance after you ship the thing. You should be thinking about it before, but we are very much in the process of developing that now.
One of the benefits of waiting until now to really think through and develop that is we do have the benefit now of a lot of feedback from internal stakeholders and from our partners. That will allow us to develop t an MVP of governance that allows us to move quickly, but also allows us to really respond to the communication needs of the different people who are using Polaris so that we’re always focused on that piece about helping people to build better experiences and helping them to build faster. That’s the next step for me on this project.
Personally I’m working on a book for Rosenfeld Media, From Button Copy To Bots: Writing For User Interfaces. I need to get down to continuing to write and doing the research that I need to do. This book is not a book about me, it’s not a book about my specific experience at Shopify or Facebook, but it’s a book generally about interface content, why it matters and helping people who are not necessarily writers to learn how to think about interface content to make their experiences better.
I’m talking to a lot of different people, I’m gathering a lot of different stories and I’m particularly interested in the piece where interface content has made a significant impact either positive or negative in somebody’s real life. It’s really easy to trivialize some of these experiences or to think that they don’t matter that much, but they actually do matter a lot to the people who are using them.
Take something as simple as checking into a flight. If you are in a stressful situation – maybe you’re trying to visit somebody who is ill – there are a range of scenarios that happen in life that make these experiences feel really significant when you’re trying to do them, especially when they don’t work properly or when they’re not clear.
By collecting some of these stories, my hope is that it will help people who are building these experiences to think about them as important to people, because I think they are.
Elizabeth: Amy, thanks so much for joining us. This was a fascinating discussion, and I can’t wait to read the book. When can people expect to see it?
Amy: We’re aiming for early 2018, so hopefully by January. If I’m really, really good, maybe the end of 2017, but I don’t think that will happen.
