Inside Hearst’s New Agile Design Process Webinar Transcript

Hearst Digital’s Creative Director Theresa Mershon shows how moving to an agile design and development workflow helped improve the speed and quality of their design work, double their traffic, and increase engagement.

Watch the video instead and see the related resources


Hey everyone and welcome to today’s webinar: Inside Hearst’s New Agile Design Process. My name is Shelly, and I work here at Monotype, and I’ll be your host for the next hour—broadcasting from our Belfast office here in Northern Ireland.

Now first off, thank everybody for joining us. So far we’ve got over 500 of you tuning in, which is great.  And those of you who’ve sat in with us before know that each month we tackle a new design issue or challenge, bringing in an expert to shine a light into those areas of design and typography where we sometimes stumble, get slowed down or just wanna understand better.

Some of you may know Monotype from our typefaces. Others maybe use our design tools and services. And hopefully when we’re finished today, you’ll all think of us as the folks who brought you a jam-packed hour on agile publishing and some tasty food for thought about your own design workflows.

Now with me today is Theresa Mershon, who is the Creative Director at Hearst Digital Media in New York City. You wanna say hello Theresa?


Hi everyone.


Now Theresa and I have been talking about and planning this webinar for a few months, and I have to say, it’s kind of mind-blowing how dramatically they’ve changed their approach to design and development there. But some the things they’ve learned are truly pure gold, and she’s done a really great job of condensing a load of really useful and interesting detail into about 40 minutes of discussion, where she’ll be talking you about:

  • how they went about making the switch;
  • the challenges it posed to design and the teams there; as well as
  • the unexpected benefits it gave rise to.

So Theresa, are you ready to get us started?


Yeah, let’s get going.


And off we go.


So hi everyone. Today I’m going to share with you a bit of what it’s like behind the scenes at Hearst Digital Media’s UX and design groups. Hearst Digital Media is a division of Hearst Magazines, so we support the magazines side of Hearst’s publishing business. We produce digital content for all kinds of magazine properties, some of them you may have heard of: Esquire, Marie Claire, House Beautiful, a lot of shelter titles, Elle magazine, Popular Mechanics, Harper’s Bazaar and about 25 total. So we produce a lot of content. We stream our content to websites, apps, social networks and many other platforms both within and without the Hearst Corporation. My team specifically focuses on the web experience, but we also work a bit with the apps and social media side. Over the last two years we’ve made some really big changes in the way that we work, and I’m excited to tell you all about it.

So first I just want to show you a little bit about our success. Between 2013 and 2015, we’ve more than doubled our unique visitors per month to our websites, and we’re on track to more than double our page views per month too. And page views are a pretty important metric if you work in digital publishing. That’s how we assess how much profit we’re making off of each user that comes to our site

However, in 2013 we were not working so quickly and we were operating at about half the velocity that we are now. We published 15 websites, 15 separate mobile sites, three responsive site, andwe had over 60 front-end templates that we supported. Each site that we published was a custom build for each magazine, so they had a lot of unique features that we had to support and maintain. Every time we redesigned a site it was basically like a full front-end redesign. A lot of the code wasn’t shared across all of the sites. We did share a CMS, but we had a lot of custom templates built in to the CMS that were used by only a handful of sites. The design team essentially acted as part of an in-house agency, producing the bespoke products for each brand. An average redesign took us about six months.

We had an eight-man team, we did all of the visuals, all of the template designs, lots of Photoshop mock-ups, we handed off everything to an offshore development team, which had its own set of challenges. We had an extended waterfall process.

Prior to the change, there were different business requirements on each property. Lots of one-off sites that were hard to maintain and very little time for prototyping or improving on anything that we actually got around to launching.

Rolling out a new feature for the design team meant that for every single site in our network, we had to create a flat mockup for each state in each new feature. Just to sort of illustrate for you what that meant, if we wanted to design a new feature for our entire platform, we would start with flat comps in each breakpoint, or separate desktop and mobile sites.

Conservatively you could say, we would need to show maybe two or three additional states for each new feature, so maybe about fifteen mockups for a single feature, for a single site. And then, you need to take a step back and think ‘Ok, but we have to do that for every single site that we’re supporting on our network’, because we had to send a PSD of every single design to an offshore development company to implement, and they were very much PSD to HTML. There was very little communication, so we had to show it all in our comps.

