J Cornelius: The Onion is one of the Internet's best sources of satirical news and entertainment. Today I talked to staff engineer, Collin Miller, about how they're using design systems to help their teams communicate and speed up the publication process.
Intro: This is Design Driven, the podcast about using design thinking to build great products and lasting companies. Whether you're running a startup or trying something new inside a fortune 1000, the tools, methods and insights we talk about will help you create things people love. And now, your host, J Cornelius.
J: Hey, everybody. We are excited today to have Collin Miller. He is a staff engineer at The Onion. You're probably familiar with The Onion for all their satirical stories and all that stuff that makes you laugh. They do great work up there and we're here to talk to Collin about what he's doing. So hey, Collin, how's it going?
Collin Miller: Hey J, it's going pretty well. I'm glad to be here today.
J: Yeah, thanks for joining us. So are you in Chicago or just outside Chicago? Where are you?
Collin: Yes. Our offices are in Chicago. We are not quite downtown, we're very close to the loop, if anyone's familiar with that geography.
J: I love the loop.
Collin: Yeah. Maybe like one or two train stops away.
J: Oh, very nice, very nice. So for those people who might not have heard of The Onion, can you tell us a little bit about what it is and why it's important and what you do there?
Collin: Yeah. The Onion got started in Madison, Wisconsin in somewhere around 1986, 1987, as a humor publication, and their focus of humor is satire. To clarify sort of what differentiates satire from straight up humor would be that satire tends to have some sort of subtext or point of view that's in the humor, and the idea is that the reader reads the joke and laugh at the joke, and then can sort of piece together the point of view or the subtext in it.
Collin: Sort of the highest ideal of satire. And then sometime in the last 10 years, I think it was about, I'm gonna get the date wrong, sometime around 2014, 2015, the print publication, because it was originally in newsprint, the print operation shut down and it's been solely online ever since then. I work on the product team at The Onion and so, we work on maintaining the website in that team. We also run, when it was print publication, sort of the first few pages were the satire, and then beyond that were, what are the eight, what do they call them now, the classified ads and then something called the AV Club, which was sort of films, television, book, media reviews. So we have that website as well. And then in the last few years a third website called Click Hole, which is sort of a take on the Buzzfeed click bait sort of world of the internet and satirizing that or parodying that. So we have those three sites that we build and maintain.
J: So are you responsible for maintenance and kind of design systems across all three of those sites?
Collin: Yeah. The way that we operate our team is that the whole team works on the whole platform. We have an internal CMS platform and then operations to run the three sites. So my role, I came on in, as a front-end engineer, and I started to sort of push towards some design systems, thinkings, and processes to sort of expand the way that we operate.
J: Right. So was that originally motivated kind of to make your job easier, or what got you into thinking about using design systems and pattern libraries and these types of tools and methodologies?
Collin: Yeah. It definitely was motivated by making the job easier. So the, sort of the architecture of our system is we have a core platform and then we pull dependencies from that core platform to build the three different sites. So, there's some shared pieces of course, things like the menu structures, the navigation structures, the basic idea of having a content model. It's like a very fancy blog, is what I would say. And so just trying to figure out how do we communicate on the team, if a feature request comes in. Are we working on something that is really just for The Onion or AV Club, or are we working on something that is or should be shared at a more core level.
Collin: And then trying to differentiate between an example we had recently is for our videos. We produce some number of videos. I don't know the exact number but, we wanted to have pages that show all those videos. So sometimes they're split up by tags or series. So figuring out what parts of that are... is there some layout that's shared and is there some skimming with colors and fonts and the site identity of all these properties. Trying to figure out how can the team communicate with each other about what part of it that we are working on.
I think part of it was also because we didn't have that vocabulary, it wasn't defined. So it came down to the opinion or best guess of the whoever was sitting down and looking at something at any moment in time. And we didn't have that kind of shared instrument or resource to check ourselves against.
J: Right. So now that you have those things. What kind of efficiencies ... how has that aided communication or how has that changed the way that you work? Has that speed things up? Has it made cross-functional teams easier to work on? What have you seen?
Collin: I'd say we are definitely... I should stop tapping the table so we should go back just a second. I would say we are in the middle of this process but we have seen some advantages, some benefits to it, in terms of the communication, I could say speed to deployment. We always had this ideal that we could come up with a feature, build it once, and release it on all of the sites, but that was never something that really came to fruition, until maybe in the past 3 to 6 months we started to have success.
And I think that really just came from orienting the mindset of the team around thinking in components that way. To the level of, at this point, our project manager, our entire design team, all of the developers have this vocabulary of thinking about things as a component. And so, while we don't have a lot of hard and fast rules about how we do it, it's the way that we get into a conversation when we have a new feature. Everybody is thinking about, "Does this fit? Where does this fit? What is this? Is this something that we can reuse?" So it’s definitely reoriented the process of how we think about and go through our steps of building something.
J: Yeah, so its sounds like it’s changed the way you talk about the process of building things in addition to, made it easier to communicate about particular elements, or organisms within that system.
Collin: Yeah. And I would say that is the place where we've had the most success. I think there's definitely a challenge in trying to convince people to change the way that they work and the tools that they use and the things that they deliver. But what's a little bit easier is to change the vocabulary that people talk about things with. And I feel like if you get people to change that, then the rest of it starts to happen a little bit at the far end. Sort of like, if you try to change the beginning the end will end up different.
J: Right. So you're just kind of changing the way you're framing that discussion and as a result of that, you tend to get more alignment as you're having that actual discussion.
Collin: Yeah. One thing that was really helpful, when we first... the background on where this came from was I was working on some project, working on a bug fix on a style sheet and I kind of threw up my hands and said, "Hey. What's going on here? This doesn't make any sense to me. We don't have a defined way to talk about the things that we're talking about right here. I feel like we're just making decisions in the moment rather than aligned with some process." And so we had a meeting. We talked about some of these things and what came out of that was a series of regular meetings between some of the developers and the design team and the project manager of doing something like an inventory on some designs and just talking about the components, architecture and structure.
We went through the... you were referencing the Atomic design patterns just a moment ago, so we went through that, explained what it was, giving the idea of thinking of it from the smallest to the biggest, thinking in terms of things that are made of nothing else and things that are made of other things, in that direction. And then we went through on our white board. We went through our design and talked to the big designers about how to make the program that looks that design ... Our brain starts to slice it up into a box model instead of a nested hierarchy of elements.
And so, we walked through a design and really drew boxes to represent what we saw on the pieces and we went through naming exercises of what we would call that. And it was a little bit like just sort of everyone going to class and learning how we think about these things and those meetings didn't go on for much longer than maybe a month and a half but that was a big piece of changing the way that everybody talked about it and thought about it.
J: Yeah, sure. So, The Onion is primarily a media site, so I'm assuming that the bulk of the revenue is based off of advertising and maybe some content licenses?
J: So when it comes to how the design systems that you're using and the way that you're thinking about what you're building, how do you see that impacting the bottom line like are you generating more revenue or is it by speeding up the size or pages load faster? What kind of things have you seen? And have you seen the design systems directly play into the business goals of the company as a whole?
We've made some... The more I think about it, I do think those goals could have been solved without a sort of components mind set. It's a little intangible to describe how specifically a design system helps with that other than it helps the process at large. I think that's the harder thing to present to someone and justify is that, this way of thinking, this way of approaching work, will make the work faster and that's something that is an ongoing challenge is how to get buy in.
J: Right, so how have you done that? When you've had to talk with people on the management team or on the leadership about the value of these design systems, what do you tell them and how do they respond?
Collin: The way that I talked about it when at first, I was able to get more buy in on this was, I am interested in... There's a field of academics called Activity Theory, which was a Russian Social Science in the early 1900s and then there is the whole World Wars thing, so it sort of disappeared from the face of the planet for a while and then it showed up in the 70s and 80s in Finland. It's called a theory but it's more just a descriptive vocabulary for describing human activities. And so, I used that as the basis for explaining why we needed to let the developers infect the rest of the process with this component architecture of thinking and the justification for that was, in this activity theory world, you break things down into systems of activity.
So, the two systems of activity that I broke down would be designing activity and the development activity and they range the system of activity based on what is the goal of this, what is the outcome that you're trying to go to. And so, I said if the goal of design is to turn requirements into a specification of what needs to be built and the goal of the developer is to take these specification and turn it into a deployed website that's bringing in revenue.
Collin: What happens there is that means the output of one activity is the input of the other activity and one of the ideas of activity theory is this idea of... They say that activities are dialectical and what they mean by that is that any two parts of the activity, if you change one, the rest of the parts of that system will change at the same time. So, they're densely interconnected things, human activities. So the suggestion was then if this is true, a single system of activity, we're changing one part of it. Like if you change your tools, If you change your rules, If you hire a new person, everything about the process will change by introducing that new piece.
So the suggestion was, if then you have two connected systems of activity as a developer my input is the output from the designer. If I want to change the way that I work, I necessarily change my inputs and if I necessarily change my inputs, I necessarily change the designer's outputs and so, the justification for this design, "Hey, we as developers would like to change some of the architecture of this." Unfortunately, that means we can't succeed unless everybody makes a similar change.
J: Right and so the design system and the style guides and those tools, do those facilitate that common language so that everyone is changing the same way?
Collin: Yeah and I think that was where the outcome of them bringing people in, starting to build that language so when they are planning out design, they come to us now with those thoughts in mind, sort of more concretely once you get to a design system that is maybe represented by a living style guide and this is the part where we haven't gotten to quite yet. It takes a long time to be able to turn over your code and be able to drive that style guide from the code, we're not quite there yet but I think some of the ... That justification seem to be a good way to get things started without having to justify it with Math and Science.
J: Right, so it sounds like there's bit of a waterfall process from department to department. Are you using Agile or any other methodologies within departments or how does that work as your dealing with cross functional teams and collaborating on building things? What's that environment? What are those conversations like?
Collin: I think we definitely do end up being in a bit of a waterfall kind of situation because the way that our relationships are set up between the editorial teams and the product team, historically has made that be the way it is, we do have to stop and turn on a dime and push out what is needed by editorial without any regard for how we might do it, if we were only a software shop without having our clients in-house.
I don't know that we have yet gotten to a point where we're able to appreciate the benefits of the change on that level from going to a components' architecture.
J: So how have you seen the use of those components and those systems impact usage of the site? Like have you seen an increase in traffic or decrease in support request or anything along those lines?
Collin: I think something we've definitely seen is, describing it earlier, we had a feature, which was a catalog of all the videos for a site split up. Some of the site split their videos into seasons, series, and tags to sort of built a discovery portal for all the sites for all the videos through one site. We were able to deliver that across our three sites and once we've built the core components, it took the developer who's tasked on that a few days on each of the individual sites to integrate it.
I don't know specifically what the return or traffic metrics are on that, but we were able to deliver a feature to all three of our editorial teams, very quickly, which is a drastic change from the way things were before.
J: Yeah, it sounds like it sped up the design and deployment process significantly.
J: So what kind of metrics if any, are you tracking about how the usage of these systems is impacting either performance of the teams or performance of the site or ultimately helping to drive business goals?
Collin: So our indicators are page unions and ad trafficking, we don't have a tracking of speed of delivery of issues, is that where the question is getting to?
J: Yeah kind of, just thinking through, ultimately, the reason that we want to use these types of systems, is for consistency, is for speed of development, remaining agile, being able to test, and prototype things that could have in much faster than in older way of where you're designing everything from scratch every single time. So, I'm curious like what you're seeing at The Onion about, are these systems actually improving those things or are people actually getting more done? Are you able to ship more code? Are you able to do more work or to do better quality work as a result of using these systems and these methodologies?
Collin: Yeah, I think we're definitely… we're able to see features roll out to our different properties a lot faster than we saw before. Before, we treated a feature request coming from an editorial team as something we were going to build for them and would go on their site. Now we think more in terms of, if we build something we can provide it to the other team, the other site and the consensus seems to be that we're becoming more agile and faster to do that. We don't have any formal validation on that.
J: Is that something you're working towards? Are you working on developing KPIs around the efficiency of the design process as a whole and how the result of that design process impacts the performance of the site?
Collin: Nothing concretely, that's something that probably will start to happen a bit more now, something that is going on at The Onion is we are ... Do you know the website Gawker?
J: Yeah, of course.
Collin: And the soon to be the ex-website Gawker. So there is a large group there with the website, the Gizmodo Media Group with a more than half a dozen sites like Jezebel, Jalopnik, the group now and through another parent company, Fusion and Univision, we're all getting pulled together into a Fusion media group. Their process definitely has more of a space for creating KPIs around the process and we're starting to move the component architecture that we've learned at The Onion and work with big groups under Fusion Media Group and try to figure out how do we use that for that much larger team.
J: Sorry, does that mean that you'll be blending or homogenizing two separate types of design systems?
Collin: Yes, will be working on converting that to one larger design system.
J: Interesting, go ahead.
Collin: Yeah, the process there definitely has, when we get into the project, has this idea of defining KPIs per project. So the design system's project would define an indicator about if the idea is, if we're coming into this to improve the process then how do we show that we improved that process.
Collin: So, it will be good to have that question more formalized.
J: Yeah, I'll be interested to hear what you see as a result of that down the road, like maybe come back in six to nine months or in a year and figure out what type of results you've seen as a result of that process.
Collin: Yeah, if I think if I could sort of predict what I see from that is, one of the changes whereas on The Onion product team becoming part of this larger team is that, we are a really small team, say around a dozen people. Our project manager, developer, designers and we're moving to a team that is, I don't even know how larger but more on the range of like 30 to 50, located across the offices, there are office now in New York and in Budapest and the teams are a bit more... We're used to being a small team. We can all communicate with each other very rapidly and the whole team is more responsible for every project but because this group is much larger, we have to split into their process in our process now is to split in smaller teams to focus on individual tasks.
And something that I wonder about the idea of a design system is I wonder how successful can a design system be if you have a more isolated teams, I wonder do you have to have the team that's working on the uniquely design system maybe be organized a little bit differently than some of the other feature driven teams.
J: Meaning the people who are creating the design systems and maintaining it, they would have a different type of workflow or methodology than the people who are implementing it?
Collin: Yeah, I guess the way that I'm thinking about that is that the… so if a feature was… Let’s say if you are building a common system for one team, another team was building a live vlogging feature, a third team was making updates to the backend CMS, and then a fourth team was the team that was working on defining and maintaining the design system.
I might imagine that the feature level teams could work more in isolation from each other and if the design system team was working in that same way, I feel like that might cause some problems whereas if the design team was more of a team that had a presence on all the other teams, if that make sense.
J: Right, yes, sounds like that they would have a sit at the table with all the other teams and kind of be as an intermediary between all of those teams to make sure that each of the teams had the support and information that they needed?
Collin: Yes, and so I'll be interested to see how that project evolves as we work together more. This is also what I'm talking about, barely even started, we only started attending each other’s' meetings in the last month or two.
J: Yeah, I think that make sense. So, where do you see things going as a whole within... I guess since The Onion is becoming part of a larger conglomerate-and you spoke a little bit on that a moment ago-but as whole from a design thinking and design systems perspective, how do you see that impacting the business as it grows and continues to become more challenging?
Collin: I guess, I see it as almost necessarily, the thing with the design system was that even on smaller scales, a lot of the ways that we initially work, make a lot of sense to me. I have trouble answering what I think are some basic questions, I think with the full FMG now, we are going to be supporting 11 properties and when you have this split between what is the core base foundation of the architecture and what is custom per site, those problems compounded.
For example, if you're working on a feature and you go to a site… Let's say you go to theonion.com and you're working on some element and the color is green and I'm looking at this and the questions going through my head are, "Why is this green? If I change what it is, what else will change?" Those are kind of to me, the only really everything that a developer does, goes down to that questions, "Why is this the way it is and what else will happen if I change it?" Or maybe "What other things are this way for the same reason?" These are the things that are sort of fairly easy to get your hands on when you're working on a single site that doesn't have any dependencies with another site. But The Onion moving at our other three sites, those questions have been, at times, very difficult to answer and I can see them getting even more difficult to answer as we join a group working on 11 sites.
J: Yeah sure but then it kind of opens another thread of conversation about, if you're thinking about the users' goals, it seems pretty straightforward, If you want to get them the content and you want to make them laugh and that's kind of the user goal right?
J: And then obviously because it's satire, you want them to also get the subtext of what you're saying and you've got another group that you're serving, which is the advertisers. You want them to have as many impressions as possible and those two things feed on each other, so to me at least sitting from where I am, it seems that the user journeys, personas, and all of those tools are probably useful but maybe not as much so as if you're building a product. So do you have any perspective on that on how you're using user goals or maybe empathy mapping or value preposition analysis or any of those types of tools to fuel your design decisions?
Collin: Yeah, I think definitely for the publication side of things, you're right, there's the complexity is fairly low on that end compare to a larger product. Where we have a bit more of that… We have a lot of different roles. We have to think more a bit specifically about is, in the backend, in the CMS, there's the editorial team, which is the editor in chief and a deputy to them who does the run around and cracks the whip. There's the staff writers, we have freelances, we have a couple tiers of contributors, all these site so we do have a product that's not external but we do have to think about what are those roles, how do we support those kinds of things.
And I think that's a place where component architecture has a very solid chance of making an improvement because it came in the background, that's the part of the architecture that's kind of like, "Well, if it's not quite working, we can just put a note on it and tell the team this is what's going to happen." So I think using this kind of thought of process gives us the bones and the foundations to more clearly describe how we're going to help out those different people with needs.
J: Yeah, I think that make sense. So we're running short on time, I wanted to give you a chance, any parting thoughts? Anything that you would say to someone out there who's considering using a design system, thinking through how it might impact their business. What would you say as the one take away that you would want them to know?
Collin: I would say that for design systems, there's a lot of obvious things that seem... If you look at a style guide that looks like, "Oh that's really wonderful" And I can feel that if you're not getting that, that you're not getting the benefit maybe… But I think there's a lot of benefit that you can still get just from starting to get people to think about it and talk about it in those terms, you might not have to achieve the shiny widget at the end of the process to get some of the benefits from it.
J: Right, I think that make great sense. So if anyone's got questions or wants to know more about you're doing at The Onion, what's the best way to get in touch with you?
Collin: The way to get in touch with me is ... I'll give out my twitter handle and my email address. My twitter handle is @collintmiller and then you can email me at firstname.lastname@example.org.
Outro: That's it for today, thanks for listening to Design Driven. We're glad you enjoyed the show. Have comments, questions or an idea that you'd like us to cover? Point your browser to designdriven.biz and click Contact Us on the top of your screen. We'd love to hear from you. Tell your friends and colleagues about the Design Driven pod. Post on Facebook, Twitter, LinkedIn, or send them an email and tell them to go to designdriven.biz, or wherever they find the podcast. Until next time, remember what Thomas Watson, founder of IBM, said, "Good design is good business."
How can we help your company use great design to achieve its business goals?
Whatever you’re building, our workshops and project engagements can help you do it better. Reach out to discuss your project or request a quote.