Scenario-Driven Design Systems

December 11, 2018 11:30 AM

SVA Theatre

Unified design systems are essential to building, maintaining, and evolving our sites and products. By empowering disparate teams via a common visual and UX language, they help us create cohesive user experiences. But creating a unified system that scales to serve a variety of content and use cases can be challenging. Sharing insights from her experience creating a unified design system for eight media brands with eight distinct editorial strategies, Yesenia will show how to approach a design system via a user-centered lens. Learn how being scenario-driven helps you design a scalable system that responds flexibly to specific contexts.

Sketch Notes by

Unedited Live Transcript

Nathan Curtis:

So it’s my pleasure to introduce Yesenia Perez-Cruz. She is a senior director. She works on what is called the chorus, publishing platforms for Vox media and also is attached to the design system that covers many of their different properties, the verge, Vox, re-code and I really like that she is a speaking that’s going to help us think about the intersection of design and technology. Please help me welcome Yesnia Perez-Cruz.

applause

Yesenia Perez-Cruz:

How is everyone doing? Why do I talk about scenarios when I talk about design systems? It’s because at their core, systems are intentional. A design system is inherently about being intentional, about the way that you approach creating, building and maintaining the user experience of your product. They provide this foundation that everyone that’s creating products and experiences for end users can kind of build on top of. And it’s the shared language. I want to take a step back and talk about systems a little bit more broadly. So Donella Meadows was an environmental scientist who published this book called Thinking in Systems and I appreciate her definition of a system, because I feel like it captures something that a lot of our definitions of design systems miss. She says that a system is an interconnected set of elements coherently organized in a way that achieves something. So to sum it up, a system has parts, those parts are connected and through that connection, they serve an overall purpose. Her definition of a system consisted of these three parts. The elements, the interconnections an the purpose. She points out that all of these are important and all of these are interconnected when it comes to creating a system. But the elements are the most tangible thing. So they tend to get the bulk of our attention. And then the hardest part to visualize, the purpose, is actually the most critical. And she warned that if you get so caught up in defining all of the different parts and bits and pieces of a system that you risk losing the overall picture.

So when all of those parts of a system exist in harmony, a good design system feels cohesive, unified and connected. Different teams know how to use them to create experiences, they inspire teams to use them and contribute to them and they grow bigger and stronger over time. But a bad design system feels disjointed, confusing, teams don’t know how to use them and they might grow bloated or discarded overtime. In my experience building and watching others build design systems, I’ve seen them fail when there’s too much focus on the elements or patterns and not enough focus on the way that these elements come together to solve a problem. So this might lead to a design system that might feel very flexible but is actually difficult to use because there’s not a clear sense of how to use these patterns together to create experiences. So what I’ve learned in my time creating design systems for my own teams and for clients is to start them not with components or Legos, but with user scenarios. But this wasn’t always so obvious to me. I’m at Vox media which is a company that strives to build journalism and entertainment. We have various editorial networks that explore topics that people carry about. And three years ago the Vox product team started a project to migrate all of our brand’s to one code base which meant we also needed to create one flexible design system in order to support our brands. This meant that we had our eight distinct brands with over 350 websites and they all needed to be powered by the same design system.

So why were we doing this? We did this because we were maintaining and iterating separate code bases which is really cumbersome and launching a new site would take months, it was time consuming and we wanted to take the creative focus of our teams away from shipping multiple code bases and towards developing products more quickly. But we also wanted to help our editorial teams tell better stories faster and that was a defining principle of this design system. But this was a really hard problem to solve. Because each of our brand’s websites was incredibly distinct and tailored to the individual brand need. They were full of custom components that ranged dramatically from brand to brand, the visual design system was also incredibly custom so each brand had its own typefaces and colors and brand elements. Even more than that we needed to create a system in a way that it would support different editorial missions, content types, audience needs as well as the typography and the branding. So we had to unify these eight brand sites into the one designing code system, but we also needed to provide enough flexibility to allow our brands to still feel distinct. And so in creating this design system, we asked ourselves what components do we need to build, how can these components be combined in order to create distinct experiences, how are we going to create unique, look and feel for over 300 websites by using one visual design system. And so of course with any big project, I find that there’s always going to be some early assumptions that don’t work. So in our case, we had this idea that we could take the smaller, modular components and combine them together to define pages instead of designing individual pages. And we also knew that we needed to address inconsistencies with things like typography and color and treatments of information. So we started with this hypothesis that a set of flexible brand agnostic modules combined with a theming system would give us the most range. That whole idea of working with Legos to create these modular pages.

