Peter Merholz: How Agile Can Turn Designers Into Pixel Pushers

Introduction

Peter Merholz is an experienced design executive and author who's become a master at building effective design teams. The one challenge he keeps witnessing is the negative impact that Agile transformations can have on design. The solution? We need to strengthen our design leaders—they need to push back on the systems that are trying to turn their teams into cogs in a machine.

I just didn't know what else you would do with computers. It wasn't until I was a few years into college that I became aware of human-computer interaction and those types of things. If you had met me in high school I would've said I wanted to go into advertising. So I had some sense that I wanted to be in a creative field.

I ended up getting a BA in anthropology from UC Berkeley. Part of the reason I pursued an anthropology degree was that it allowed me to take classes in videography—essentially filmmaking—because Berkeley didn't have a real film program. So I’ve always had some interest in those acts of creation, but as the anthropology degree suggests, I really had an interest in understanding humans.

After I graduated I had a weird job at UC Berkeley helping a professor who was interested in multimedia and education. Through that job I was able to teach myself Photoshop, Illustrator, and Director and started to figure out how to prototype interactive media.

Richard Saul Wurman's Information Anxiety was on that professor’s bookshelf, and it’s one of the two books that set me on my career path. It explained how to organize and make information accessible in a way that resonated very deeply with me and how I already saw things.

Find this on Giphy at SupersidePeter

So I taught myself multimedia production, essentially, and was able to use that skill to get a job as an associate producer at a CD-ROM company in New York called Voyager. That’s where I worked for the first time with people with formal design backgrounds.

There were a lot of folks from the New York School of Visual Arts at Voyager, and the company just generally had a high regard for quality graphic design. It was in that context that I started to find my way into design, which wasn't as a graphic designer.

I don't have any training in that and I've never really done much to develop that skill (as looking at any of my presentations will show you). At Voyager, I was hired as a QA tester. I was trying to make sure their programs were bug-free and that they worked as intended. But I started filing things as bugs that turned out not to be bugs. Instead, they were bad interface designs that I thought were buggy. So, when I went back to the person who designed it, they’d say it was actually working as they intended. That’s when I realized I had a knack for heuristic evaluation.

For example, we had a CD-ROM that we were developing that was image heavy and also had a ton of content so it needed a search function. If you wanted to zoom in on an image, you used a magnifying glass. If you wanted to search, you clicked a magnifying glass. I brought that to the attention of the designers: ‘We're using the same icon to mean two very different things. We shouldn't do that, that’s confusing.’

They were looking at me like, why are you, the QA person, telling me how to do this design? But it was indicative of how I was wired and in understanding the usability behind the design. It was also at Voyager that I read the other book set me on my career path— Norman's The Design of Everyday Things—which was as foundational for me as it has been for literally tens of thousands of designers in my field. That’s really where I started thinking about user centered design or user experience design.

Download this as Peter Merholz-inspired pattern as an Adobe Illustrator file. As Merholz told us: "Each image isn't richly detailed, but taken together they weave complexity."

Learning to Drive Strategy With Design

In 1996, I left New York, moved back to the Bay area where I worked for Studio Archetype as a web developer, because my only marketable skill was HTML coding. But working in that design context I carried forward that kind of heuristic understanding of what makes design sensible to a user.

Then I took the one formal class I've ever had in design, which was called Usability Engineering in User Centered Design. It was taught through UC Extension and for a semester I took a night class and developed some foundational understanding of human-computer interaction. That’s really what set me on my path. I came out of that course and changed my job from web developer to interaction designer. I was the first person with that title at this design firm, and then from that point on have worked in user experience design.

In 1999, I joined Epinions. I had been independent a little bit before then, but I’d started speaking at conferences and developing some notoriety. And Epinions was essentially looking for a head of design and they’d heard about me. At the time Epinions was this rocket ship Web 1.0 startup. It had been written about in the New York Times as the archetypal Silicon Valley startup in the late 90s, and that was my first management job. I had to build a team. There were about five of us total working on design for this website that essentially was a product reviews directory. It had bigger aspirations, but that was where it started, as a giant library of product reviews, helping people make better buying decisions.

Peter Merholz interviewing Don Norman at UX Week, 2008.

That was where I learned what it meant to be a manager, how to recruit and hire. As a design leader my job wasn't to be a creative director, telling my designers what to do; my job was to protect my designers from the rest of the company who wanted to overwhelm them with work to do.

In 2001, I started Adaptive Path, which was a user experience consultancy. At the time—at least in the United States—it was pretty much the first consultancy dedicated to user experience, as opposed to usability. Over time Adaptive Path grew to be a kind of strategic design consultancy. We evolved from focusing on web user experience towards recognizing the role that design can play in really helping companies develop a portfolio of offerings to address a user's needs or challenges.

At its largest, Adaptive Path was almost 50 people with three offices, big dreams and aspirations. We actually survived the financial crisis pretty well. But we hit some hard times about a year and a half later towards the end of 2010 and kind of shrunk a bit and closed some offices there. But that’s where I learned what it meant to run a business. I learned to understand the other aspects of the business, you know, what it means to manage your finances, and have HR, and all of those types of processes that I think a lot of designers aren't really familiar with.

I was responsible for recruiting and hiring pretty much every practitioner in the San Francisco office. So that's where I really developed my chops as a design hiring person. It’s also where I kind of went beyond user experience to embrace service design—again, design for driving strategy.

