Q&A: Theresa Mershon talks about agile publishing

In our webinar Inside Hearst’s New Agile Design Process Creative Director Theresa Mershon showed us how they switched from a waterfall to an agile process. Afterwards, she answered your questions about tools, upskilling designers to code, pair working, overcoming resistance, workflow and more. Here’s what she had to say

Throughout the adoption, was there ever any push back, and if so how did you deal with it?

When we started there were a lot of people saying, ‘Well, it’s fine to tear everything up and burn it down, but what if you can't build anything else to replace it?’ There was a lot of fear. But we had the support of our president and executive team, and that was really important. I can’t emphasize that enough. It’s possible to change things from the bottom up, but it makes it a lot easier when change comes from the top down. We were supported in the effort to change.

People mainly feared that they were going to lose their control and influence over the products. It’s still a challenge to find the right place to engage everyone, but in general the output was so much better, and the turnaround time was so much faster, that stakeholders stopped being afraid that if they didn’t get their view point in it would never go into the products at all—because they knew that we were always going back and fixing things and were always going to have a phase two, three, and four. That really took a lot of the pressure off. And when you take the pressure off, people stop acting so defensively.

How did you make the shift to do more coding?

The only thing that was blocking us was access to the development environment. Once we showed the engineering team we could be trusted to not break the Internet, we started pushing code and never looked back. Having guided a few designers into a code-based design workflow, I suggest focusing on learning the basics of HTML and CSS, but mainly to focus on CSS if your main concerns are going to be presentation and layout. Our designers need to learn how to write SCSS, but they have a framework in place to learn from. For the first few projects they aren't writing anything from scratch, just altering existing code.

If you don't have that luxury, start by forking CodePens and trying to change things someone else started for you. The best motivation is to get excited because you are making things happen!

Our designers also have to learn Git workflows and get comfortable using terminal. None of those things is harder than learning to use Photoshop. These are the kinds of skills you can only learn by doing. I've found more success getting designers educated using CodeSchool over taking a class, but a live class might be preferable for people who don't have free time at home.

A designer's success is linked to the success of the product, not defined by the quality of their specific design deliverables.

You also started pairing designers and engineers on projects. How did you overcome the cultural differences between the two disciplines when pairing?

I don’t think there are cultural differences between designers and engineers, as groups. I think there can be differences in the way that individuals prefer to work, and it isn’t always a good fit for someone to work in a very collaborative, agile framework.

We’ve definitively had engineers who did not like having to talk to the designer all the time. They preferred to receive all of the mock-ups and just implement them. But that problem was solved by the fact that we were already working in agile. Some shifted to backend engineering for a while, and some shifted back after they got used to working this way. There were designers, too, who didn’t want to have to be as involved in the coding side as our designers have to be.

So it wasn’t so much a difference between the designer and the engineer as disciplines; it was just a conflict between the way that the engineer liked working and the way that the agile process functions.

But if you’re designing digital products (which we are) and want to work faster and produce better work (which we do), you need to be involved. It’s important. So when we hire people, we make it very clear to them what our culture and our working arrangement is. We pull in people who are enthusiastic about working this way.

How does pairing work when staff are remote?

We work really closely with Hearst Magazines International, and they’re primarily based in the UK. We also have distributed team members based in New York, San Francisco, Nashville and Colorado who are all involved with our day-to-day scrum. We’re able to pair remotely by having strong digital collaboration tools. We use web meetings for everything. We use Skype a lot. We use HipChat internally, and we have integrated that with Jira. We’ve also invested in high-quality microphones to make sure those team members can hear everything that’s said.

So it’s not difficult to work together with remote team members, but they do have to follow the same workflow as the in-house NY team. When we work on a project with the UK team, those of us in the US work the hours of the UK team and vice versa.

Do you have separate dedicated app and web designers? Or would you expect a single designer to be multidisciplinary and cover visual, UX and UI design?

My team specifically focuses on UX and visual design for our web platform. There is a separate design team that focuses on app design. There is also a creative team that focuses on editorial design, and they produce all of the photography, illustration, motion graphics, and infographics for our brands' content. However, we frequently collaborate with these other creative teams, chipping in on the UX and creative direction of an app or editorial design.

I like to hire people who are open-minded and interested in developing new skills. We all have different backgrounds and areas of expertise (some of us are strong front-end developers, some are more experienced with UI/UX design, and some have strong traditional graphic design backgrounds). However the goal is that each of us could be capable of working end-to-end on a feature—from user flows, to UI design, to applying style and interaction in code. This makes us more useful on interdisciplinary scrum teams, and helps keep project team size manageable and resourcing flexible.

