Transcript

Hello everyone. How's everyone doing? Awesome. So there was a great talk yesterday about how design systems can help us make sense of the complicated world around us and all the complicated issues that we have to deal with, so I thought that was a great introduction to what I'm gonna talk about today which is a deep dive on creating flexible design systems.

So, like the intro said, my name's Yesenia. I'm a Design Director at VOX Media where I work on the user experience, design system and visual design of all of our eight brands on our owned-and-operated platform. And VOX Media is a house of editorial brands which goes deep to serve people obsessed with food, sports, gaming, tech, news, shopping, culture and where they live. And 30 second, deep-dive into all of them. The VERGE is our technology brand and it covers everything from science to culture and art and entertainment. Vox explains the news, and empowers people to be informed and put their world into context.

SBNATION is the fastest growing sports media brand which has over 300 fan-centric team communities. Polygon covers video games, so the people that make them and the people that love them. EATER, covers dining and food. RACKED is a daily shopping resource curated for real life. CURBED covers homes, neighborhoods and recode covers the intersection of technology and business. So two years ago the VOX product team started on a project to migrate all of our brand's websites to one code base and design system.

Which meant that we needed to create a unified design system to support all of those brands that I just talked about that have widely different editorial strategies, branding, visual design. And we did this because previously all of our brands had been running on different versions of Chorus, which is our contact management system. And that meant that maintaining and iterating our websites was cumbersome, and launching a new site would take several months. So we really needed to make that experience much easier, and make it easier to launch, build, maintain, and evolve our brands.

But this was gonna be a big problem to solve because as I said, each of our brands websites were incredibly distinct and tailored to the individual brand need. They were full of custom components, that ranged wildly from brand to brand. And the visual design system was also really custom, so a lot of different type faces and colors and visual elements. So we had to create a design system that could support different editorial missions, content types, audience needs, typography and branding.

And while we had to unify these distinct brand sites into one design and code system, we also had to provide enough flexibility for our brands to feel distinct. So in creating this design system there were a couple of questions that we had to uncover before we could get started. Which were what patterns and components do we need to build in this system? How can these components be combined in order to create distinct experiences? And how are we gonna create a unique look and feel for over 300 websites with one visual design system? So, let's start with some early assumptions and the things that didn't work. First off we started with layout and modularity, as an approach. We also thought that color and type were going to be enough to distinguish brands. And we had this idea that we were gonna create a platform that was brand-agnostic.

So, often when people talk about design systems, they're like, it's super easy, it's Lego's, it's just Legos, you get Legos, you put 'em together, you create combinations or atomic units and that creates you know various experiences and page combinations. And this idea really appealed to us, because we thought that by creating lots of components within a very flexible system we'd get a lot of range and variety. So here's some initial kind of stabs at creating some components that we did for Homepage heroes. And again, we were thinking about this super-flexible Lego approach. Alright we'll create a four-up, a two-up, a one-up and brands can use those as needed. And then here are like some entry boxes for Homepages, and again, it's like one component. We're like maybe images can be a little bigger sometimes or maybe if there's a map it can get a little badge.

So we thought that we could create these really flexible modules and then layer color and typography over them and that that would be enough to make our brands feel unified yet distinct, that didn't work. So we quickly learned that the solution wasn't going to work. So for one, our sites felt too similar, but more importantly we weren't accurately reflecting differences in content, tone and audience. Take for example CURBED and recode, they cover very different topic areas. CURBED covers homes and neighborhoods, while recode covers tech and business. CURBED has a lot of servicy content, like maps and guides. While recode has news, podcasts and events. CURBED city sites have very active commenters, while recode doesn't have any commenting. But with our initial design system none of these differences were reflected, they look very similar. Besides some different type faces and colors.

So that gets to that third kind of assumption that didn't work, which was thinking about this platform, brand-agnostically. This meant that we were trying to design a canonical-article product, the best feature product, the best homepage, without thinking about the individual, any of our individual brands while we were doing it. So, that idea just didn't work out. And to be fair this model does exist, right. On platforms like Medium or Apple News or any social network like Twitter, Instagram or Facebook, right?