That meant, for a single feature, even a small feature like a new module that we were adding to a page, we would have to create maybe eighty-plus PSDs. And you can think about that, then think ‘Ok, well, what if we need to make a change to the feature?’ We had to roll that out to eighty=plus PSDs, and then we had to export those and send them off to an offshore development company.

Was this really necessary? Did stakeholders really need to see every screen before it was rendered in code? Was viewing static mockups of the new feature actually confusing and misleading for stakeholders?

Essentially, in 2013 we worked really hard, but we worked really slow. We would work around the clock making revisions to these comps. We would spend maybe six months working on a single feature before we could launch it.

And the thing was, when design work was finished and we handed it off to the development team, the feature wasn’t even developed yet. We would get it back and say ‘Oh, you know, maybe I made the wrong decision here’, or maybe the way we thought this would work isn’t how it actually feels once we see it in a live experience. Sometimes there would be elements that we had designed around, that didn’t make it into the final product, and that would leave big holes in our design.

While this was going on, digital publishing was changing. Pure-play publishing companies were beginning to challenge old world media companies like Hearst. There was a big challenge to increase our traffic, increase our speed, and around that time, management came to us and they handed down some mandates. They said ‘You know, you need to simplify your platform. We expect you to double traffic within a year. We expect you to double your velocity.’

And velocity didn’t just mean how fast we worked, but it meant how fast we could help the editors publish stories, how fast we could design, how fast we could release updates. Essentially, they wanted us to accelerate everything we were doing.

As part of this challenge, we were going to create a new CMS, we were going to create a new front-end design system, and basically we tore everything up, and we took it as an opportunity to create a completely fresh start.

We couldn’t do it working the way that we were working. Something had to give. A new CMS wouldn’t solve all of our problems, but it gave us the opportunity to break from the way that we were working. We took a step back and we looked critically at our approach, our process, our frameworks, our skills and our tools. We evaluated everything against the challenge that was handed down to us. How can we make things faster? How can we make them simpler and how could we be more flexible?

I’m happy to say that by 2015 an average redesign takes us two to three weeks. In fact, we’ve expanded from fifteen to over 25 fully responsive sites. We’ve extended our platform and design guides to several international properties. We’ve reduced our front-end template set, from over 60 to closer to six very flexible templates that allow a lot of modularity. We implemented a platform-wide design system that empowers us to spin up new sites or visually redesign existing sites in less than three weeks.

So how did we do this?

Here’re some examples of what our websites look like now.

Between 2013 and 2015 we overhauled the way we work. Handcuffs were off. We evaluated all of our tools and workflows for inefficiency.We tried out a lot of new products coming out onto the market for web design, from online tools like UXPin and inVision, to frameworks like Foundation, and software like Bohemian Coding’s Sketch. Nothing was sacred. We realized that the goal of the design team was not create sleek deliverables, but to make sure that our best design thinking is applied to the final products we released. By focusing on the end product, we were able to let go of a lot of old habits.

I’m going to walk you through the changes we made to our working process, our approach to user experience design, and the skills and the tools that we’re currently using.

So, as you can see, between 2013 and 2015, we work almost completely different from the way we worked two years ago. There’s very little that we were doing in 2013 that we still do today.

Huge changes were started by changing our process. We needed to work faster and working in waterfall wasn’t working fast enough for us. In 2014 the product tech and design teams all adopted an agile and scrum process. We found our velocity increased hugely working with scrum. In many ways, we took the same approach to our code base, and the way that we work with each other, as well. For instance, we started looking at frameworks in every place within our organization. For project management we started using tools like Jira, we modularized all of our problems, and we really focused on creating fewer specks, and more collaboration between our teams.

What we found was that changing the way we work, changed the way we thought. Starting with agile in design was a bit scary for the design team, I think. We really tore up a lot of the ways we were working before. In 2013 we would have received a very elaborate written spec from a business analyst, we would have converted all of that into wireframes, and then into high-def comps. We would have a lot of time alone with a project or alone with a feature, without a lot of the collaboration from the other teams, and at the time that we were finished with our part of the design phase, we would kind of throw it over the wall, hand it off to the development team, and we wouldn’t see it again until only a few days before that feature might launch. And at that point we would move into damage control mode, and just try to fix all of the things that were implemented the way we thought that they would be when they were designed.