So we started with the modular components. For instance, there’s three different home page hero components that we designed. They were pretty general because we thought that keeping them general was going to be the most flexible. Here’s some story cards and you can see the variation there is primarily presentational. So an image might be larger if the story is featured, it might have a map icon if it’s a piece of map content. So we thought that we could create these really flexible modules and layer color and typography over them with our theming system and that would be enough to make our brands feel unified yet distinct. But we quickly learned that the solution wasn’t going to work. For one, our sites felt too similar and they were losing some personality. But more importantly, they weren’t accurately reflecting critical differences in content, tone and audience. So if I take, for example, curbed and re-code, they cover different topic areas. Curbed covers home and neighborhoods while recode covers tech and business. Curbed has maps and guides while recode has news, podcasts and events. But with our initial design system none of these critical differences were reflected. And that was because these modules didn’t have a clear purpose. The variation that existed within them was primarily visual or presentational. So that gets me back to the quote in the beginning where Meadows defined a system as an interconnected set of elements coherently organized in a way that achieves something. In a way that achieves something. So while we were so focused on the modularity of the system, we weren’t thinking about what our audience needed to accomplish when they came to our sites. So define the elements but not their purpose, their interconnections and the ways that they solve user problems. So we actually found that in order to create a more flexible system, we needed to start by being more specific. So here’s what we learned after that initial round. For us we found that you can’t start just with the individual components. And that’s because successful design patterns don’t exist in a vacuum. They don’t ignore the context that they’re in, the people that are using them, the content that they need to display, and how they need to work with each other. In her article, the Language of Modular design, Alla Kholamatova says we should start with language. So for us we found that creating a successful design system meant we had to start with content and with people. And that meant considering our audience, our editorial teams, the content that they’re producing and consuming, and our revenue goals.

So we really had to ask more questions to better understand the needs of this design system. Instead of just asking what components do we need to build, we had to take a step back and ask for this feature, what is the audience goal? Is there a shared audience goal across all of our brands, or are there differences? What’s the editorial workflow to produce this piece of content? What range of content should this support? And so this led us to a much better process for creating our design system and the key steps that we uncovered were start with a fast, unified platform, be scenario driven when creating variation; and find key moments for visual brand expression that serve your audience.

So the first step is really creating that unified baseline experience. So first and foremost, our platform should load quickly, be accessible and work well across devices. We should have a unified core user experience. They knew how to log in in a consistent place, they knew how to find related articles once they’re done reading. However we shouldn’t be created one size fits all solutions. We can have variations with components and layouts and we can have a lot of range within a system. If those patterns are solving specific problems. So scenarios, instead of layout, should be driving those variations. And this means that we can’t have hypothetical situations. What I mean by this is, we can’t anticipate needs for our design system that don’t exist. Because our audience, the end users that end up using these products, they aren’t hypothetical people. They’re coming to use our products to do specific things. So if we only focus on our patterns in the abstract, if we only reference other design systems while we’re designing our own, then we risk having that really unified, cohesive system that maps back to our brand purpose.

So I said a few times that scenarios have helped my team achieve more purposeful design systems, but how do you start identifying scenarios? Really, the work to identify scenarios is all about understanding the broader context of your system before identifying individual parts. So Brad Frost popularized this idea of a UI inventory as a way to kick off a design system project. Essentially you do an audit of the UI elements across your site and you group them into categories like navigation, forums, tabs and buttons and this allows you to see duplicative patterns and identify where you need to spend the bulk of your attention with your design system. In her back on design systems, Alla introduced the purpose directed inventory. This inventory groups items by purpose. The exercise helped her team think about families of patterns joined by a shared purpose rather than individual pages or components. You know, and if you’re getting started with creating a design system for your team or if you’re in the process of kicking off any phase, I think it’s valuable to run through the UI inventory exercise and kind of see how people group things and then have them run through the purpose-directed inventory. Because it starts to kind of uncover questions about wait, why are these two things different. The work should really help us identify the core work flows that we have, and the patterns that need to support these work flows. Understand the role that each pattern plays in a user’s journey and define how those patterns work together to create cohesive experiences.

