IA Summit 2015 Main Conference Talk
Topic(s): organizational design
Design and UX have won. Companies are building in-house teams like never before. Unfortunately, they’re doing so with outdated organizational models, and so are not getting the most out of their design and UX investment (in fact, some companies are getting negative value because of how UX is placed within the organization).
In this presentation, I will use my personal story of growing a design organization from 30 to 60 as a way to explore how to shape organizations to deliver great user experiences. We’ll delve into matters of organizational models, team structures, and processes to identify how your organization can be most effective.
About the speaker(s)
Peter Merholz co-founded Adaptive Path in 2001, perhaps the world’s premier firm dedicated to user experience. He was instrumental in AP’s growth from a small boutique firm to a renowned international consultancy. More recently, he led the global design team at Groupon, including product/UX, marketing, and brand design where he doubled the team from 30 to 60, and was instrumental in the first redesign of Groupon.com since the company launched. He’s also worked with OpenTable and Jawbone. He is currently co-authoring a book on building in-house design organizations. Peter is also perhaps most (in)famous for coining the word “blog” in 1999. Really. In the OED and everything. Since then, he’s been blogging continuously at PETERME.COM.
Peter Merholz: Hello, friends. As I mentioned earlier, there’s a lot of you in here, some of you might not have heard, this is not a talk about information architecture. I’m at the wrong conference, sorry…
Peter: …but they let me in anyway. This is going to be a fairly wonky, dense, talk on organizational lulls, process stuff, and leveraging the power of design. There’s a lot to get through, and so I’ll start.
A lot of us, I know myself, and a lot of us in the community, as we’ve evolved in our understanding and in our practice, have gone through a road similar to what I’m going to talk about.
To deliver great user experiences, this is a goal that a lot of us bring into our work. Initially, I thought at least, that in order to deliver great user experience, I need to get the design right. Great design, ship it, it will be awesome. You do that and it doesn’t work.
Then it’s like, “Oh, right. I don’t need to get the design right. I need to get the strategy right. If I can crack the strategy code, do some user research, make sure that I’m responding to user needs, business opportunities,” all that stuff, then it will be great. I’ll deliver great experiences.”
But that doesn’t work out. Then for a new release, I realize it’s not about design strategy. The most important impact on your ability to deliver great user experience is, the organization that you’re in. And is it able to deliver on great user experiences?
I have spent the last, even before I left Adaptive Path last year and my time there, and since I left Adaptive Path, thinking about this. This talk is going to be focused on, specifically around design teams within large organizations.
There is a larger organizational problem that would take a whole day to talk about, but that’s we’re going to be going on. So [inaudible 01:45] .
Peter: In October of 2012, I joined Groupon to be the Vice President of Design. Before that I worked at a start-up in a similar VP role and before that I was in Adaptive Path. But I had never worked in an organization anything like Groupon. I never worked in a big company. I never worked in a public company.
It was all very new to me. When I joined, this was the work that I inherited. I was the VP and the team was as you see. You had to go on the right side there was a Creative Director and his team, communication designers.
The UX Research Director and his team of UX researchers and then this pile of product designers who worked on their core product experience for Groupon as opposed to the communication designers who are doing more like marketing type of efforts.
Those product designers were all unicorns. Before I joined Groupon, pretty much anyone doing product design had to be proficient in his visual design, interaction design and front end development. Which is weird because they didn’t do all of those things.
Separate conversation, maybe I’ll get to it. So that’s what I inherited and I needed to try to get this into some shape because I had a pile of 25-year-olds reporting to me directly and a lot of the things we’re working under when I joined, was essentially one of an internal services firm.
A project would come up and they’d ship a product designer out to work on personalization for two to four weeks or work on the shopping cart for two to four weeks or whatever it is. That designer would come back and then another problem would come up and they’d ship him out again.
This is a not uncommon model. You don’t see it as much anymore. This was pretty typical when companies first started bringing design in-house and when I saw in the mid ’90s, this was a much more prevalent model. The idea is that, companies are used to buying design from external agencies.
Let’s created an in-house agency. This internal services model, your in-house agency design works on project basis and designers tend to get organized by function. There are some pros to this model. They breed a strong design community.
When I joined Groupon, the Design Union, you saw that logo, there was this real sense of togetherness there. As a designer you get to work on a wide range of projects and something that we’ll play out a bit over the course of this talk.
Design costs are understood in this model, because there is almost a buyback or payback in part of this where the group asking for design understands that they need to pay for that internally. There are however, many problems with this model that outweigh it.
The primary one is that design is not seen as a strategic contributor. You bring designers in, to solve a very pointed design problem, and then you send them back. Designers, if they had issues with the strategy or the bigger picture are often dismissed because they are not part of those teams.
These designers have little influence on the upstream decisions that impact design. It breeds an “us versus them” mentality, designers versus the other people. They’re not collaborating. When I think of this internal services model, I very much think of something like this, the short-order cook.
You have a bunch of tickets and you’re trying to execute on as fast as you can. That as a designer is what you’re essentially credited for is. You may even deliver something fast. It’ll have to great, it’ll have to be OK. In the same way when you go to a diner, you’re not looking for the best.
It’s only something that satisfies you and you move on. It’s not a model that a lot of us and a lot of designers want to be working in. We want to be held to higher standards. That was a model I inherited.
A typical model in Silicon Valley at that time and at this time that I considered is the decentralized and embedded model. To explain that, I’ll diagram how that works. Imagine an e-commerce experience such as Groupon but it can work for almost any generic e-commerce experience.
A lot companies even have essentially featured teams who are responsible for different parts of that experience, search, browse, product page reviews, et cetera. Their feature team is made up of design, product management and engineering. This has become this sacred triad of product development.
What you do is, you have a set of teams, designers or product manager and usually three to five engineers who are working on that feature. It’s a model that can work pretty well. Then you have leadership that oversees all this. That provides management across and then the design director.
The director of product management and director of engineering are also figuring out the road maps, the plans for this larger team moving forward. Decentralized and embedded is an interesting model. I call it the “everyone gets a designer” model.
You get a designer, and you get a designer and you get a designer. Everyone gets a designer. It’s great. Unlike the internal services model that is project-based. This is what I call program-based. You have designers who are dedicated to things for a much longer period of time.
So the pros are with design included and dedicated for a longer period of time. Design is now included throughout the product lifecycle. So they are involved in those upstream decisions. They are seen as a core member of the team and someone to listen to as opposed to someone to dismiss.
There are problems with it though. The biggest one that I wasn’t going to be able to overcome within, what I was trying to do at Groupon is, when you decentralized and embedded in that way you’d end up delivering a fractured experience. It is not cohesive. It is not consistent.
People solve problems in isolation of each other, those walls. Then when you bring it together, you realize like, “Oh, that doesn’t all come together and now we’ve created something that’s more problematic.”
Also though, if you’re thinking about this from a pure design management perspective,” that guy, that guy is lonely.” Because they spend most of their time talking to people who don’t know what they do, don’t understand and relate to them.
Designers as you might have found out if you’ve managed them, tend to be more sensitive, very empathetic, a little more on the emotional side. I’m not. This was one of the things that I had to learn as a design manager and it can be really frustrating.
It could be hard and yes, you will occasionally engage with the other designers and other teams, but you’re really in that universe of the program. It can be hard. Leah Buley has written about that UX Team of One. It is that model and it can be challenging for that individual. I don’t want lonely designers.
They don’t stick around as long. In terms of that fractured experience, one of the things that happen when you have this model is what happens on Facebook. If you use Facebook and gone from App to App within Facebook, it is a totally different experience apart from the blue and the Arial text.
It is totally different within the same website. These are four shots going downhill here and I click, click, click. You have the news feed but that works different than the messenger, you have different things on the left hand side and we are used to having navigation on the left.
And now we have navigation across the top for photos and it may never get on the left here. But this navigation is quite like. It’s totally a crab show. So any new App that you’re going into, you have to de-learn how to use Facebook in that context.
So they called and made a strategic decision that that was OK but they weren’t going worry about coherence across an experience and that my work for Facebook has more of portfolio featured. They’re not expecting everyone to use all of Facebook.
Maybe they are but in reality not everyone is using all of Facebook to have a complete experience. Or you can spend your entire time in the newsfeed and have a really satisfying experience. At Groupon you can’t spend all your time on a product page and feel complete. That’s not sufficient.
So I needed to figure out, how we’re going to make something that’s going to be more coherent. So I have to throw a different model and it was a model that was predicated on organizing for the customer journey. Coming out of Adaptive Path we talked a lot about service design.
We talked about service mapping. This is more of an Adaptive Path’s signature deliverables. The experience map that was created for Rail Europe. It mostly as an illustration but the idea being, these is a lot of things to manage when you’re trying deliver a complete experience for someone.
And I would suggest you want to try to organize your design team to deliver on that. Organizing for a customer journey and you can’t have that fractured messaging that go from bit to bit or people are going to drop off. You’re going to be delivering a bad experience.
The other thing I realized to think in terms of teams is important. I think too often, particularly where I am based now and in the water that I am swimming there is this idea of the unicorn, of this lone designer working on products and being this full stack person.
So you may need one and they can do it all. In my experience, a complementary set of designers working in a team is going to deliver better than five unicorns working individually. You’re going to get efficiencies of scale, you’re going to get the T-shaped thing like people better at specific parts of the craft.
But able to collaborate and even deliver overall a better experience. There’s no way that any unicorn is going to be able to be the best at everything, whereas your team, you can have each of them to the best at everything and fluent enough at the other stuff and complement one another skill sets.
I’m going to stress teams here, because I don’t think we think about teams often enough, at least internally, when it comes to structuring design capabilities. This was the product universe at Groupon. There were 40-ish different product teams, like those feature teams I showed.
Instead of everyone getting a designer, one, I didn’t have enough designers to do that, but instead of everything getting a designer, what we did is we organized that product world. Then, created a set of teams, that’s what these are, that serviced a set of those featured teams.
We had a few that were centralized around prototyping, research, and brand design, but most of the designers were working on these design teams that, in turn, had relationships with sets of product teams. The way it would look, let’s say you take the platform team.
Which would be responsible for something like this. Platform was responsible for the core functionality that you would see throughout Groupon, regardless if you’re selling local experiences, goods, getaways, those types of things. Instead of being decentralized and embedded.
The design team, instead, there is a team. You have a team with a director, and some senior designers, and other designers, and they really operate as a team. Instead of that embedded-ness, what you have is design leadership within the team working with those feature teams.
The design director is still leading the whole program and working with a team, and then the senior designers splitting their time across a couple of these teams. Importantly, product managers, who serve as this coordination hub of getting stuff out, always know who they can turn to when they have a problem.
That’s one of the things that project managers love about the decentralized and embedded model is they know who their designer is and they know where to turn. Where they get nervous about centralized design models is, “Who do I go to?”
The idea here is to have someone that you’ve identified who is committed to those teams. That can happen. In my experience, you can have design leads who are working across a couple of features that doesn’t spread them too thin.
This is how we organized. The term I’ve adopted for this model is what I call centralized partnership. The design team is centralized, as those rays suggested. They tend towards the center, and they reported up through me as the VP of Design.
All design at Groupon reported up through me, so there was a centralized orientation, but there was a committed partnership. We didn’t pull someone out and send then somewhere else, then pull that person out and send them somewhere else.
If you were in one of those product teams, you knew who the designers were that you were working with. You knew that team that was working with you. That was my attempt at trying to deliver on the best of both worlds.
Creating a centralized design community of practice that still was delivering for those product teams in a way that demonstrated the commitment so that they would be seen as real members of those teams that they were working with, the product teams they were working with, and not be dismissed.
Points about the centralized partnership, organized for the customer journey, trying to make sure that you are addressing the parts of the customer journey in a holistic way. Creating these teams that maintain commitment across a meaningful set of features.
Those features the platform is working on are part of a coherent experience, and so you want one team to work across product page, and search, and browse, and reviews instead of designers who aren’t talking to each other.
If you go to amazon.com, you will see designers who don’t talk to each other all together on one product page. That’s how they organized and why it is weird the more you scroll down.
The centralization helps maintain that coherency across the entire experience. This is one of the themes of Andy Fitzgerald’s talk yesterday, Jorge’s talk yesterday. Coherence is important. Making sure that the experience hangs together is important. This model is designed for that.
One of the side benefits is, oftentimes, in my experience, product and engineering teams like to reorganize. It’s a thing they do. If your design team is structured in such a way that it’s responding to the customer journey and customer experience.
You can stay stable while the musical chairs revolve around you as they figure out where it is they’re orienting. You don’t have to find your designers getting whipped around in other teams’ re-orgs, because your organizing principle is a different model.
Often, than the engineering and the product management organizing principle. It’s one that’s external to the company, and so it tends to be a little more permanent, a little more stable.
That’s the big picture. I’m going to talk about teams. Before I get into teams, there was something else about this group that was important to understand when I joined. This is something I’ve come to since I’ve left Groupon, a realization.
It’s a model that has worked pretty well for me in thinking about designers and design practitioners operating at anywhere from the 10,000-foot level to the 1-foot level. I tend to operate between 5,000 and 100 feet. I’m not the detailed person. I’m not good at executing on final, detailed, polished designs.
That’s not my strength. This maps in some way, you can all envision it, I don’t have it up here, the invoice of Jesse’s planes. We’re starting at the top with strategy, scope, structure, skeleton, and surface. He has them going from bottom up. You can think of them.
When I joined Groupon, there was me, and I was supposed to live at the top, and see the big picture, and make sure it all came together. My user research team, I had a couple of folks who also had that view of the world, and all the designers were really focused on delivery and the details.
Didn’t really have a systems thinking approach and a coherent approach to thinking about the problem. They, “What is the problem? I’m going to solve in isolation and go.” There’s one exception.
I had one slightly more senior designer who could go up there, but by and large, I had inherited a team, because they were all fairly junior, of folks who were focused on execution. You’ll notice there’s a gap here. What’s become my playbook, both at Groupon but it’s also true at Jawbone…
Because I’ve inherited a team that had a much smaller but similar leadership. Lots of folks sweating the details and not a whole lot in-between. My playbook is to bring in that design leadership layer, and I’ll talk about that.
The structure of each design team. Now, I’m taking that model, and here’s a team, like you saw in that platform diagram, that spreads across form about 1,000 feet down to one foot that can work well together with design leadership, that designer director driving it.
Some senior designers who can go between, and then some more junior designers who are executing on the details. Not necessarily junior, they might be that’s where they do the best work is really focusing on those details.
In my experience, a good design team is about four to seven folks. Much smaller, not enough critical mass. Much bigger, it gets a little overwhelming. If you find a design team getting beyond seven, you might want to break them into two teams of four and then let them grow.
The thing that made me look best at Groupon was hiring design managers and design directors, AKA middle management. Middle management is awesome if they’re good. Middle management is the grease that keeps the machine running.
If they’re bad, they’re the sand in the gears that cause it to fail, but if they’re good, they allow that machine to hum. My first nine months, I spent a lot of effort looking for design managers and design leaders, because I knew that those would be the folks who had a harder job than I did.
They have to manage down. They have to get the most out of a team. They have to manage across. They have to collaborate with product managers and engineers. They have to manage up to people like me or other executives.
These are folks that have to be able to get from 10,000 foot to one foot and back and not get the bends, and whip around pretty quickly. That’s not easy to find. It took a long time, but I was able to get a good squad in there, and recently completed that process at Jawbone.
I’m looking forward to seeing how that turns out. Design teams should be organized around business problems. They should have a spread of skills within them.
There’s some companies that organize design teams by function, a visual design team, a UX design team, an information architect team, a research team, et cetera.
You should be oriented on a business function and have a mix of folks who can work across that and address all of those different aspects of design within that team. The other thing that happens is that you’re going to have teams at multiple levels.
Not only did we have these specific design teams, we also had an overarching consumer team, that met once a week, to make sure that marketing, platform, mobile, local, business, getaways, were all tied in with each other, and that they were delivering coherence.
The merchants teams, the people facing the merchants, were smaller. It was a smaller set of folks, but there were two of those teams, and they needed to make sure that they were delivering a coherent experience. You do have fractal teams, as well, that you need to be aware of.
Something else you might have seen in this and wondered about, I had marketing and brand design in my team. Often times, if you are the head of UX, or the UX director, you don’t get involved in marketing and brand design. That happens in another part of the organization.
At Google, when I was the head of design, we centralized all design, including marketing, That, is exactly the right way to do it. It is an archaic organizational structure to have marketing design report up to a marketing VP and product designer report up to a product VP.
Archaic as in like a 19th and 20th century model that no longer makes sense anymore because if you’re designing for that customer journey across a bunch of touch points where someone who isn’t yet a customer and not necessarily using the product, but is reading websites or calling people, et cetera.
And then becomes a product user. It’s the same person on the same journey. It doesn’t make sense to have the design teams isolated from each other. They need to be working together, delivering against the journey, not thinking about, “I’m working on marketing, and I’m working on product.”
There are some challenges in getting product and marketing designers working together, because marketing design tends to happen at a speedier cadeus. It’s campaign-based, and the turnaround times tend to be faster than product design.
It’s still worth addressing that hiccup in order to have the marketing designers understand what the product designers are doing and what they’re trying to achieve, so when they’re doing the marketing design, they can deliver appropriately on that.
At Groupon, I got the teams together, hired the right people. We were all good to go.
The next thing I had to address was, I’ll explain. This is an anecdote, but you’d had these project plans when I came into Groupon, and this is not Groupon. It’s other places, either I’ve been, or people I’ve talked to.The words are going to be way to small, so I’ll read them out.
A common project plan will start with an initial insight where someone has an idea, often the product manager, it could be someone else. Develop a plan to execute on that idea, “Here’s what it needs to do. We’ll flush out the solution, do some user testing, if we’re savvy, refine it, build it, and ship it. ”
Then we’ll do some analysis, and go, “Wait, how do we know we’re successful?” We barreled ahead and we never stopped to think. This happens a lot, because you get very ship date focused. You get very delivery focused.
You’re Agile, and you’re Lean, and you’re trying to push a lot of stuff out. What I’ve seen is in that model there’s maybe not as much forethought.
A slightly more enlightened plan, you go from initial insight to plans to, “Maybe let’s try out some stuff first and do some sketching.” You’ll prototype some solutions. You’ll test those prototypes before you get into that more active and detailed design and developmental model.
What happens is once you bring strong leadership in, one of the reasons this could happen is, I mentioned how I had a bunch of 25-year-old, in-the-weeds, designers, they cannot go to a 35-year-old product manager and be seen as a credible engager of strategy and roadmap.
What happens is the product manager’s like, “Here’s what we’re doing,” and the 25-year-old designer is like, “Yes, sir,” and if they disagree, they’re dismissed. This is one of the reasons you bring on that leadership is to have folks with experience, with gravitas, who can engage productively with the other leaders.
When you get that, you can start doing more ahead of time. What this is, some of you might be familiar with it. I’ve written about it, spoken about it, not here, but elsewhere.
What I’ve found is that the double-diamond is a helpful model for talking about all the design should be helping influence within a product development life cycle. With leadership you can start doing these things in a way that can be hard without leadership.
The key is making sure that design and your design leader is involved, not just in execution, which is on the right side, but in definition, in developing the strategy and plan, making sure that you’re building this thing right, as well as execution, working through trade-offs to deliver your optimal solution.
And building the right thing, and then building the thing right. There’s a lot more to it. The core idea behind the double-diamond, if you’re not familiar with it is you go broad. You diverge as you’re starting to think about a problem, and then you converge and you hit on a plan.
Once you have the plan, you still diverge again to explore ways that you can solve that plan, and you converge. Too often, whatever that first idea is, we ram it through. I’m sure folks in here know if you’ve ever sat down and been part of some sketching concept generation exercise.
Your first idea is usually the worst one, because it’s the most obvious. It’s the 5th, the 6th, the 10th, the 15th idea where you’re doing something interesting. That’s why it’s important to make sure you give yourself that time to diverge.
How it ends up playing out is, you’ve got one big definition phase, and then you do a lot of execution based on that. You’re not going to do definition and execution back and forth. That would be psychotic. Usually what happens is, once you have that plan.
That plan is some form of a roadmap, things you’re going to try to do, and you’re now delivering on that roadmap bit, by bit, by bit. That said, it’s better to iterate here, in the ideation and prototyping part of definition, than here.
Which sets me apart from at least what is perceived wisdom around things like Lean user experience. It’s cheaper. It’s simpler. You’re sketching, and you’re coming up with ideas, and you’re playing. It’s not nearly the investment it is. Once you ship it, it’s an investment.
Frankly, they’ll say MVP. MVP is usually only product because you got it out and then you’re moving on to the next thing. It’s rare, in my experience, that people continue to iterate, unless something’s obviously broken or buggy. As long as it barely works, they’re like, “Great. Move on.”
I saw that at Groupon. I saw it at Jawbone. I saw it anywhere. If you can talk to anyone, that is sadly the truth. It’d be better to measure twice before you cut once. That’s what we’re saying there. It doesn’t seem very Lean or Agile. I tend to be wary of people with espousing methodologies.
They tend to be crutches for critical thinking on your own. Please don’t use them to make your own case, “Oh, but I read a book called ‘Agile Means UX Things,’ and it said to do this, and so I am right.” That means you’ve stopped thinking and you’re parroting.
You need to figure out what’s going to work in your environment. There’s stuff to brew from those models, but you need to make sure that you are interrogating them, you are questioning them. You are making sure that they are relevant to you before simply executing against them.
I don’t think that happens too much. Also, being Agile, most of the literature out there is about execution. It’s not about definition. Those communities aren’t that interested, from what I can tell. I’m sure someone will correct me.
In that definitional phase it tends to be like, “Let’s get this out there. Let’s let the market help us understand.” I understand you don’t want to spend a lot of time staring at your naval, wasting a lot of money before you ship something.
And so you have to manage that definition phase appropriately, so that you’re not just spinning. But, it is worth doing because even though it might take longer to get the first release, my experience in this belief is that it is shorter to get to the right release.
Whereas, if you launch too early and then try to iterate your way to something good, it ends up taking longer to get to the right release than if you had done a little bit of that thinking up front.
Something else happens. You’re moving on from process, no segue ways, dive right in. Something else happens when you’re in this centralized partnership model, and one of the challenges is every one of these product teams needs design.
They have been told that they can have design, but they don’t have control. They don’t have their own designer. They’re coming to me, or the design team, and saying, “Hey, we need design,” and my responsibility is figuring out how to make sure they all get design.
That’s hard. The biggest challenge with centralized partnership is maintaining that commitment back to the rest of the org. When you have taken away a bit of authority from them by, “You’re not allowed to hire your own designers,” you have to return.
“OK, we’re going to help you figure out how to solve your design problem.” These are the challenges that you need to figure out how to deal with when working with these partner teams. The partner teams don’t end up understanding the cost to design. It’s not a headcount that they’ve had to worry about.
There’s no buyback model that they’re dealing with. They’re told, “I was going to get design.” They don’t understand that it’s not that simple and that they have to help us hire, or whatever it is, to help solve their problem. It’s something that I spend a lot of time trying to bring them along in that way.
They don’t have control over their own destiny, and that makes them nervous, and rightfully so. The centralized partnership model does require more coordination and communication than perhaps a decentralized and embedded model in order to make sure it’s all going to be OK. That is a trade-off.
It’s an acceptable one given the benefits of it. It does become, especially if you’re the leader of that organization, what you’re spending much of your time doing is coordinating and communicating, as opposed to creative leadership.
That leads to the next challenge that I had at least, specifically, at Groupon, which is I was able to grow a team from about 30 to about 60, and I was still the single leader. As there were more people, there was more coordination and communication.
And I couldn’t be both a creative leader and an operational leader. That’s getting really challenging to manage both. This is a current shortcoming in how many organizations think about design. They want one person to do both, what they want.
So after I left Groupon and I talked to a lot of companies, they want a creative director. They want the creative leader. Most companies don’t understand the importance of how you organize design. Regardless, having one person do both gets hard, and unlike other parts of the org.
In tech it’s pretty common as you grow an engineering team to have a CTO, who’s the creative leader of the technology team, thinking about systems architecture and what technologies they’re going to use, and a VP of engineering who is making that thing go.
You separate the creative leadership and operational leadership. In journalism you have an editor and chief who holds the vision and the managing editor who’s whipping people until they turn in their copy.
Design doesn’t have those functions identified. There’s one exception that I’m aware of which is at Twitter. Kevin Chang mentioned it in his talk earlier. Doug Bowman, who is the creative director at Twitter, loathed the idea of managing people.
And to his credit, recognized he would be bad at it, and it would be a problem if he was expected to do it. So Twitter hired a VP of design. That VP was more operational and organizational, and Doug was able to remain more focused on the creative aspect.
This is something we need to think about as we start having these design orgs scale, is you have to figure out as the leader of that org what are you wanting to do, and if you’re leaning towards one or the other, making sure that you’re able to balance that and have that complimentary skill set around.
Something else I learned, particularly at Groupon, starts with this picture here. That’s Marieth. He’s a designer at Groupon, surrounded by developers who are hanging on his every word, waiting for him to tell them what the hell to do.
As he’s looking at me, he’s looking a little “deer in headlights,” a little shell-shocked, like, “What the fu-?” It’s because designers can keep a lot of people busy. A typical designer and developer ratio, in the past, has been one to 21, to 31, to 40.
So [inaudible 31:45] , it’s getting down to one to five, to one to 10, but still that’s way fewer designers than engineers. What’s interesting about that, at Groupon there were 500 to 600 people in the PMs and engineers of those products, and we had 60.
We had a one to ratio of designers to the other part of the org. Those 60 people include the marketing and brand designers who went spending most of their time focused on products. It’s probably greater than that.
You have relatively few designers engaging with a much larger group of other people, be it engineers or product managers. The insight that I had at Groupon is we’re going to go back to know to the beginning of this talk. Few centralized partnership, teams with strong leadership, your influencing definition.
And you have a relatively small team, you have leverage. What do I mean by that? Two stories, going back to Doug Bowman, I saw him shortly after I joined Groupon. Twitter moved to a fabulous new space. All the designers sat together in essentially a design studio.
One of the by-products of this, this wasn’t intentional, is that when their CEO, Dick, wanted to find out what was going on in the company throughout the entire company at least in terms of what they were delivering from a product standpoint. You could go to one room in his building and look around.
He could see the entirety of Twitter. There’s thousand engineers somewhere else but their 40 designers, that’s this lens that allows him to understand everything that’s going on. Before I left Groupon, I instituted a monthly design share-out that was somewhat similar.
We were much more distributive company so we couldn’t do it all in one team. It was a one-hour presentation every month to the leadership. Product managers and marketing, et cetera., and use all the stuff designers working on. 120 slides in 60 minutes go bam, bam, bam.
I got feedback after the first one from our CEO that that was the most important meeting at the company. Again, in no other way, no other form, are you able to see the totality of an enterprise distilled as you can through design. That’s leverage. Leverage equals power, Archimedes taught us that.
Design, this is another reason to have strong design leadership. With strong design leadership, design, thanks to its leverage, can start pushing back into the organization. Instead of simply being the recipients of requirements and specifications.
You can now push back and help determine the plan, those definitions and make the organizations you’re working with much more friendly to delivering better user experiences.
In order to do that, designers tend to be pleasers. Designers tend to be folks who want to help those around them and often will suddenly make their own desires for the sake of serving what they have received as a great organizational good.
Designers need to be a little less nice and a little more determined in their perspectives and viewpoints and be clear that there’s stuff that we have to offer and that we have a point of view that will help out and continue to push that back.
With the leverage, there’s a lot of opportunity to do that. One more thing, this is my last thought before I break. I talked about the decentralizing embedded model. Decentralizing embedded model is structured around these product or feature teams.
Centralized partnership also still as you see serving these product teams. As we know about the evolution of categories in tech, in new technical categories in the world, new product categories, they tend to go through this evolution.
You start with technology. So that is a Nokia communicator, one of the first phones that could ever get on Internet and essentially the first connected smartphone. I never used one.
I have to imagine. It was probably not the best experience but that you could get on the Internet and send email was like, “Yes, please more.” You don’t expect too much at that stage of a product category’s evolution.
Then over time, as that becomes more typical and expected, you tend to get this feature raise. You get smartphones doing different things and they’re competing on parity and who does more features and more apps and more whatever’s. That becomes the determining factor.
You go through that transformation where experience starts to win out. The first iPhone had fewer features than a lot of other smartphones at the time but a more accessible experience and has become the template. There’s a before iPhone and after iPhone. Leave it at that.
If this is true and I believe it to be so, even this model, this centralized partnership model that I’m talking about is stuck in a feature’s world. It’s still allowing organizing for engineers to drive what it is that we’re creating. The reason…I didn’t talk about that.
The reason you have feature teams at this scale is that is the optimal number of engineers working together. That’s important. They’re responsible for delivery. You scope problems to suit what makes sense for a team of four engineers to deliver, three to five engineers to deliver.
That tends to be smaller than if you were to scope problems for an equivalent team of designers. My last project at Adaptive Path was a newcomer’s project. We had a design team that looked roughly like this. I was lead, a couple of senior designers and some other designers working on their project.
There were five of us, maybe not six. Did an e-commerce project and not only did we deliver on search, browse product, UGC personalization checkout, we also created a whole shopping experience and involved gifting and merchandizing and sharing and social and wish list.
And install pickups and style guides which in the model that I showed before, each of those and in fact at Groupon, they had feature teams that were dedicated to those. Five, six designers can create a really rich experience but they’re being constrained by that old model of delivering on features.
A model that is designed to support what makes sense in terms of organizing engineers and not organizing designers. I don’t have a solution to this. I’m going to say that right now.
I recognize that if a design team is delivering all these greatness in terms of this experience but you don’t have an engineering capability deliver on it, what do you going to do?
There needs to be some balance there. I knew that we have to poke and probe and challenge this prevailing model of product teams and feature teams that are organized to serve what a group of engineers can deliver on as opposed to what a group of designers can deliver on.
As we mature within this field and this industry, if we are going to realize all the benefit that we can deliver, we’re going to need to figure how to crack that nut. I don’t have the answer to that. If someone in the audience does, that would be awesome. With that, thank you for your consideration.
Peter: It is exactly 12. I didn’t even know. I’m that good.
Peter: I’m happy to stick around if folks want stick around for Q&A. Lunch is at 12:15 upstairs. I’m not going upstairs for lunch. I’m going around the corner to a Vietnamese restaurant, that’s supposed to be pretty good. If you want to stick around for a little bit and do Q&A, I’m happy to do it like this.
If you need to go, go but we have microphones. There’s nothing happening right after this. We can hang out here for a little bit longer. Did you want to add anything to that, Emily?
Emily: Is there anyone who’d like to ask a question?
Audience Member: I appreciate the talk. Loved all the points you made around what we can do especially in the beginning stage, that design. First, it’s cheaper to do it on paper with pencils than it is after you start building it.
My question for you is can you describe a little more this leadership position, the strong leader that was able to play up and down both sides? You describe them as a spread of skills, strategy planning, research interaction design, IA visual design prototyping. That’s a great list. Can you share a little bit about…?
Peter: I’m trying to pull up that…
Audience Member: …profile. Where did you find them? What experience did they have?
Peter: There we go.
Audience Member: Expand on that a little?
Peter: Yeah, happy to. The design leaders can come from different backgrounds. At Groupon, we had people with visual design backgrounds who, through their career development, learned not only work well with interaction designers and user researchers but could lead them.
If I look at my own experience, my background is one of information architecture interaction design. Over time at Adaptive Path, I was leading visual design, I was leading research.
A model that I have talked about before is one of film directing. Film directors come from many number of backgrounds. They could be actors, they could be writers, editors, cinematographers. They have learned how to help coordinate a set of craftspeople toward a common goal.
That’s the responsibility of these folks. Regardless of where they came from, they have, through their work, learned how to establish a vision for what it is their team is doing and help their team realize that vision and work and know how to lead different disciplines towards that common goal.
Where do you find them? One of the things that I am fortunate of in having been in this field as long as I have is they’re my friends, they’re my network or if they’re not directly my friends, they’re friends of friends. I could bang on a lot of pipes often through LinkedIn and these folks can turn up.
I have a benefit that others don’t in that regard. You’re looking for someone probably more than 10 years experience, being in a couple of interesting position situations, and who you feel can do those three things. It’s not just the managing down part in terms of delivery, it’s that managing across.
If this person is hired well, it’s the reason that design is going to have the influence it can have. One of my design managers in Chicago at Groupon started becoming a product manager and was treated as such because he was so good at coordinating all those details and the product manager wasn’t.
Design was driving product literally in that instance. This gets to a whole other thing where I won’t get into how senior UX leadership and strategy as really product management, but it is. That’s what he was.
He is a hard-core old school UXer who turns out when you’re one of those, you can be a product manager instantaneously. Does that answer your question?
Audience Member: [off-mic question]
Peter: No. [laughs]
Audience Member: Hi. I work in an organization where there are two UX designers over nine development teams. They don’t…
Peter: That ratio sucks.
Audience Member: Very. They don’t have strong UX foundation or understanding of UX.
Peter: The UX designers or the whole org or…?
Audience Member: The organization. We do but they don’t. I’m trying to get them to incorporate more collaboration, more testing in UX principles, but yet still their approach to development is get it fast and get it done.
How do I go in and try to get them to allow me to do my job as a UX designer better instead of being a user interface designer?
Peter: I’m probably not the best person to answer this question because I’ve been afforded the luxury of being in places that did respect user experience whether it’s Adaptive Path and their clients that they came to me was because they understood it already.
Or anyone who would hire me but hopefully, those that they’re getting into. I’m not a very private person. I would encourage you to seek others who probably have better stories. From what I have experienced.
What I would say is the key to getting an organization to rock the value of what it is your team is trying to deliver is get them seeing people using their stuff. You have ton of usability. Get on usertesting.com, five-minute, 10-minute test, get 50 of them in a day.
Sit their asses their down in front of a screen and have them yell at the monitor as they’re realizing no one understands what it is that they are building.
That seems to be the wedge, the best lever into it. If that doesn’t work, you’re working with robots who might not be saveable and you might need to move on. Also, not just those, engineers’ leadership too.
If the engineers don’t get a leadership probably well, if for whatever reason the products and services you’re working on aren’t delivering, that should concern the people in charge.
You need to figure out how you demonstrate that the reason they’re not delivering or not delivering as well as they could is because there are these user experience findings. That research is going to be, again, your best wedge in.
Others at this conference, and I encourage you to seek them out. Who are you? Felicia. If anyone has good stories of turning an organization around with this…
Audience Member: [off-mic comment]
Peter: Lorelie in the back would love to tell you about that. Again, I haven’t had that experience directly.
Audience Member: Hi. Thanks for the awesome talk. A lot of what you were talking about was about designers to developers and the structure around that. I’m really curious about the marketing designers and how that works. It came from marketing or it came into UX and it’s a different set of challenges.
How do you work with the marketing department?
Peter: Similarly but differently with the way we work with products. With product designers, you’re really committing them to parts of that experience. That happens…Two ways to answer it. Marketing designers at Groupon still operated in that short order cook model.
It’s harder to get them out of that because, again, I mentioned turnaround of the work they’re doing.
One thing I was doing though is bringing marketing designers into conversations that would have otherwise been considered simply product design conversations, i.e. anyone touching the consumer met once a week.
That included marketing designers, communications designers, as well as the product designers. We would share the work that the marketing and communication designers are doing and we would share product designers and they would talk back and forth. They realize there are things to share with each other.
Something I also realized is that, my marketing/communication designers often have better visual design skills than my product designers. The product designers were often [inaudible 46:14] who didn’t respect marketing design and didn’t understand that they could learn from anyone else.
That was something I had to do, is try to help them understand like, “No, these people have skills that will make your stuff better.” It’s that work to continue to bring it together. Also, what would happen is.
Oftentimes, we wouldn’t have enough product designers to deliver on what the organization was trying to execute on. We would have especially the younger marketing designers often had some digital skill because they’re young and you can’t not.
I would start pulling them into product stuff to make sure that there was leadership to help see them through, but they were execute on product experience. That’s the other thing that is important about keeping them together, is I want to be able to prioritize marketing needs and product needs.
If product has a higher priority than marketing right now, I would have taken designer out of marketing and have them work on that product problem. If there’s a wall where I don’t even know what it is they’re working on or how they’re prioritizing, I can’t make that decision.
It was hard and sloppy and that’s a problem I haven’t solved well. I had some success in finding ways to integrate them.
Audience Member: Thanks again for the amazing talk. I had several experiences that match what you’re saying about separation of features and such like that. One of my best experiences was working with the design team as a developer.
And then translating that information to the rest of the development team. That was a long ago. Going forward in the future or recent path I should say, my question is this. You present this idea of how a design team that could come together.
And pump out a whole bunch of awesome features and ideas and get it all together. I know you said you don’t have an answer for this, but I’m wondering what the level of conversations you’ve had with say development teams who are often siloed in the features.
In my personal experience, it makes sense that a logical view of dividing things into features but even functionally in multi-year projects, things fall apart regardless because people don’t understand what the features are.
They come up with new ideas. Really, I love this guidance through the UX. I would love to try and have that conversation with you about how to help this from the development point of view. I’m wondering what conversations you’ve had there.
Peter: Not a lot honestly. Those conversations for better or worse, one of the things that I’ve seen happen is that engineering tends to be treated as plumbing. Even VPs of engineering, their job is to make the plumbing go. It’s like structural engineering and architecture.
They’re not there, but the big ideas [inaudible 48:42] out there. They’re there to execute on it. One of the challenges though at least in the organizations I’ve been in is finding engineers who are wanting to contribute. A lot of engineers like to be told what to do and execute against.
That might be a generalization, but I see that a lot. Give me the specs, give me the wires, give me the thing and let me build. I don’t know enough about engineering management and engineering hiring to understand the challenges in getting an equivalent engineering leader.
Like the design leader who has that, the crossness and is seen as a contributor. What happens is, the designer and the product manager, what will it take to build this thing as opposed to what do you think we should build and let’s come up with this together.
The engineering voice in that is usually estimating delivery times. I don’t have a good answer but that’s when I was alluding to. There’s a broader cross-functional problem that this isn’t quite addressing yet. I’m trying to stick to my [inaudible 49:40] .
Which is the design org because that’s the thing that I’m hired to fix or address, and I’m developing a model for that. The next step is like, “OK, how does this really integrate into this bigger, heavier, messier structure which I don’t have nearly as much direct control over to make it work best?”
At my job, we have this little cross-functional project team council in part to try to solve that. One of the keys is making sure, this is hard, making sure there is product leadership, design leadership, and engineering leadership before you start anything.
That commitment itself has proven really difficult because you don’t have enough engineers. You don’t have enough designers. You don’t want to wait until you hire the right people. There’s challenges there.
One model that we’ve been looking at this cross-functional council has been looking at, and drawn some inspiration from Spotify has written a ton on how they’ve organized. There’s a lot of good stuff about agile product development.
If any of you have ever used Spotify, you know that it is not a coherent, cohesive experience. They tend to get very feature-oriented. To their credit, they’ve written a lot of good stuff. There’s models there that we have been able to draw from, recognizing that we want take some and leave behind other stuff.
They’ve at least addressed this and being very thoughtful and rigorous in how they think about it. That would be something I would suggest pursuing this at a broader level. They tend to come at it from an engineering standpoint as opposed to a designer, even product standpoint. Do we have to go?
Emily: We do have to go. The LGBT lunch is right upstairs. I hope to see you there. Thanks again, Peter.
Peter: Thank you all.