Now, in 2014 we realized that we needed to move forward in a completely different way. We brought on a really talented scrum master, and she really helped us see how design could fit into agile.

So I’m going to answer each of those questions that I showed you on the last slide.

So what happened to the design phase?

Especially if you take on some of the front-end production and styling tasks as a designer, you can be involved in the entire agile cycle. We didn’t lose influence over the product by no longer having a design phase.

What happened was the design phase spread out over the entire cycle of development. In the beginning of a product cycle, designers would be involved with the product managers, working on sort of like UX processes, like personas and user flows. We would tend to do collaborative sketching sessions or really quick turn-around sketching sessions with the product management team, starting to shape the UI out from its kind of high level requirements. After that we move into a prototyping phase, where we worked really closely with some lead engineers on the same feature. After we finish prototyping, and we’ve decided that we’ve come up with a solution that’s worth releasing to our environment, designers and engineers pair-develop together. And I think that’s really key on how design works well in an agile cycle. Designers will sit with the engineers, as the engineer is beginning to develop the feature based on light wireframe sketches, sometimes even just a conversation. The designer has a chance to give immediate feedback, and they tend to bounce projects back and forth until the point where we feel it’s functioning well and all that’s left to do is to polish it up, implement the visual styling, and make it look good. At that point we hand the feature back over to the designer, and the designer is the last person to touch front-end experience before it goes out the door.

This means that instead of being stuck trying to fix something that was developed without that much time left to do it, we’ve taken over the time ourselves, and we are able to make the changes without having to do a lot of checking or going back and forth between multiple people.

That’s worked out really well for us and it’s shaved off an enormous amount of time. Now, as the cycle comes to an end, and we begin to have something that’s a candidate for launch, designers might focus on refactoring CSS, doing a bit of housekeeping, cleaning up the code, and then they might move into assisting the product management team on user testing and research.

After we test it out on our audience, we’ll loop back around, we’ll look back on the results of our testing and our research, we’ll look over the metric supports that come out the feature that we tested, and we’ll start a new cycle, back at the beginning, maybe adjusting our personas, reworking user flows, figuring out new features that we want to implement into a UI and you can see how the cycle just continues.

A lot of the designers were afraid they were going to lose control. We found that we actually gained more control moving to agile. We used to throw a lot of our designs over the wall, and often they weren’t implemented exactly as we imagined. Now designers are the last people to touch it before the feature launches, and we have a lot more input in the way our designs are implemented.

A lot of the time I’ve heard designers say ‘You know, MVP, lean development, doesn’t that just mean half-ass design? Doesn’t that just mean the designer isn’t really necessary to create the best possible product?’ And I can say the answer to that is ‘yes, and no’. Just because it’s MVP, doesn’t mean it’s not a polished piece of work. I think the more high-profile the projects you work on, the more important it is that each thing you release has a strong style guide, has a really good feel, and doesn’t maybe look as shaky as it is on the inside when it is presented out to the audience. At the same time, we’ve become more comfortable with launching features that are maybe not everything that we intended. Maybe it’s only 80% of what we intended, but working in the waterfall process we would often launch features that were 0% of what we intended. It also means that the designer will be able to check their design work in the real world a lot faster, and we don’t spend time upfront finessing details that might never make it into the final product.

There were times in the past where we designed an entire feature around a single element, and then we figured that that element wasn’t going to be in the product that we launched and that left us with something that felt like a half finished piece of work. Now we test things as we build them, and so that gives us a lot more information, and I think the end result is a better feature that’s released to the audience.

Another thing that comes up is the question ‘So is everyone a designer now?’ I think there’s a lot of fear when you start working in interdisciplinary teams that people are going to take tasks away from you that you think validate who you are in the process. For us it meant letting go of deliverables defining who we were as designers. It meant more that we were all evaluating our success against the final product. It was also really good for us, because it gave us greater knowledge of each other's roles on the team. As UX interaction and visual designers, we leveraged close communication with our teams by educating them on user-centered thinking and design principles. So, in an ideal world, everyone is a designer. In an ideal world everyone has a really high level of education around producing products from a user-centered point of view. So agile actually gave us the opportunity to advocate for that within our teams in a way that felt very siloed before. Also, designers take advantage of the agile scrum, sort like interdisciplinary working model, by taking on small tasks outside of their comfort zone. Sometimes those are maybe planning or product management tasks, and sometimes they’re more development tasks. But for us, that meant we could take on stories, work with a more experienced team member, and we’re all growing our knowledge of what it means to be a team that produces products in a digital environment.