They're creating the platform and you're adapting your content, you're uploading your content and it just needs to kind of work and adapt. But on our owned-and-operated platform, so our websites, we wanted more control and customization over how our brands were presented. In part because now that we had brands on Apple News and YouTube and Instagram, our owned-and-operated platform was the best place to get the flagship-brand experience. So this meant that even though we were just designing that one system, we needed to take into consideration all those differences in content, tone and the audience for each of our brands.

So back to this idea of Legos, in her book, Thinking in Systems, Donella Meadows defines design systems as, "a system of interconnected set of elements coherently organized in a way that achieves something." So that's the key there, in a way that achieves something. While we were focused on the general modularity of the system we weren't thinking about what our audience needed to accomplish when they came to our sites. And we actually found that while maybe in order to create a flexible system, we needed to start by being more specific.

Here's what we learned after our initial designs. One, you can't start with individual components. You can't start with the Legos, you can't start with the little content blocks. In this article for a List Apart, called The Language of Modular Design, Alla Kholmatova writes "We should start with language, not interfaces" when creating a design system. And we found something similar, for us creating a successful design system meant that we had to start with content and people. That means considering our audience, our editorial teams, the content that they're producing and consuming and also our revenue goals and requirements. And within each of these buckets there's a lot of variation.

So when we talk about our audience it could be return visitors or first-time visitors. They could comment frequently and maybe even upload their own content or they could never comment and they're just here consuming content. They could be entering via social media or via saved bookmarks. Our editorial staff, some are full-time staffers that might have more time to be able to kind of work with the layout. And some might be freelance bloggers, that just need to kinda get in, get out, as quickly as possible. And then each editorial team has a completely different workflow. And then with content, right, there's a ton of different types of content that our platform needed to support, from photography to words, video, podcasts, maps, guides and then all that ranged in tone, right from more friendly to more authoritative. Then we have to balance all of that with our revenue goals and our requirements.

So to really think about how to create this design system in a better way, we had to ask ourselves some questions about kind of each of these categories. So starting with the audience goals, understanding what the audience goal is, helps us understand what is the core problem that we're solving for? And for us, since we were designing one system for eight brands, we had to consider is there a shared audience goal across all of our brands? Or are there differences? Because if all of our brands audience goals are more kind of consistent, then we can create more consistent systems. But if there's differences then we need to add some variation.

We have to consider what the editorial workflow is, so how are our editorial teams using and maintaining these templates? What's the size of our editorial teams, what can they support? And then in content, what range of content do we need to support? And that could help indicate a need to add additional components or layouts. So, this led us to a much better process for creating our design system. And the key steps that we uncovered were one, start with a fast, unified platform. Two, be scenario-driven when creating variations. And three, find key moments for visual brand expression.

So, the first step was creating that fast, unified platform. And we had some principles about what our platform needed to be. And that was that, first and foremost, it should load quickly. It should be accessible and it should work well across all devices. We also should have a unified, core-user experience. So if we have users that are traveling from brand to brand they have a seamless experience. And all components that we build should be available to all of our brands. Even if maybe they don't use them or they don't have them turned on. But that doesn't mean that we should be creating a one-size-fits-all solution. You know we can have variations in components or layouts if the patterns are solving a specific problem.

So scenarios, not layouts, should drive variation. And that means that we can't have hypothetical situations, kind of like what I was talking about in the beginning when we were like, oh it's just a four-up and a one-up and a two-up and those'll get used. So you know this is along the lines of Christopher Alexander's definition of what a pattern is, in his book A Pattern Language where he says that, "Each pattern describes a problem "that occurs over and over again in our environment, "And then describes the core of the solution to that problem in such a way that you can use the same solution over and over again, without ever doing it the same way twice."

So this is very much in line with our definition of scenario-driven variations. And then when it came to brand expression and making sure that our brands still felt distinct. We needed to create a platform where our brands could feel distinct. We needed to be able to express strong editorial voice and identity. And this also meant that brand experience was more than just the colors or the type or the logo, that we had to think about giving our editorial teams tools to be able to customize their audience experience.