I left at the end of 2011 after ten-and-a-half years, because I wanted to get out of consulting. I’d become obsessed with the role that organizations play in shaping designs, and in shaping the experiences that they release. As designers, we tend to get very focused on, "Well, if I do good design then good design will get launched," but that's not sufficient.

Instead of consulting, I wanted to work within organizations so I could have access to the thousand little decisions that determine the quality of what actually gets delivered.

Download these Peter Merholz-inspired color swatches as an Adobe Swatch Exchange file.

DesignOps and Organization are What Really Drives Success

So I've been a design executive for the last eight or nine years running design at a few different firms, most notably probably Groupon where I grew a team from 25 to 60 over both product design, as well as marketing design.

For the last two years I've been independent, focused on helping companies get the most out of their investments in design. My main focus is on shaping design organizations, behaving as an interim head of design, leveling up design leaders and putting a real focus on design leadership.

I took a six-month contract at Capital One where I helped them in a DesignOps fashion by focusing on their recruiting and hiring processes and practices. I was working with a design team of 300. When you get a large design team—and that can mean anything over 20—if you don't have people dedicated to the operational matters of that design team what ends up happening is your design leaders are taking on those operational matters, and it slows everything down because operations can't be ignored. If you don't pay attention to the operations, the wheels come off.

Since the operations can't be ignored, then the other things you want your design leaders to do, which is usually some form of creative leadership and managerial leadership, just aren't being done. So the importance of design operations, and dedicated design operations, is to have people who can focus on those operational matters. That way, your design leaders can focus on the things that only they can do—whether it’s creative leadership, managerial leadership, recruiting and hiring, managing one-on-ones and professional development for their reports, all that kind of stuff. By offloading DesignOps to a specific function it frees up the time of your leadership to focus on their core tasks.

In 2016 I released a book that I co-wrote with Kristin Skinner, who I'd worked with at Adaptive Path. It was called Org Design for Design Orgs. It was essentially me trying to get all the things that I'd learned about building effective design teams out of my head. It has nothing to do with process, or practice, or methodologies and case studies, and all that kind of stuff. There's a thousand books that address that, but my experience, particularly as a design executive, was that the stuff that drives success is the stuff that no one's talking about. It’s organization stuff: It's how do you recruit and hire? How do you organize your designers, both within a team within the design team? How do you manage their relationships with their cross-functional peers (typically product management and engineering)? How do you establish a design culture? How do you know how healthy your organization is?

I had to learn and develop all of these practices on my own, because there weren't any resources addressing them as I was coming up. So when I had some time after a layoff from a company called Jawbone, I was able to focus and write this book with Kristin. I wanted to get all these things that I'd learned out of my head and put them into the community, and in an effort to kind of raise the floor of our understanding of what it means to lead successful design teams.

Download this Peter Merholz quote as desktop wallpaper or for Instagram stories.

Why Agile Transformations Devalue Design

There’s a lot of challenges in the design community today. Recruiting and hiring for designers, specifically design leaders, is pretty much a shit-show. But one that I'm becoming more and more witness to is the negative impact that Agile transformations can have on design teams. I teach a workshop called “Design Your Design Organization” and inevitably, I'll have someone who's coming from a large traditional enterprise and they're in my workshop because they have just gone through some form of Agile or digital transformation and they are suffering.

What often happens is an old big enterprise decides it needs to move faster and be modern, and they bring in one of the big management or IT consulting companies to help them embrace Agile and scrum. The irony being that these consultancies don’t really understand Agile, and so they teach these enterprises about “SAFe” (Scaled Agile Framework) or the “Spotify Model,” without actually understanding the implications of these changes. And the playbooks that these consultancies are running end up causing a lot of problems for design because they turn most of the designers into pixel pushers—all that is valued from a design standpoint is productivity in terms of feeding the engineering machine to continue to build product.

I've heard from design teams at a number of these large, traditional companies that after they started working with Agile methodologies their designers feel less empowered than they had been under Waterfall [a linear approach to development]. It’s just bananas that they’d even say that, but it’s because, with these implementations of Agile, design isn’t able to contribute to the upfront strategy thinking that they might've been able to influence before. Design becomes a factory for producing pixel widgets to feed the machine.

We need to strengthen our design leaders, because they're the ones who are going to be able to productively push back on the systems that are trying to turn their teams into cogs in a machine. Instead of allowing that to happen to their designers, design leaders need to wield the power they have to shape their teams differently, to not have individual designers embedded on squads and to encourage designers to be able to work across an end-to-end customer journey. You need design leaders who can articulate a vision of how design should operate, and then how it can interface with this Agile structure that has been often imposed.

The thing to remember about Agile—which in and of itself isn't necessarily bad—is that Agile was designed for engineering productivity and frequency. It wasn't created to help designers do their best work. Design is simply seen as an input into this engineering process. So what we need to do, is say: ‘That's not right. Design is a different kind of function and succeeds when operating in a different way.’

Then the role of the design leader and the DesignOps person is to become the interface between the design team and these Agile development teams, figuring out how they can work together so that each gets to work the way they work best. But design does not work best within the context of a typical kind of Agile engineering approach. If it’s going to succeed, design requires an entirely different approach.

This interview has been condensed and edited for clarity.