And finally, our work is never finished, it really never is. But look at it this way: we removed levels of review and approval before we test a feature on real users. Because we get the features out so quickly, we don’t have to do a lot of rounds of review with internal stakeholders. We can come to them and show them living metrics on how the feature is behaving, and that takes a lot of the guesswork out of building new experiences. Instead of making changes to a mockup, we move the rounds of changes and improvements into the development cycle. We learned to trust that our future selves will make better decisions than our current selves. In the future we’ll have better information; the more data you have to work from, the better your result will be.

So how did that influence our approach?

Since we had the opportunity to work with a new, more flexible, CMS and a new front-end for our sites, we wanted to make sure that our approach to user experience would allow us to build a lightweight and consistent platform that would be easy to update in the future. Reflecting back on the goals that were set by our management team, we wanted it to be simple, we wanted it to be fast and we wanted it to be flexible.

However keeping it simple is really complicated, especially when you’re a large platform and you’re serving a lot of different stakeholders, and a lot of different brands, and you need to make sure that everything you do works for everybody. Essentially, our goal was to enable the brands on our platform to create unique experiences, and maintain a clean and easy-to-update UX and design system that could be quickly extended to an increasing number of websites.

That isn’t easy. We needed fewer templates, we knew we needed flexible modules, and we knew we needed infinite types of experiences that could be created from that toolkit.

We had to find efficiencies both in site design and rollout processes, so some of the approaches we took—responsive design was big. The design team were big advocates of responsive design for a few reasons.

Starting in 2011 we saw that mobile access to our websites was increasing faster than desktop use. It made sense for us to shift to a mobile first design process as it aligned with our user-centered values. Beginning in 2012, we started to roll our responsive sites out onto our old system, but found it very difficult to support both responsive and separate mobile and desktop sites in the same ad network. The rules are just different, and it was hard to maintain both.

By 2015, more than half of our traffic comes from smartphones. At certain points, on some of our sites traffic is over 80% mobile, usually in the evenings and sometimes in the afternoon. So for us responsive meant focusing on the mobile experience first, and it is a way of bringing mobile concerns to the surface whenever we tackled a new problem to solve. Many of our visitors find us across several devices, so it was important that we use a consistent URL structure.

I don’t think this is as important for everyone as it is for publishing, but for us, we will find a lot of our users, they will share a story to themselves, they will email a story to themselves, and then they’ll come back and visit it, and they might be on a completely different device. So for us it’s really important that the same URL will take them to a screen appropriate experience no matter where they are. And finally, Google rewards mobile friendly websites with better search rankings, and this is really important.

When Google changed their algorithm to reward mobile-friendly sites, the fact that all of the Hearst sites were already responsive and had good performance meant that we immediately shifted up in search rankings across the board.

Responsive design, again, it may not be needed for everyone. I think there’s really specific use cases where responsive is not the solution, and it does limit you and challenge you in several ways. Mainly, you can’t create these really elaborate, rich desktop experiences when you’re thinking about the mobile experience primarily. But at the same time, for publishing I think it’s a no-brainer.

We need to serve content quickly to everyone, no matter where they are, and more and more of our users’ only experience relating to us is on a mobile platform.

When it came time to implement our front-end design system, we leaned heavily of Brad Frost’s atomic design. We applied our modular approach at all levels. Our HTML and CSS modules are structured into elements, components and blocks, which give us the flexibility to use consistent elements in different configurations across our platform. Now, that’s good for a lot of reasons. I won’t focus on all of them, but I will say that from a visual design perspective, that means that you are able to enforce a great deal of consistency in the visual design of each site, and it also makes it a lot easier to update the visual design of your site because you’re only changing a limited number of elements that are grouped together into blocks, and then into templates. And you can make sure that if you change, for instance, the color of a link somewhere, that will change throughout the entire site.