And what you start to notice is the difference between a presentational difference and a semantic difference. In other words, there might be two patterns that look different that are actually solving very similar problems. Or pardons that look similar that are solving different problems. It kind of helps you get to the bottom of that. And I think what’s great about scenarios is they can help add focus to the layout level, the component level and even the visual design level of our design system. I love seeing this layout page in sales force’s lightning design system where they say know your use case. Understand how the information on the page will be used. So they have examples of different templates and when to use them. Like work space, which facilitates user collaboration on records. Shopify Polaris design systems is a great example of a system that puts users at the forefront and they use scenarios to define their patterns in the documentation. It really makes sense because one of their values is to put merchants first. Each explains a problem that it’s solving for a merchant. For instance, callout cards are used to encourage merchants to take an action related to a new feature or opportunity. I think what’s useful about defining our patterns in this way is it helps the users of the system, the designers and engineers that are using the system to build products, think about how to use these components more thoughtfully. So they understand the logic behind all of the design decisions and they can kind of figure out how to put a flow together using these patterns.

This is a great example from the U.S. web design standards. They actually have scenarios for their type system. So they have different type systems and recommendations based on what you’re going to be building. So this one is called default or lite which they recommend for digital services that feature forms but also basic or text-heavy sites and they have another one which they call robust which has an additional font and is recommended for more promotional sites.

So here’s some examples of how this scenario-driven design practice played out for us at Vox. With features, reviews and home pages. Features are pieces of long-form content that typically cover a topic with great depth they contain beautiful illustrations, engaging interactives and before we created a unified system, our features were all custom built and they were really challenging for our editorial teams to update. So we had to turn 18 distinct feature templates with 81 code snippets and turn that into one flexible, easy to use design system. So we started off by identifying the core work flows and understanding the content that goes into those features. What we found was that the core work flow is pretty straightforward. A user is typically entering the page through search or social media. We want to catch their attention, guide them towards related content. So the basic components for the features were a lede image, a text box and a recirculation module. When it came to thinking about the variations that we needed to support, it was really all about supporting all of the different types of content that can go into a feature. These need to be flexible enough to vary in tone. There was also a lot of variation with things like images. So image quality and aspect ratios. So we really focused a lot of our attention on variations on the lede image component. So we created Hed below which highlights photography. If you really want to have an impact right at the top. Hed above which prioritizes photography but still has displayed above. Hed overlay which uses the photo as a background image and is good for lower quality images or more textural images. Hed below short image which is valuable for wide illustrations or widescreen images and side by side, which is tailored for vertical images. The key here was that we only added a layout if there’s a content need. We didn’t create these variations off the bat for the sake of it. In fact the side-by-side variation was added later because we got requests to be able to support vertical images better in our features. When it came to unifying the snippets, these are components that editors can drop into their stories to make them more robust. And we had 81 — 81 code snippets. So our team conducted a content audit to understand which of these needed to be pulled in to the new system. The questions we had to ask ourselves was does it add value? Is it currently available to more than three of our brands and are they using it? Or is it a must-have for one brand. Is it so critical to their mission that they will fail if they don’t have this component. So this helped us determine which snippets would be included in the new system and we kind of cut that number down in half before pulling them over. We had to make sure brands could express themselves and feel different with things like the theming system and drop caps and the lede image variations. We started with these 18 different templates and we ended with one robust system that could support various content scenarios across devices that still felt distinct to our individual brands.