So our design system ended up being comprised of several layers. And I'm gonna break them down because I think that our definition of a design system, since it's spanning across multiple brands, might be a little bit different than kind of the common definition of a design system which is kind of like, you know Google Materials Design or Salesforce Lightning Design where there is one brand that's creating robust systems to enable efficient design and development across many apps or products. But since we were dealing with eight brands, our design system was a little bit different.

So what we have are templates for each of our core experiences, so an article, a feature, a home or a hub page, search, user profile. And then those templates are made up of sets of components and those components can travel across different templates, they're reusable, they're modular. But within the templates the components can be modified with scenario-driven presets. So that can change how a component displays the contents that's within it. So you know one could have larger images, one could display more metadata. And then layered on top of that is our theming system which supports variations in color, typography and visual treatments.

So I'm gonna talk about how the process that I described played out with some examples of some of our templates with our features, our reviews and our homepages. So I'm gonna start with features and those are pieces of long-form content that typically cover a topic with great depth and contain beautiful illustrations, original photography and engaging interactives. And before we created the unified system all of our features looked very custom and were challenging for our editorial teams to update.

So our task was to take 18 distinct feature templates that contained 81 code snippets and turn that into one, flexible design system. And for features, the audience goals were generally consistent, across the board. Right, people just want to read the content, maybe find something else to read afterwards. But there was a lot of variation in the actual content that was displayed in features. So when it came to creating that unified product, what we did was look to our audience goals. And our audience goals for features was consuming content, so making sure that it's easy for them once they land here to be able to read what they came here to read. But then also guiding them towards new content.

So our basic components were the lede image, the text box and the recirculation module. So when it came to the variations this was mainly around content and supporting different types of content. So we had our 81 code snippets, many of which didn't work or had duplicative functionality. And then there was also a lot of variation in the images that were displayed on features. They had different quality, different aspect ratios. So one of the first things that we tackled was some variations on our lede image component to be able to support different image types.

Some of our options are HED BELOW which highlights strong photography and then HEAD ABOVE, which still highlights photography but places more emphasis on the text and getting you to kind of the top of the article. And then HED OVERLAY was more for lower quality images, you know if you want something that's more textural or if you want an image but it's not very high quality then we might put a color overlay over it and put some typography over it. And then HED BELOW SHORT IMAGE, which was valuable for widescreen images or illustrations. And then SIDE-BY-SIDE, which was tailored specifically for vertical images like that delicious hamburger. The key here was that we only added a layout variation if there was the content need. So we didn't add layouts or variations just for the sake of it. So similarly, for our snippets, now snippets are components that are editors, used within our content management system to make their features or their articles more robust.

So they can be things like sidebars, tables, pull-quotes and galleries. And since we had 81 individual code snippets, many of which didn't work or had duplicative functionality the team that worked on this completed a content audit to understand which ones should be included in our system. And the main questions for the content audit were, does this add value? Is it currently available for three or more brands? Or is it a must-have for one of our brands? Right, is it so critical to their editorial strategy that it has to be included? And then that process helped us determine which snippets to include in the new system and generally kind of cut that number in half.

So those snippets were reduced from 81 to 43. Now brand expression for the features is really all about the details. So there's a lot that we could accomplish just with those layout variations and features have very custom photography or illustrations, so that gets us really far. And then we have our custom typography and color palette and then it's all about those details like, custom drop-caps, or pull-quotes which add a little bit of brand expression in a scalable way.

So just to recap, we started with 18 very different feature templates and then those were unified into one robust system that could support various content scenarios across device widths while still feeling distinct to our individual brands. The process for creating reviews went a little bit differently. At first glance reviews don't look that different from features because they share the same basic structure and many of the same common elements, right. Like the lede image and the text block, but there is one distinct part of reviews which is the scorecard component. And three of our brands have a reviews program, EATER, The Verge and Polygon.

They each used to have, surprise, surprise, very different scorecards. So the initial design for our scorecards was one scorecard component that had three primary sections, so a section for meta info, a text field and some call-to-action buttons that we thought could just be, you know this one flexible component. The problem was that we were creating these scorecards for vastly different things. So food, video games, and tech products and gadgets. And the people looking at these scorecards all had different goals, some wanted to know where to eat and what to order. Some wanted information about a game that they were interested in and some were looking for advice on what products or gadgets to buy. And then this also meant that the content displayed in each scorecard was very different.