I’ll brief you quickly on what atomic design is and how it’s applied for us. Essentially, an element is a basic tag—such as a form label, an input, or a button. A component would be a grouping of elements—so for example a form label, a search input, and a button together can combine to create a search component. And a block is a group of elements joined together to form a distinct section of the interface—for instance a date, a tag, a headline, a subhead, a byline and an author image can combine to create an article header, which we would then call an article header block. A template is just a unique configuration of the elements, components and blocks to create a single user-facing page. An example would be an article.

We then extended the concept of atomic design to the content administration side of our platform. We’ve done this by separating presentation elements from the content on the pages. Editors can apply a content type to any page or feed, which allows us to group similar content together even if it was on the different sections on the site. Each story within a content type can look very different. So, for example, horoscopes is a content type for us; quizzes are a really important content type for us; video, again, is a very crucial content type in publishing. But the way that you want to treat those different content types might not be the same.

You might have a video that you want to make a big feature. You might have a video that’s simply an element on a standard article page, or you might want to have it be as part of a bigger feature with a sidebar in it. It’s fine. You choose the content type, and then you select the display type. You don’t have to change the content at all. Just selecting the display type will drastically change how it’s presented on the front end.

In addition to this, we’ve added a third layer that we call ‘display options’. This gives us fine tuning control over every element in our UI. So, for instance, two big things that we need to toggle on and off on are ads and comments. Sometimes we need to turn comments off because an article might be a little bit incendiary, and we feel like it would detract from the article’s impact to have a lot of user comments on it. We might turn off ads if it’s a special feature and ads don’t seem appropriate.

We can extend this down to the modular level too. So, a single module within a template can have display options that control the way it looks or feels. For instance, you could embed a slideshow and say ‘I want this to appear as a carousel’ or ‘I want this to appear as a grid’. This gives our editors a lot of control over building the final page.

So, there is a lot of flexibility in the way that we put our elements together, but the elements are consistent across the entire platform. That’s great, but all the pages look very similar to each other, so the second challenge was ‘How can we make these look different from each other, while keeping them extremely maintainable?’ We published multiple sites, so we needed a way to find how we implement unique brand identities for each of them. I think this is even more important because we’re a magazine company, and magazines, historically, are very visual experiences, with lots of photos. But they all have their own unique tone, their own editorial identity. They’re very different from each other.

We achieved this with two branches. On one hand we adopted a UI design approach that was very content first. It was important to us that we allow the content itself to drive the identity for each brand, since the elements that we used to compose the content on the page were consistent across all of them. We also built in a visual theming system, and I think that a lot of you will be familiar with this. It’s very similar to what Wordpress or Tumblr allow you to do.

Each site has its own theme. We accomplished this by creating an SCSS-based style guide for each brand. We abstracted all of the major style elements, such as type, color, and animations like transitions, into our base files. We extended placeholders everywhere we thought we might want to change the look of an element by brand.

Each brand has four CSS files that determine the site’s look and feel. There’s a file for fonts, a file for type styles, a file for variables, such as borders and colors, and a fourth file that just allows us to add custom transition effects or other little bits of visual polish to our site. What we gained was an easy to launch, consistent, well tested, easy to improve and fast to spin up platform.

So, as I said, we moved from a six month redesign to a three week redesign, and the way that we structured our visual theming system was crucial to achieving that velocity. The challenge was that modularization made it hard for us to find ways to apply the visual identity uniquely for each brand. You know, an Esquire doesn’t want to look like an Elle. The way that we achieved this was really by focusing on a high level style guide for each brand, looking at what really made a magazine’s visual design unique to it, and trying to pull out the main elements that would allow us to achieve the same look on the web.

Those are kind of obvious, but color and type are really central to achieving a brand identity, and so, typography became like a crucial element in how we applied the design system. As a magazine company, we need to be able to present a 360 degree brand identity across print, web apps, and more. The website used to have its look refreshed frequently throughout the year. We couldn’t wait for a yearly or a bi-yearly redesign for each site. Not only is that a ton of work, but the magazines themselves update more frequently than that, and we’re on the web, we should be faster than magazines. We should be able to try out new visual ideas even faster.

Type is really the keystone of how we do this. And we really needed a way that we could swap out type very quickly, that we could use a multitude of different web fonts, that when a magazine switches Gotham for Avenir®, we could do the same within a day or two. So we found it very useful to use a platform-wide subscription plan with It allows us to use any font from the library on our sites. This is great because we aren’t limited by individual font licenses, we don’t have to write a contract every time we need to use a new web font, and we can make a big impact quickly by changing or adding new fonts to a brand site. We can try things out and throw them away if they don’t work for us. We couldn’t have made the system work without strong font choices.

