Episode #219 Adam Connor - Design Studio: Building Consensus Early in Your Design Process
Getting two people to agree on something is a difficult task in any aspect of life. Getting a whole team to agree on a design, where underlying feelings, ownership, and organizational hierarchy are involved, can be an even greater challenge. That’s not even counting the dreaded “swoop and poop” scenario. The trick is to get everyone involved early in the design process and a design studio is a perfect tool for just that.
Adam Connor of Mad*Pow deals a lot with critique sessions and design studios. Adam knows the value of getting the entire team and stakeholders together in a collaborative environment to sketch and share ideas. In his virtual seminar Design Studio: Building Consensus Early in Your Design Process, Adam outlined his process for running a studio and offer tips to aid in gaining consensus.
A bunch of great questions were asked during the live seminar and in this podcast Adam joins Adam Churchill of UIE to address some of them including,
- How do you run a design studio with remote members of a team?
- What’s the appropriate structure of a studio, time-wise, to make it worthwhile?
- Who do you involve in a studio?
- Is the facilitator someone on the design team, and are they actively involved in the studio?
- How do you manage difficult participants?
In addition to his virtual seminar, check out Adam’s daylong workshop from the User Interface 18 conference, now in our All You Can Learn Library.
Adam Churchill: Hello, everyone. Welcome to another edition of the SpoolCast. Just a few weeks ago, Adam Connor came to our studios to present his virtual seminar on design studio.
Adam's seminar, along with over 100 others that teach the tools and techniques you need to create great user experiences, is now part of the UIE User Experience Training Library and soon to be unveiled as part of what we're calling "UIE's All You Can Learn."
In the seminar, Adam shows us how to avoid what design reviews have become. They're things that can result in conflicting lists of stakeholder feedback and out-of-scope ideas about what the design should be. Other outcomes are bruised egos, longer timelines, higher budgets. They're often par for the course.
Adam Connor joined us, and he shared a better way. Adam builds design consensus naturally by running what's called a "design studio," which structures team brainstorming early in the process, then uses sketching, presentation, and critique activities to get everyone involved in moving towards this shared vision.
If you employed the techniques he shares, before long, you're running faster among a team of happy people and best of all, building better products. Adam's back to talk a bit more about what he discussed and tackle some of the questions that came up.
Hello, sir. Thanks for coming back.
Adam Connor: Thanks for having me.
Adam Churchill: So, Adam, for those who weren't with us during your virtual seminar, can you give us an overview of what you talked about?
Adam Connor: Absolutely. As you pointed out, there can be a lot of challenges that arise during a project with regards to design reviews and also just the conversations that take place throughout the project.
It can take a while to get everybody on board with the ideas you're going to pursue and which ones you're not going to pursue. Ideally, you're coming up with a lot of ideas for your solutions.
There can also be this feeling that the team can't make decisions. The users have to point everybody in the right direction. While user research is hugely valuable, at times, you're going to have so many ideas that going out and putting all of them in front of users, it just isn't feasible.
You can also run into challenges with the swoop and poop scenario where you and your team have managed to build some consensus. You've got a design. You're ready to go. You just need that one last stakeholder to look at it and give the stamp approval. You put it in front of them and all of a sudden, they're shitting all over everything.
They want to know why you didn't design it the way that it's in their head and what went into these decisions. This isn't everything we need. We need these other things instead. This isn't what I was thinking it was going to be like.
That can seriously derail your progress and demotivate your team and can cause all sorts of issues for your project going forward. We worked to employ this design studio method as an activity that we use early in the process that we bring all members of a team into.
We involved stakeholders, developers, marketers, subject matter experts, whoever we have on the team. We want to bring them all in. We share our ideas. We share our ideas for the design through a process of sketching those ideas, then presenting them to each other, and then critiquing them.
Critique is a major component in the studio process because critique allows us to analyze the validity of ideas against the objectives that we have for the project. Before we get to this brainstorming part of the effort, we start off with research.
We use that research to frame the problem that we're going to solve. We do that by creating personas, by outlining scenarios that we're going to design for, by establishing design principles, and project goals.
We use those four things in our design studio in the critiques to frame our conversations around the ideas that we have and make sure that the ideas that we're coming up with are solving the right problems.
That they're solving the problems in the way we want to, according to the principles and the scenarios that we've outlined. That they're solving them for the right people and align with those users behaviors, based on the personas that we've captured.
Through doing this in a workshop, we can build some consensus very quickly around where the solutions for our problems lie in terms of how something should be designed. Starting off on that foot will make the rest of the project feel much, much smoother, if we have that consensus in the beginning.
Adam Churchill: There were a lot of people that had questions about where there teams are dispersed. People buy into the practice but are worried about how they involve the important members of their design team because they're spread out in different locations, in some cases, across the globe. How do you get your hands around that?
Adam Connor: Yeah, telecommuting, remote working is getting to be bigger and bigger by the day. I myself, am a telecommuter. My company has offices in Portsmouth and Boston, but I live on the other side of Massachusetts. The remote situation is something I'm very familiar with.
In the seminar, I mentioned that in some remote situations, you might not want to use a studio. That's true, but let's talk about all the ways that you can still do a studio with remote individuals and what some of those factors that might make you want to do something different are.
First off, when you're dealing with remote people, you need to think about how many people are remote versus colocated. You have to get an understanding of who is where. Is it that everybody is colocated except for one person? Is everybody remote?
Do you have people spread out kind of according to departments within your organization? I know a lot of times, this is something we run into where the entire development division is off in one office in one state and all the marketers are in another state and maybe the designers were in a completely different office. Get a good sense of who is where.
From there, you can start to think about, if you were going to do this, how would you create your teams? As I mentioned in the webinar, this is a team-based activity and you want your teams to be balanced, according to the disciplines, the subject matter expertise that you have involved.
You don't want all your developers on the same team. You don't want all your designers on the same team. You want to mix your teams so that each one is kind of like a mini-organization.
Now, that's going to present challenges because all your developers are in one place, or all of another division is in another place. This is when you have to start thinking about, can I possibly bring people in to be present physically? Or if I'm going to continue remotely, maybe we need to treat everybody as if they're remote rather than relying on the co-location.
Get a sense of who's where, figure out what kind of impacts that's going to have on building your teams. Then you can start to decide, OK, now, if everybody's remote, we're going to build our teams in a certain way. I've got these three people and these three people and these three people.
Now, each remote team can function on their own as long as you have a really good facilitator on that team. Each remote team can work on their scenario, come back at a certain point to share with the other teams.
It can be fairly simple, you're basically doing the same thing that you would in a live studio, but you're doing it over an Internet connection. You can use things like, the IPEVO document camera is great for sharing sketches across people who are remote. You want to use your screen share technology like Google Hangouts or Skype or Webex, whatever it is you guys use.
You want to build in additional time. In the webinar, I talked about the timing that I typically use for an in-person studio.
In a remote situation, you want to allow for additional time, because getting points across when you're not physically in front of each other can be a little bit harder. Because you have to make sure that you're talking about the same thing on the sketch that maybe you're referencing. It can be a little bit harder to point to it, to point to a specific element that you're talking about.
In person, we tend to use red and green markers to circle and highlight things that aren't working or are working. It can take a little bit more time to coordinate that.
Also, if you have some people that are colocated and some people that are remote, in critiques, what you'll find will happen is that the remote person will kind of just sit quiet, waiting for an opportunity to talk. It never comes up because all the people who are in person just keep talking because they can visually see when someone's going to trail off in their sentence and they'll pick up the conversation from there.
You have to have a little bit more facilitation in terms of making sure that those remote folks have had a chance to share what they're thinking, that someone is facilitating those conversations to make sure all this is happening.
You can do remote studios, you just need to be a little bit more careful around how you're going to arrange things and possibly expand your time.
Adam Churchill: Yeah, we've had a little bit of success with that here at our end. We've run a few design studios. Jared's the big fan of us sketching, grabbing a white board and making sure that we're communicating our design ideas through that medium.
We actually were able to use an IPEVO camera and have one of our designers join us remotely. The part that we screwed up, though, is we tried to jam it into three hours. It just wasn't enough.
What's the structure fit into, realistically? People that are saying, I like this idea, but time and constraints and resources, it's just an issue. What's the magic number in terms of time?
Adam Connor: For a single persona and scenario, I usually use three hours as a ballpark estimate of what it's going to take. The problem is that one scenario, unless you're maybe focusing on one piece of functionality in a larger project that's ongoing -- maybe you're taking more of an Agile methodology to your work, or maybe you've just got a very, very hyper-focused product -- one scenario doesn't cover a lot of ground.
My guess is what you guys were doing, you guys were probably tackling a couple different pieces of functionality, or a couple different scenarios and trying to do that within the three hours. That really can go all over the place because you can't focus enough in that three hours, on any one thing.
Typically, in a studio, we'll probably do two to three scenarios in order to make sure that we've got enough of the core pieces figured out to build and expand upon for our entire concept. A day is a typical studio for us. We'll do an entire day, maybe a day and a half, tops. After a day and a half, people are just mentally drained, so we try to cap it at that.
Adam Churchill: Talk a little bit about who's involved in terms of the roles you have in the room. How many people should be involved for a successful design studio?
Adam Connor: Studio, if you think about just the general structure of it -- sketch, presenting, and critique -- following this idea of divergent to convergent thinking. Initially in your first charette, your first iteration, you're generating a lot of ideas. Then you're critiquing those, you're refining a few, critiquing those, and eventually boiling down to either a very small handful or just one.
You can do that with any team size. You can do that alone, if you need to, if you are that UX team of one. Don't worry so much about team size, in general. Think about what you're comfortable with. My personal preference, when I'm doing this with a team, is in the 6 to 12 person range. I've done this with up to 20 people.
After 20 people, in my experience, it can start to get a little difficult. All that means is that you might have to bring more people in to act as facilitators and help manage the workshop. There is no limit, but I would say find what you're comfortable with.
We have done studios before where we've had a team that is so large that we wanted to make sure everybody got a chance to bring their opinion in and their ideas in that we actually did multiple studios. The one I'm thinking of, I think we had upwards of 40-something people.
At that point, we were really just concerned about one thing, so we did three half-day studios. That way we were able to get everybody's ideas, watch how those ideas evolved over one set of iterations. Then after those three half days, we convened the core team to then look at those ideas that everybody had, discuss the similarities, discuss the differences and move from there.
You can find ways to do this within larger groups. You can find ways to do this within small groups -- if it's just you and one other person, you can treat each person as their own team. Or maybe you just do one team and it's just you and the other individual working together.
There really isn't a limit. The thing to keep in mind, though, is that more people means more time. Everybody needs a chance to present their ideas and receive feedback on their ideas.
More people equals more time and more people means more hands-on facilitation. As you get into higher numbers, you'll need to make sure facilitators are stepping up their game. You may need additional facilitators as you go.
Adam Churchill: Let's talk about that role. You mentioned the facilitator a couple of times. Is it someone who's part of the design team? Regardless, is that person getting involved with the sketching and the charettes?
Adam Connor: You have some options here. I do think the facilitator should always be a member of the design team. Really, there are two kinds of facilitators involved in this workshop. The first is the master facilitator. They're the ones who are leading the whole workshop.
They're kicking things off, reviewing the research findings with everybody at the beginning, presenting the personas and scenarios, and principles and goals, and all the things that you've done to frame the project. They introduce the activity and its logistics.
They're the ones who are assigning people to teams, telling people where to go sit in the room, reviewing the scenarios at the beginning of each set of charettes with people, making sure that the workshop stays on agenda. They're overseeing the whole thing. That person is very, very important.
Then, on each team, you want someone who can act as a facilitator, too. Each team is going to be working independently during periods of this workshop. Typically, what we'll put either a member of the design team on each team to act as that facilitator. If we don't have that many members of the design team that we can spare, we'll prep people from other areas within the project to act as that team facilitator.
That facilitator role, they're really there primarily as an observer. Because coming out of the workshop, what they're going to do, they're going to be part of that core team that reconvenes, takes all the concepts that came out of the workshop, and refines that into one.
They're there to see how ideas evolve, take note of the important things in the discussions and the designs, and also, to make sure that the critiques that are happening in each team are staying focused and staying on-topic.
If they start to observe that things are getting off track, people are getting too into problem-solving, people are talking about things that sound way more like personal opinion or maybe are about a scenario that that has nothing to do with what you're focused on -- their role is to guide that conversation back to a focused critique.
You've got those two facilitators. The team facilitator absolutely should be sketching and critiquing with their team. The master facilitator could also serve as a team facilitator if they feel comfortable. Sometimes we've had that master facilitator step aside and just be a facilitator for the workshop, and not do anything else.
Adam Churchill: In preparing for this podcast, you and I agreed that we were going to talk about some of the types of difficult participants that you run into. I know that I have a couple of thoughts in my mind.
You've got the person that's got an idea that their idea has got to be the way. Maybe another person you have in the room is someone who tries to take over or the facilitator. Why don't you tell us? What are the things that people listening in are most likely to run into and how do you handle them?
Adam Connor: You're going to run into quiet people, you're going to run into loud people, stubborn people. It's going to run the gamut. The most important thing to do is to first make sure that you've set the right expectation. Don't just rush out and call a meeting, bring everybody in, and then spring this on them.
Talk to your project team first about this workshop and what you want to do -- especially the stakeholders. You want to talk to them about what this workshop is and why you're doing it.
If you're doing it to address specific concerns, maybe you're in a project that's going all over the place right now and you'd like to reground it and bring it back, be honest with them. Explain that you're seeing these issues. Explain that you've got this workshop that you think could help and why you think it could help.
If you're trying this out for the first time, again, explain to them what you see the benefits of this workshop being, why you think it's valuable and how you're going to execute it. You want to make sure, at least at the stakeholder level, the critical project team member level, they know what it is you're doing.
They know that people are coming in with the expectation that they're going to sketch and share their ideas. The team is going to critique those ideas. Make sure that the things you're going to have them critique against -- those goals, those principals, whatever you've got -- that the stakeholder and leadership team are in line with those. You've got them talking about the right things.
Get that awareness and that agreement at that level first. That will save you a lot of headaches later on. As you get into the workshop you want to make sure that you don't just, again, throw everybody in this thing. You want to make sure you set aside time to explain the logistics of the activity to everyone.
Reground them in the fact that they're going to be sketching. Address any sketching concerns that people might have around they can't draw, or anything like that. There are lots of expectation-setting.
Now, once you're actually doing the charettes, you're actually sketching things. People you're going to be on the lookout for are very quiet people. Those quiet people are dangerous because chances are there is something in their heads that they're not sharing with you. It's not that they have nothing to say, it's that they have something that should be said, they're just not sharing it.
What will likely happen with those folks is they'll share it with someone, somewhere down the line -- maybe a week or two later -- and at that point, maybe it goes through some chain of people and finally makes its way back to you, at a point when it's really not useful. It can derail things. It can cause things to have to be rethought. It's not a great situation to be in, to find out things like that late in the game.
This is where your facilitator comes in. Whoever is facilitating that team, or observes this person being quiet, needs to be ready to ask for feedback directly. Ask about their ideas. Ask about their thoughts. Call them out on it, if you have to, "I see you rolling your eyes over there. I think you've got something to say. [laughs] What is it you're not telling us?" Call them out if you have to.
If they continue to do it, then you may need to pull them aside at a break and say, "Look, I'm really concerned about this. You're not talking. If there are things that you feel you're concerned about, or you have ideas about, and we bring them up later, we're not going to be able to work effectively with them. Now is the time to share them."
Don't be afraid to address people head-on. That's one of my running philosophies. Don't be afraid to address people head-on. Everybody is a grown-up here. We should all be able to talk to one another and address these concerns. That's the quiet person.
Then you're going to have the difficult person who is basically a Negative Nancy. It's like, "Oh, we can't do that because of this, and we can't do this because of that." They're going to find every excuse in the book as to why something shouldn't be done.
Again, it comes to facilitation. You're going to have to go back to any agreed upon principles or problem-framing. If you know that you've already agreed that you're not considering a certain limitation, a certain infrastructure-legacy system that you might have, you need to bring that to light.
You need to be prepared to address them head on. You need to be prepared to talk to the stakeholder about the fact that they might be causing issues. Again, don't be afraid to address them head-on.
Then to your point, Adam, there's that person who just takes over. They're railroading people. They're pushing their ideas. They're ignoring other people's ideas. Again, the facilitator is your first line of defense. Make sure the facilitator starts to try to take over that discussion, basically, and now is playing more of a hands-on role in guiding that critique.
It means that the critique will be less of an open discussion and more of the facilitator calling on people one by one. But it's very, very important because we need to make sure that everybody is getting their chance to speak. If you've got somebody who's speaking over everybody, then there's going to be a lot of people who don't get a chance to get their ideas out.
I can't emphasize the role of that facilitator and their importance enough. Facilitation is a very strong component, a very important component, of any workshop activity. You have to be prepared, not just to guide the conversation, but to really get in front of people and take over if you have to. If you don't feel comfortable doing that then you probably need to find somebody else who can play that role for you.
Adam Churchill: Very cool. A couple of important topics that you've been thinking about that you've done virtual seminars for us on, one is this concept of critique. It's not easy to do, and it's very important in the design process. Also this concept of a design studio, it's a great way to communicate design ideas and build consensus.
You and Aaron Irizarry are actually doing a full-day workshop on those topics at our UI18 Conference in Boston this Fall.
Adam Connor: Yeah, we're looking forward to it. We did it last year. It was great. People had a great time. We had some hands-on activities. It's a fairly active workshop, so it makes for a good, fun day, with lots of practical advice that people can use immediately, following the workshop.
Adam Churchill: I will look forward to seeing you then.
Adam Connor: Yeah, me, too.
Adam Churchill: Thanks for coming back and talking to everybody about the design studio process.
Adam Connor: Thanks for having me.
Adam Churchill: For everyone listening, thanks for your support of the UIE Virtual Seminar Program. Goodbye for now.