So for a restaurant you wanna see the address, the cost, the rating. You want to be able to book a table. For a video game you wanna know the platform that it's on, the publisher, again, the score, it's a scorecard and the release date. And then for a product, you wanna know what are the pros and cons, you wanna be able to buy it and there also was a product image included in them. So instead of creating one flexible scorecard, we needed to create three different cards, a VENUE CARD, a GAME CARD and a PRODUCTS CARD. So a VENUE CARD, it highlights the content that helps you find where to eat.

So there's more emphasis placed on an address, on a price, on the website for the restaurant. While the GAME CARD is specific to games, so there's more emphasis placed on the score of this game across all the platforms that it's on which isn't a thing for a restaurant of course. And the the PRODUCT CARD, it highlights content that's specific to products, like a pro/con list and those Buy Now buttons.

So we started with three completely different scorecards modules and then we had our first unified version that was ONE SCORECARD, that was meant to be just kind of neutral and flexible. And then you know you can see that the content all generally has the same hierarchy across all of them. And then afterwards when we have three separate scorecard components, VENUE, GAME and PRODUCT that share many of the same common elements, but are tailored to showcase the most valuable content for that subject matter. And then these are still flexible components.

So IF for some reason CURBED decides that they want to start reviewing games all they need to do is embed the GAME CARD into one of their reviews. Now our homepages were perhaps the most challenging of all to unify. And that's because previously our homepages were incredibly robust and distinct for each of our brands. So we had to, the challenge of creating a unified product for this was a little bit more challenging. And we started with a research phase. And what we did in this research phase was try to understand what is the value of a homepage today? Who's our homepage audience? What are they looking for and how are our current homepages performing? And we sought out those answers by talking to our audience, through understanding our data and also through some user surveys.

And what we learned was that our homepage audience was primarily comprised of a loyal audience that returns often. So their primary goal is to find new content since their last visit. And of course they also want things to load quickly. So based on that research we determined that the homepage needs to clearly answer these three questions. What's new, what's important and what's helpful? But maybe the date isn't as important for this piece of content. And that matched back to three main areas of purpose or components for our homepages. The STORY FEED, our COVERS or heroes and UTILITY. Now I'll start with the story feed.

That is kind of the most important part of the homepage, because it solves our user's primary goal of finding what the latest content is. So it's just rev/chron list, and it's purpose is just allowing users to see what the latest content is. And it's made up of a bunch of what we call Entry Boxes. So, these entry boxes can change depending on the type of content that's in it.

So if there's a map, you get a map pin, if there's a review, the score information is displayed. If there's a feature then the image displays a little bit larger and more prominently. Now creating these scenario-driven variations for the homepages is also very important because if you'll remember back in the beginning of the talk, I talked about how we initially created these kind of generic homepage heroes because we thought that they would be the most flexible. But that ended up not allowing us to have enough range and it didn't communicate all of the differences in content that we had.

So we revised our homepage hero strategy to make them all serve specific content driven goals and also gave them all specific names. For example, this one is NEWSPAPER and it's a text-heavy layout for busy news reporting. This one is EVERGREEN, which highlights service content and is particularly helpful for some of our brands where users might be looking for a place to eat or a place to go. MORNING RECAP is one of my favorites and it is for the morning after a busy night of sporting events where users can catch up on all they missed over their morning coffee.

Something to note here is we gave all of these heroes specific names, so when we started we had gave them all kind of generic, layout-based names. And we switched that strategy, so again, in The Language of Modular Design, Alla says that, "in the process of naming an element, "you work out its function." so I think that's really valuable to actually give components specific names in order to better understand what its purpose is, and if you really need to add it to your design system. Now brand expression for the homepages took a couple of different forms. In some cases we had very flexible components, like this one is called the PROMO BAR and it's meant to promote content, typically big features or EVERGREEN content and each of our brands, many of our brands use it, and it's customized visually which feels distinct to each brand.