Although web fonts are a concern when considering web performance, as an organization, we feel that the performance cost is outweighed by the visual quality the web fonts contribute to our brands. At one point, actually, as a test, we stripped all the web fonts off from all of our sites, and we wanted to check to see just how much that impacted performance, but just having our stakeholders look at what the sites look like using only using system fonts made them decide that the cost of using the web fonts was well worth it.

So that was a little bit of an overview of our design system. Now I want to talk a bit about the tools and skills we use in our design team every day.

I mentioned earlier that when push came to shove, we needed to reevaluate the tools and skills in the UX and visual design team. One of the big changes we made was to bring the UX and visual designers into the development process. Like many in-house UX and visual design teams in 2013, we were familiar with front-end coding individually, and we were really excited to dive in, but mostly, we had not been working in a professional production environment.

Here’s how we made our design team comfortable applying visual design and working through new features in code. Our design team, at this point, like we’d push code every day, sometimes we contribute more than the engineering team, and in many ways, we feel like we’re very competent front-end designers.

In my experience, taking a class off-line was not an effective way to get designers to get more comfortable with front-end coding languages. We paid for people to take classes, and they would come back, but they needed the practical experience of actually working in a system to get it done. It’s been a lot faster to take a designer with strong visual and UX design skills, and I can’t emphasize that enough. You can learn anything, but you need to have a strong eye. And so, when we hire designers, we look mostly at the quality of their design work, because we know that we can teach them anything else. So we’ll take these people, these wonderful designers, who don’t have a lot of production experience, and we throw them into an existing system using the same workflow as the front-end developers on our team, and then we gradually increase the complexity of the tasks that we give them. So, generally, we’ll start a designer by allowing them to hack someone else’s existing work. We’ll give them really simple CSS production tasks, then a more experienced designer can sit with them, and give them oversight and mentorship. After the designer learns the basics of our systems, they take on more and more complex roles.

The design team handles almost all aspects of rolling out a change to every site on the platform. We decide what we want a new element to look like in the browser, as we roll the feature out. This has saved us a huge amount of time. We’ve cut out visual comps past the discovery phase and we don’t have to worry about how our designs are being executed, cause we’re doing it ourselves.

When I talked to my designers this morning, because I wanted them to check over this presentation, to make sure that I was staying honest, this was one of the main points they wanted me to make to you guys. They love the fact that they can do it themselves. They love the fact that they have control over the way everything looks, and if they see something on the site, and they don’t like the way it’s looking, they can take the initiative to go in there and change it themselves. That’s been hugely empowering for them.

We’ve also been liberated to go in and sort of structure the way something is built to be as flexible as we need it to be across all of our brands. So, we tend to be generalists, we don’t all focus on the same set of brands, we work across all of them. We’re all contributing to the style guides. This has been really handy because it’s helped us think in terms of platform designers. It’s helped us think in terms of when we roll out a new feature—what’s the flexibility that we need for our Harper’s Bazaar versus an Esquire, and that’s, I think, made us better at designing features that are consistent across the entire platform.

We’ve also freed up our engineers to focus on engineering. The front-end team has built several tools to help designers save time and stay consistent. So this has been really great for us. Before, designers would have handed off something to a developer, and a developer would have spent all their time trying to implement the design. Because the designers have taken over the visual production, the front engineering team has time to focus on things like building better tools for the designers.

In 2013 a frontend dev would have spent a lot of time pushing pixels around. Now, the same front-end dev builds us cool tools like this grid overlay that we use whenever we’re doing layout on any of our sites. It’s pretty neat. You can go to any of our sites, you can go for instance to, you can hit Ctrl + Shift + G on your keyboard, and it would immediately turn on our horizontal grid overlay. This lets us, while we’re designing, check layout, so it’s really handy. There is a backend component, as well. The same engineer built us a set of grid mix-ins that makes it really easy for us to control layout when we’re creating new modules on a page; we can turn on a horizontal grid, too, so it helps us check vertical rhythm. It’s also been really handy for the QA team, because whenever something doesn’t look right to them, they can turn on the grid, and ask themselves ‘Well, does it align to the grid?’, ‘Does something look like it’s broken out of our grid in any place?’ and that makes it a lot easier for them to tell whether something is an issue that needs to be fixed and communicate that back to us.