The process for creating the kind of review components went a little bit differently. So a review is a variation of our features, but it has two additional score card components. One at the top that summarizes the key metadata and one that can be inserted anywhere in the body of the future. And so the one distinct component for reviews was the scorecard. Three of our brands have a reviews program. Either, the Verge and Polygon. And they each use to have different looking scorecards. Our initial design, we created one neutral flexible component that had three primary section. A section for meta info, an open text field and an area for calls to action. The problem was that all of these score cards were for different things. Food and restaurants, games and products or gadgets. And the people that were looking at these reviews had different goals. You wanted to know where to eat and what to order, what game to buy, what tech gadget to buy. So we’ve got three different scenarios here. And so then it also meant that the content was different. If you wanted to find a place to eat you wanted the address, the cost, how to book a table, but if you’re looking at a game, you want to know what platform it’s on, what is the score, what’s the release date. So instead of creating just that one scorecard component, he we created three different variants for the scorecard. A venue card, a game card and a product card. So the venue card highlights the content that helps you find a place to eat, like the price, the address, the phone number. The game card highlights content specific to games like the publisher, developer and scores across gaming platforms and the product card gives you pros and cons and some buy-now buttons. So we started with differently score cord modules for the first unified version. Where it had the same hierarchy across the board and it wasn’t specific enough to the three separate variants because each one needed to be tailored to showcase the most valuable content for that subject matter. But these are all still flexible components that our brands can use. So if they want to start reviewing games, they just need to enable that scorecard component for them. And because of the theming system, if Curb wants to start reviewing venues, it’s already built out what they’re branding. The home pages were the most challenges of all to unify. This is because our previous home pages were incredibly robust and distinct for each brand. So in order to discover the patterns that we needed on our home pages, we had to start by this research phase where we asked ourselves what’s the value of a home page today to our audience? Who is the audience? What are they looking for? How are home pages currently performing? And so we sought out those answers by talking to our audience. And we quickly learned that the home page audience was primarily composed of a loyal audience that returns often, so their primary goal is to find new content since their last visit and they care a lot about performance and things loading quickly. So based on that research, we kind of determined that the home page should clearly answer these three questions. What’s new, what’s important, and what’s helpful. And we broke that down into these three main areas of purpose. And so that meant that we could hone in on which components do we need to create to support those goals with the story feed, covers and promotional or service modules. So the story feed is a reverse list and its primary purpose is to allow the audience find the latest content and it’s made up of a bunch of entry boxes that offer a quick preview of our stories and within those there’s some variants on if it’s a review or a group or a map. And that then gets us to the variations for the home page. So back in the beginning of the talk, I mentioned how we initially started out creating these generic home page heros because we thought they would be the most flexible, but that didn’t allow us to have enough range or communicate differences in content. So our revised home page heros all serve specific content-driven goals and have more specific needs. Newspaper for a text-heavy layout for a busy news reporting, evergreen which highlights service content, morning recap, which is a hero for the morning after a busy night of sporting events where users can catch up on all that they missed. And you’ll see that all of these heros also have specific names. We found that getting more specific with the names of these heros helped us make them more successful. And that gets me to this point that it’s really important to name components collaboratively as a team. And not just have designers or engineers do all of the naming on their own. Because establish that clear shared language is going to help us make better decisions about the purpose of each of our components and how they should be used. And it’s also going to help collaboration go more smoothly and make the design and development process faster. Now, something that we struggled with was, what is good variation and what is bad variation. From my perspective, variation is good if there’s a specific problem that we need a new pattern to solve. If it’s determined by user scenarios and content needs; and if it strengthens brand voice in a way that serves our audience. While bad variation is visual variation on components that serve the same function across the board, they also don’t do much to strengthen brand voice. So an example of that is we used to have these newsletter modules that looked very different. We were using a lot of code overrides to get them to look different. But these are really consistent in functionality and layout. So we actually ended up, because these were so consistent in terms of user goals, unifying them and kind of really dramatically simplifying the design of them. But because this is kind of like a low impact when it comes to a brand perspective. On the other hand, in some cases we added components to the design system to support more impactful brand expression. So this is a masthead component that was created for the Verge and the most exciting thing about this Masthead component is they can use the masthead and the one-up hero and art direct the entire home page. I think it’s amazing how these two components because they’re uploading original art can really dramatically change the tone of the page without their team needing any engineering support to be able to do this. And so you can see here with a couple of variations, the Vox and the Verge feel very different. Vox has the standard navigation. And with the theming system, color and type options, it provides a lot of range and you immediately get the sense that the content is different. But most importantly, the brand ethos of Vox and the Verge are reflected here. So Vox is all about doing the work, being explanatory, smart, being generous, while the verge is all about being illuminating, beautiful and rebellious. So we really want to communicate that range even though we’re working within a system.

So this combination of the scenario-driven variations with our theming system allowed us to create brands that felt distinct but still unified. So just to wrap up and recap. Remember that successful design patterns don’t exist in a vacuum. They don’t ignore the people that are using them, the content they need to display and how they need to work with each other. Successful design systems are solving specific problems for our end users that are coming here to use our products. And successful design systems start with content and with people. Thank you.

applause

Nathan:

A wonderful talk. You opened my mind to think different about a variety of things. So thank you for that. I’m curious to start — I’m really curious about your community of designers and the range of brands that you publish on your platform. Can you talk about the interconnections that they have and how involved they were in expressing these components across the different products?

Yesenia:

Yeah. So we have a product design team. So those are a subset of those designers are working on a design system and the design of our websites then we have a brand design team. So they are working on the overall style guides for each of our brands. And then in some cases individual teams. So with a lot of this work we had to partner closely with the brand designers and also the editors in chief and the embedded designers to make sure that one, we really needed to understand like what is all of the range that we need to cover here, what are the variations and tones and brand missions that we need to communicate. So that we could like our baseline settings could cover that range. And then we work on a more individual basis with the different brands to see like okay, here’s all of your baseline settings set up with our theming system. What is missing. So that’s how we start to identify how we might need to grow things. Or in some cases, like the side by side like layout module, the feature layout, we sometimes get so many editorial requests for being able to display a piece of content in a specific way, and that will lead to creating a new variation or component.