So here's some examples of those EVERGREEN bars on small screens. And then in some cases we added components to the design system in order to support more impactful brand expression. So while most of the decision around components was centered around audience goals, we also knew that it was important to be able to support all of our brand goals. So this was a MASTHEAD component that was created specifically for THE VERGE, but available to all of our brands. And it contains a logo, a tagline and a date. And they actually, they'll update the image and the tagline several times throughout their day as their promoting content, which is really cool. And I think the most important part of like this MASTHEAD component is when THE VERGE has a big story or a big feature that they drop, they'll use a one-story hero along with the MASTHEAD and basically art direct the entire page.

But it's pretty amazing, it's just two components, two pretty flexible components that are available to all of our brands, but they make such a huge difference in art directing their page and it's really exciting to see where they took that idea. So you can see here, that just with a couple of variations in components how different VOX and THE VERGE can feel. So THE VERGE has the MASTHEAD turned on and has an image uploaded to it, while VOX uses our standard navigation. VOX is using our NEWSPAPER hero, while THE VERGE is using that MASONRY hero.

And of course they have different color palettes and typography systems, but overall you get the sense that they're very different and that the content there is very different. But they're all built on the same unified platform with the same baseline components. Creating that scalable visual design system was kind of the last problem that we needed to solve for. How can we create a unique look and feel for over 300 sites with one visual design system? And what we found was that we needed to set some foundational elements and we also needed to figure out where we had room for customization.

When we talk about foundational elements they are things like our type scale and type system. Our color system, spacing variables. Our typography performance budget. So as I said one of our primary goals for our platform was that it was gonna load fast. So the type performance budget makes sure that we don't make the site load slowly by uploading too many typefaces. So the Types Scale and the Type System, the challenge here was that each of our brands have very different typefaces, which can vary in height, in width, in weight. So we couldn't use fixed sizes for all of the typography and we had to figure out a solution where we could kind of flexibly adjust and manipulate the hierarchy of elements.

So within our little Theme Editor we have a font ratio type scale that we can adjust and customize for each of our brands. And then similarly with the Color System, I think typically in style guides, Grants style guides, there's like a primary color palette and then a secondary color palette with some rules on how to use them. And we not only needed to determine what the individual color palette was for each of our brands, but then also figure out how we could use color variables to map each element of our sites to a color.

So here's some examples of some of our kind of most important color variables. Like COLOR-PRIMARY, COLOR-ACCENT, COLOR-LINK and COLOR-BUTTON background and what those values look like for three of our brands. And then again, the way this works is that all those color values map to something on our front-end, so that if I go in and I change COLOR-LINK to a different color it'll change on the front-end. And then these color variables can actually be very powerful when it comes to making things feel distinct.

So here are three Polygon sub-brands and they're basically identical, right. There's not different heroes, no different typography. They have different logos and they're using three different color variables set to different colors, which is COLOR-HERO-GRADIENT, COLOR-NAV-BACKGROUND and COLOR-LINK and they can feel very distinct just with those three color variables. And then here are some NEWSLETTER modules that are consistent in functionality and layout but they have variation in type, color and visual treatments like our borders.

So the combination of these scenario-driven variations with our theming system allow our brands to feel distinct, but still unified, they're still on one unified platform with the same components. Then here's some examples of how that plays out with our ARTICLES, so you can see some differences in typography and hero treatments. And then with the features, where you've got kind of even more variation because we have different lede image component variations. What's next for us? Now that we've finished this two-year project to build this design system and move all of our sites to one unified platform? Now we can focus on creating even more tailored experiences at scale.

So what I mean by that is now that we're all on one platform and running on one design and code system, if we want to go really deep and solve a specific problem for one of our brands, like EATER, we can do that and then we don't have to worry about that not scaling. So it could still be something that all of our brands could use at some point, but it allows us to create much more tailored experiences for our audience.

To close this out, successful design patterns don't exist in a vacuum. And whether you're designing for a design system for eight brands or one, your design patterns need to reflect the context that they're in, the people that are gonna be using them, the content that they need to display and how they need to all work together. Successful design systems need to solve specific problems. We can't just design for modularity or layouts, or flexibility. We need to think about how every single pattern that we create is solving a specific problem for someone. And that means that our successful design systems need to start with content and with people. Thank you.