Secondly, the design team follows the engineering workflows. We use the same workflows. We follow the same standards. This has been really good. For us this means that we use Git, we write SCSS, and we tend to use Sublime for editing code. We tend to use Git’s free terminal. We don’t use a lot of tools that the engineering teams doesn’t use.

I think this has been really helpful. This means that when the engineering team updates anything to their workflow, they educate us and we adapt to it. When coding standards change, the design team is educated alongside the engineering team, there’s no lag in between the engineering team making a change and us adopting it. And it helps us because we have a more experienced team on hand who can step in and help when a rebase goes bad, or something won’t compile. It’s just made it a lot easier for us to work this way.

We mentor each other. This has been a really great development for working in collaborative teams. Our new features that have user-facing elements, the designers will pair with a lead engineer. The engineer is able to mentor the designer, while the designer is able to help the engineer by testing the code as it’s developed, and polishing the final experience. Over the two years, we’ve had designers working in developing environments, we’ve moved from skinning or tweaking styles in completed production-ready code to prototyping, maintaining the CSS system, and working directly on base files. We’re reaching the point now where the design team is comfortable creating placeholders, writing their own mix-ins, and at times we even educate the engineering team on good practice, because we’re the ones in there doing layout all the time. There’ll be certain efficiencies that we’ll find that then we’ll take back to the engineering team and we’ll make sure they follow.So, we tend to collaborate together on standards, which has been really great and I think taking a step back from the way that we work, I think that it's really increased the, let's say, respect the teams have for each other. I think that now we see each other’s viewpoints a lot more clearly, and that only result in better product work from the team.

Finally we make time to play. It's really important as designers that we focus on the main directive using interaction and visual communication to create intuitive and frictionless experiences for our audience. There are certainly many designers who have gotten more comfortable coding and have started to transition into being more front-end engineers, however, we think it’s really important that we stay focused on design and visual communication. For us, we like to have fun. We get excited when we see cool, new tricks around the web. We take presentation more seriously than our engineering team does. We like to consider how each new module might need to be treated across our properties. We tend to look for ways that we can extend or even hack a design system to provide special effects for each of our titles. Having development instances means that we can play in a sandbox, and when we find new ways to display something, we strategize how to incorporate that back into the platform.

I think an example I can use is background patterns. It’s a pretty basic example, but we were designing a bunch of sites that were very minimal. We got to a site like Seventeen magazine, which is not a minimal brand at all, and it needs to be very useful and fun, and it needs to be changed up fairly frequently to keep the audience engaged. So we’ve developed a way to add background patterns and gradients, and like layers of visual effects to these modules. After we saw it working well on Seventeen, we abstracted it and added it into the platform, so that we can use those same tools everywhere.

We use online tools, like Codepen and JS Bin to experiment with CSS and Javascript. This is good, because sometimes the pressure is on when you’re working in a production environment, to just get it done as quickly as possible. So every couple of weeks we take on a project and we say ‘Ok, let’s experiment with cool CSS transitions’, or ‘Let’s experiment with cool ways of doing type paddings’ and we just do that offline, on our own, and share with each other, and that’s a great way of keeping us excited in working this way, and pushing us forward.

One way we make time to learn, and have fun is by building tools that free us up from manual busy work. I personally hate busy work, so any time I’m doing something that I think a computer or a script could do faster, I’d rather take the time to write the script, than to continue to do it manually. One example would be our style guide template. We pulled the site’s styles, fonts and visual elements, like borders and icons, into a template that’s powered by the same styles that are showing up live on the site. Any change we make to a site style, is automatically updated on this page. This frees us from having to maintain multiple versions of unwieldy style guide PDFs, and it ensures that we can provide partners with up-to-date style guidelines anytime. So we can just send them one link. We just send them to, and there will be a completely up-to-date style information for that brand. It’s open to everyone, there’s no password on it, so we can share it freely. When we were working with video teams, when we were working with outside vendors or outside ad agencies, this has been really useful for them.