When we hire, we do not expect to find people who are strong in all skill sets. Instead we look for people who are hungry to know more about their medium, who want to fully own a project, and aren't afraid to try new tools and ideas.

I love hiring designers who have run their own businesses or have mixed educational and work backgrounds because I know they won't be afraid to dive in and explore a new discipline. A designer's success is linked to the success of the product, not defined by the quality of their specific design deliverables.

More than anything, we look for a strong visual design eye, creative problem solving skills, good communication and a passion for digital content. Everything else can be learned on the job. Based on my own experience, I think that if you work as a designer in tech you should expect to pick up new skills as the medium is still so new and rapidly evolving.

…we look for people who are hungry to know more about their medium, who want to fully own a project, and aren't afraid to try new tools and ideas.

Now that you do much more prototyping, and start this process a lot earlier, do you comp at all?

We really don’t do very much of it anymore. But using our tenets of being fast, keeping it simple and staying flexible, there are definitely times when making a mock-up or a comp is faster than implementing your solution, and there are times when showing someone a picture of your solution is enough to convince them to move to the next step in the process. For example, we still do comps when we need to present something to an outside team or agency that is going to develop for us and they need us to do comps. And occasionally we need to make big, shiny pictures for pitches. But even for those, we try to show as much of the real experience as possible, include demos, and only comp the additions to the feature that we’re trying to pitch.

Within our team we only really do light, low-def wireframes and the mood boards that I talked about.

You mentioned that early on that Hearst hired a scrum expert to help with the transition. What other personnel changes and training were needed?

Prior to 2014, we didn’t have a defined product management team. Products tended to develop in silos, run by different groups – editorial, advertising, consumer marketing were all to some degree competing against each other. Bringing on product managers who were pure product managers did a lot to change our culture.

We’ve also significantly increased the size of our internal development team. Whereas before we were working with offshore development, we’re now working almost entirely with in-house tech, and that has made scrum possible.

What do your sprints look like in your version of agile?

We’ve been working in agile scrum for about a year and a half now, and we have been able to see our velocity steadily improve. That’s one of the things that I really enjoy about agile. But it’s really important to follow it faithfully if you’re going to do it at all.

Designers are distributed among four scrum teams currently. We all use two-week sprints. Each scrum team attends daily stand-up, and team members also have scheduled working sessions for their specific projects. Backlog grooming, sprint planning and retrospectives happen once every sprint. Since everyone participates in planning meetings and backlog grooming, team members estimate their own work effort and leave with a holistic understanding of every project. People sign up for the work that they’re getting, for the most part. Sometimes I encourage specific team members to tackle certain projects because of their particular background or interest.

Retrospectives are so beneficial, and I love them so much because it’s a chance to bring up things that broke down during that sprint and make an action plan to fix them in the next one. We’ve made a lot of improvements to the way we work because of that.

Is your agile loop linear, or do you go back and forth between the steps until you get each right?

The process is a spiral. We try not to backtrack too much, but we often touch the same problem multiple times before we feel that we’ve gotten it right. For instance, with scrum, the goal with each sprint is to finish the work that you said you were going to finish at the beginning of the sprint. We expect to see things go live that we said would go live. We expect products to get pushed that we said we were going to finish. But once we push it, we see how it sinks or swims in the wild. We get hard data back, and then we go and touch that same thing again. So it’s definitely not linear.

A lot of the planning work happens at the beginning of the cycle, and we don’t break down and start replanning in the middle of the cycle unless something has gone very wrong. But for other points in the cycle, we try to move forward with the stories that we’ve set for ourselves, but that doesn't mean that we don’t go back and touch the feature again later.

How do you keep the team motivated and inspired outside of official project work?

We also have weekly Design Chapter meetings, which give us the chance to all meet and discuss our discipline, workshop our new designs, collaborate on fun/experimental projects outside of the official workflow and generally keep in the loop with each other. Our Design Chapter meetings are open to anyone who is interested in our world, and we are joined by other design and UX professionals from the Hearst corporation, as well as interested product and tech co-workers. In addition, we sometimes have group sketching or pair design/development working sessions.

It seems like a lot of meetings, between that and scrums, etc., but designers still have large blocks of free time, and hopefully their work is unblocked by the meetings they attend. We make an effort to make every meeting useful in pushing a project or initiative forward. Action items are immediately documented on Confluence and followed up quickly, and we try to complete planning within the meeting so we leave feeling that progress was made on the project.

Which CMSs you were using in 2013 versus 2015?

They were both custom CMSs. We are in the process of rebuilding it a third time entirely from scratch.