Nathan:

So I love that you brought in the system thinking aspect into this. And you talked about elements and connections and purpose. Do you ever think to apply those to not just the system of parts you’re making, but also the people and how do you think about in particular interconnections and purpose of this.

Yesenia:

Yeah, absolutely. Because I think about — so that whole like systems thinking, you have the flow of information in and the flow of information out, the interconnections is all about that flow of information. And so when I think about a design system, there’s information that needs to be communicated to the end users that are using the product, but also the people that are using your design system need to — there’s that interconnection too. So you know the way that I think about it is being able to provide a scaffolding for problem-solving so that the people that are using the system know how to apply that to the problems that they’re solving.

Nathan:

And so one of the connections you focus in on as a part of your purpose, but I haven’t heard a lot about the relationships, is content and design. A lot of the language I’ve used is design and engineering and the pairing of those two things how did you weave in the editorial, the voice and tone and their mission in conveying their message to infuse that into the design you’ve created?

Yesenia:

Yeah. I think — in some cases we had to make sure that we gave the editorial teams the opportunity to, by uploading their content, they could express what they needed to. We needed to be able to support a ton of different types of storytelling. And so understanding what that range is, and there’s also like the editorial teams were resistant to move to a design system. So we had to kind of sell that opportunity that you don’t need someone to be an engineer to build this custom feature out for you. You can focus on what you do best, which is producing your content. Now you can work with designers and engineers to create beautiful art for the futures and that’s — features and that’s the way to use the system. There was also some work to kind of find those opportunities where the content itself could make the system shine.

Nathan:

And so that I really appreciated and was almost captivated by your specificity argument and be specific. One of the things I talk about in a design system principles include what’s shared and omit what’s not. Often these systems can be a range of products. The necessity variability that you include can have things that one product must have. Can you talk about the choices you made around allowing for that variation and is there a story where you said we’re not going to put this in the system even though one product perhaps should have or could have it?

Yesenia:

Yeah, there’s always those trade-offs. I think that we still have patterns that are pretty general, the text box, they can write any content and format it the way they want to. It’s kind of like where might there be a more specific use case, sort of like I think like Eater has maps. We have a maps product. But it’s very unlikely that — is going to produce maps. We focused on creating something for Eater. Within Eater there’s 20 city sites so it’s still used at scale. So we really thought about if this variation is mapping to the brand mission, then we prioritize that more highly. Where we push back on a lot of variation would be things like that were just kind of like visual variation that didn’t really bubble up to something greater. Like all the newsletter variations like why is there an image of pizza and why does this one have slashes, let’s just unify that because it’s really not doing enough for us.

Nathan:

That’s great. And so the classification system was based on purpose. I wondered did you find any patterns in purposes?

Yesenia:

Oh, yeah. Like shared purposes?

Nathan:

Sure. I’m thinking about for using this approach in a different catalog of components, what could I imagine might be some likely purposes and how do you arrive at —

Yesenia:

Yeah. So we had the design system for our audience websites. We also have one for all of our content management, the video, and in that one where they’re not thinking about expressive branding, they’re thinking more about unifying the UX of our editorial tools interests’ kind of shared workflows. There’s things like uploading a piece of content and whether you’re uploading a photo over some of the video, could that be abstracted into a pattern or do they need to be different. So kind of thinking about purpose in terms of like what workflow is someone trying to accomplish here.

Nathan:

I was curious because most of the examples you shared were content based. Sit back and absorb the content as opposed to data entry or rich, highly transactional environment. The upload is a good example of the latter. Did you have other experience that sort of created a distinction between content versus transactional UI, or were there other big characterizations that split components one way or another?

Yesenia:

I think that with each of these two design systems we’re aiming for different goals, so that helps to kind of frame the thinking. The one for our CMS we’re looking at consistency of user experiences. So like a navigation pattern across the board. And things like your dashboard where you’re kind of deleting or sharing stories, like that becomes — those become unified patterns. With the audience one we’re really thinking about being able to enable that flexibility. And so that’s where like there’s a conceptual divide between those two. But I still think that the idea of using scenarios and purpose to kind of create that scaffolding for how to use all of these components together is relevant in both these cases.

Nathan:

That’s great. Can everybody help me and thank Yesnia for her talk?

applause

Yesenia:

Thank you so much.