So I wanted to recap with just a couple of unexpected results that came out of changing our process. Like I mentioned, our traffic has doubled. Our velocity as an organization has increased,. Our editors have gone from publishing five pieces of content today to upwards of sixty. Those are really great results, but there’re other outcomes that have surprised us, ones that directly impacted our team.

First of all, we found that we had more credibility in the organization. Design stopped asking for design approval for everything we launch. We didn’t have time to create mock-ups anymore, so we had no need for big design reviews. Obviously this was a huge time saver. At the time, we thought that this was one of the biggest risks that we were taking—not showing them what they were getting before they got it. That was a big shift.

The way we redesign a site today, we’ll just create a very quick mood board or a style tile exploration. Sometimes we’ll show only one, sometimes we’ll show up to three. We’ll work with the brand on establishing the right visual identity, but we’ll take all of the functionality and all of the UX out of the conversation. Then, once we feel like we have a good look and feel set, we’ll never show it to them again until it’s basically completely built out, populated with our content and ready to launch. Seeing designs fully implemented really improved the quality of the feedback that we got. There would be a lot of hesitation or disagreement when they looked at a comp before something was implemented. But I find that once something is implemented and you show it to your client or your stakeholder, the feedback becomes very consistent. Everyone sees the same things. Everyone has the same problems. The stakeholder’s closer to the user. And that’s the end goal, just to get the person who’s viewing the work and signing off on it to be as close to the environment that the user will be in as possible. So we show things on devices. When we do design reviews, we’ll bring a laptop, a phone and an ipad with us, and we’ll make sure that they hold it in their hands because that’s going to improve the quality of the information that they give back to you.

Unexpectedly, once we stopped asking for people‘s opinions on design decisions, stakeholders seemed to trust us more. They weren’t constantly questioning us anymore. They were seeing that they were launching quickly. They were seeing that when they did have an issue with something, we were making that revision really fast. And that really built their trust. That was something that we were afraid wouldn’t happen, and we were really happy at the way that it turned out.

We’re also better designers. We’re better designers because we are better developers. Designers took over so much of the front-end production, and as I said, we’re starting to take full ownership of the SCSS system. We have a much better understanding of how our technical ecosystem works. We don’t have to change design because a developer said it wasn’t possible. We don’t give a design to a developer that isn’t possible. We have a better sense of how our designs get implemented, which means when we turn out design work, it’s easier to build. We are also better developers because we are better developers, and that’s funny because that’s been very liberating for us in terms of doing work outside of the office environment. I found out a lot of the designers have taken on a lot of freelance projects where they’re doing everything from stoops to nuts, and in my mind, that just makes them better at what they do. We know that “design” is the reason why we’re here, and we’re primarily experts in visual communication, but the more we know about how our house is built, the better our house will be.

Also, finally, there’s more designers than ever, and a lot of times, when you talk about being efficient and streamlining processes and changing the way you work so you can do more, it’s because you’re downsizing. It’s cause your business isn’t doing very well. Now, we were really lucky. Or I should say what we did was really great, because our work was so successful that we’ve actually achieved more with fewer people, and because of that, we’ve been rewarded by the business saying ‘Yes, we need more of you guys! You’re doing great work!’ In fact from the time that we started until now, we’ve more than quadrupled in size in terms of our UX team alone. Meanwhile, creative teams around our department have increased in size as well. There’s just more enthusiasm for having design thinking involved in your project. As word of our progress got around, we’re even starting to work more closely with UX and digital teams in other parts of our organization.

So I can say, in general, it’s been really successful. We’ve been surprised at how much progress we’ve actually made, and it’s been really liberating for us. And I have to say, it’s been really empowering for us to work this way. There was a lot of fear getting started, and we had to do a lot of learning, and we had to change a lot, but the results were so positive that, right now, we’re all really enthusiastic about moving forward.

So, I hope that was interesting for you guys.


That was fantastic. I told you guys that she packed a lot in 40 minutes. But all super-useful. So, yeah, that ends the formal part of our presentation everybody. Listen, thank you so much Theresa, for taking the time to do this. I really appreciate it cause I know how much effort it was condensing all of that information. And thank you to everybody who tuned in today and stuck around for the Q&A. All of your questions really either make or break the end of our webinar here, so I appreciate that. And that’s it! I just wanted to say my thanks and goodbye, and we hope to see you guys in November for the next one!


Awesome! Thanks everyone!