We actually considered WordPress, but in the end we realized that we had custom needs (such as ad products) that were so specific nothing that existed on the market could support them. Also, because we’re a big media company, we’ve built in all kinds of tools for editors in it—tools that tell them how stories are trending on other sites so they can syndicate across the network, tools that tell them how the velocity of their own features are working, content testing tools, etc. And we’re constantly developing new tools as part of the CMS, so it made sense for us to do it ourselves. The rebuild that we’re doing right now initiated to support internationalization. Hearst Magazines International works with our CMS, but they need specific tools that we didn’t have to consider—things like language support. So we’re rebuilding it to be more extensible worldwide.

What design changes have had the biggest impact on sales or conversion rates?

All of our web content is free, and we don't ask users to register for our websites. However, we do promote subscriptions and sweepstakes for magazines (both print and digital) as well as our free iOS and Android apps.

One recent change that made a positive impact on magazine subscriptions was the addition of a persistent second-level navigation bar with Subscribe in the first position on all breakpoints on our sites. Previously we only had exposed navigation at 1024-pixel wide screens and higher, and smaller screens (including most mobile devices) only showed a hamburger-style hidden menu.

Can you elaborate on your typography process?

If we are designing a site for one of our magazine brands, we will first review the offline brand identity and meet with creative leads from the print side to understand their design direction. Then we translate the offline brand into mood boards for the website, using a process similar to Samantha Toy Warren's Style Tiles.

Although printed magazines tend to use many fonts, for the web we have to boil down our type selections to only 4-5 fonts (including weights) because of performance concerns. We have a subscription-based agreement with Fonts.com that allows us to source from the site's entire library, which gives us a good selection of type to choose from, including many classic faces that are still used by magazines today: Avenir®, Brandon, and ITC Avant Garde® are all popular magazine faces included in our plan.

If we are designing for a new brand that doesn't have offline design collateral (for example our food-focused site, Delish.com), we’ll do more thorough type explorations. We have used Typecast to set up specimens for testing type pairings. We find it easy and convenient to use because we can access all the type from our subscription through the tool.

After initial research, we download web fonts directly from Fonts.com (we prefer to host our own web fonts to cut down on server calls) and immediately test them on our local development instances as we style the site. Designers are able to quickly swap out styles and weights as they work through styling the site's CSS. We work on a copy of the live platform, and use the specific site's database for content, so we are able to test type in a ‘real content’ environment. The next time we review the site design with stakeholders, they view it on a device and the design is populated with their content. We've found that this helps us address legibility, style and other type concerns quickly and realistically, with no surprises once the site is live.

How much attention do you pay to site performance?

Fast site performance on mobile devices is crucial to our business, and it’s something we discuss frequently across all teams at Hearst Magazines Digital Media. We follow best practices as they develop and look at benchmarks and outliers in our network (since we have 20+ sites to compare with each other). We design and build mobile-first, optimize and lazy-load images, utilize caching services, minify our CSS, and use inline .SVGs wherever possible.

For the design team, performance issues usually come up regarding web type. Type must load first for the page to render as we designed it. We are pretty strict about the number of fonts we include for a site. In most cases, we limit web fonts to four files. We also try to limit the number of web fonts that need to load in the initial screen view.

I don't think time is wasted if someone on my team spends a day or two learning a new tool and then decides an existing tool is stronger.

Photoshop vs. Sketch? Fight!

I'm really excited that web design tools have finally reached a stage where there is enough competition and user base to see real innovation happen. I don't think time is wasted if someone on my team spends a day or two learning a new tool and then decides an existing tool is stronger. That's much better than wasting hours a day over years using the same clumsy workflow. At the moment we use Sketch for all UI design, graphic production (eg, icon fonts) and UX documentation. We use Adobe tools as well, as they were originally intended: Illustrator for vector-based design when Sketch isn't robust enough, Photoshop for raster image manipulation, and InDesign for laying out documents. We didn't want to force the team to all use Sketch, but after a fair amount of work was completed using Sketch, it made sense for all of us to work from the same files in the same tool. We switched to Sketch because the stripped down features set, vector design support, ability to set styles and exporting options all improved our work speed. However I'm also always on the lookout for new tools, especially ones that facilitate collaboration with distributed teams. The design team has taken on more prototyping work as part of the design process as well.

Do you have any advice for designers working in environments where long-time staff refuse to adapt?

My best advice is to just start changing the way you work quietly. Even if you still have to produce high-def comps for review, see if you can convince an engineer to let you do the last cleanup round of CSS. For example, rather than sending a long punch list of pixel-perfect fixes, hack the changes using your browser's developer tools and start sending the correct CSS back—and from there work them into letting you actually commit the code changes yourself.

Look for allies on other teams—for example the developer who thinks they are a bit of a designer. Collaborate with that developer. If you can show that changing your process means faster turnaround and less trouble for someone else, I bet you'll find that person amenable to helping you.