by Jeff Gothelf
Collaborative design is an approach that allows a team to design together. It helps teams build a shared understanding of both the design problem and the solution. It provides the means for them to work together to decide which functionality and interface elements best implement the feature they want to create.
Collaborative design is still a designer-led activity. It’s the designer’s responsibility to not only call collaborative design meetings but to facilitate them, as well. Sometimes, you’ll have informal chats and sketching sessions. Sometimes, more structured one-on-one sessions with a developer at a whiteboard. Other times, you will gather the entire team for a Design Studio exercise. The key is to collaborate with a diverse group of team members.
In a typical collaborative design session, teams sketch together, critique the work as it emerges, and ultimately converge on a solution they feel has the greatest chance of success. The designer, while still producing designs, takes on the additional role of facilitator to lead the team through a series of exercises.
The output of these sessions typically consists of low-fidelity sketches and wireframes. This level of fidelity is important. First, it makes it possible for everyone to contribute, even team members with less sophisticated drawing skills. Second, it’s critical to maintaining the malleability of the work. This gives the team the ability to pivot quickly if their tests reveal that the approach isn’t working. It’s much easier to pivot from a failed approach if you haven’t spent too much time laboriously drawing, documenting, and detailing that approach.
Collaborative Design: The Informal Approach
A few years ago, Jeff was designing a dashboard for a web app targeted at TheLadders’ recruiter and employer audience. There was a lot of information to fit on one screen and he was struggling to make it all work. Instead of burning too much time at his desk pushing pixels, he grabbed a whiteboard and asked Greg, the lead developer, to join him. Jeff sketched his original idea about how to lay out all of the content and functionality for this dashboard (see Figure 4-2). The two of them then discussed the idea, and eventually Jeff handed Greg the marker. He sketched his ideas on the same whiteboard. They went back and forth, ultimately converging on a layout and flow that they felt was both usable and feasible, given that they needed to deliver a solution within the current two-week sprint. At the end of that two-hour session, they returned to their desks and began working. Jeff refined the sketch into a more formal wireframe and workflow while Greg began to write the infrastructure code necessary to get the data they needed to the presentation layer.
Figure 4-2. Examples of whiteboard sketches
They had built a shared understanding through their collaborative design session. They both knew what they were going to build and what the feature needed to do. They didn’t need to wait to document it. This allowed them to get the first version of this idea built within a two-week time frame.
Conversation: Your Most Powerful Tool
Lean UX promotes conversation as the primary means of communication among team members. In this way, it is very much in line with the Agile Manifesto that promotes “Individuals and interactions over processes and tools.” Conversation unites a team around a shared vision. It also brings insights from different disciplines to the project much earlier than a traditional design cycle would allow. As new ideas are formed or changes are made to the design, a team member’s insight can quickly challenge those changes in a way the designer alone wouldn’t have recognized.
By having these conversations early and often, the team is aware of everyone’s ideas and can get started on their own work earlier. If they know that the proposed solution requires a certain backend infrastructure, for example, the team’s engineers can get started on that work while the design is refined and finalized. Parallel paths for software development and design are the fastest route to reach an actual experience.
These conversations might seem awkward at first; after all, you’re breaking down time-tested walls between disciplines. As the conversation evolves, however, designers provide developers with input on the implementation of certain features, ensuring the proper evolution of their vision. These conversations promote transparency of process and progress. This transparency builds a common language and deeper bonds between team members. Teammates who trust one another are more motivated to work together to produce higher-quality work.
Find ways to have more conversations with your teammates, both work-related and not. Time spent cultivating social ties with your team—eating meals together, for example—can make work-related conversations easier, more honest, and more productive.
Collaborative Design: A More Structured Approach
When your team is comfortable collaborating, informal sessions like the one we’ve just described take place all the time. But sometimes, you are going to need to gather everyone for a formal working session. Design Studio is a popular way to do this.1
This method, born in the architecture world where it was called Design Charrette, is a way to bring a cross-functional team together to visualize potential solutions to a design problem. It breaks down organizational silos and creates a forum for your fellow teammates’ points of view. By putting designers, developers, subject matter experts, product managers, business analysts, and other competencies together in the same space focused on the same challenge, you create an outcome far greater than working in silos allows. It has another benefit. It begins to build the trust your team will need to move from these formal sessions to more frequent and informal collaborations.
Running a Design Studio
The technique described in the sections that follow is very specific; however, you should feel comfortable to run less or more formal Design Studios as your situation and timing warrants. The specifics of the ritual are not the point as much as the activity of solving problems with your colleagues and clients.
Setting
To run a Design Studio session, you’ll want to find a dedicated block of time within which you can bring the team together. You should plan on at least a three-hour block. You’ll want a room with tables that folks can gather around. The room should have good wall space, so you can post the work in progress to the walls as you go.
The team
The process works best for a team of five to eight people. If you have more people, you can just create more teams and have the teams compare output at the end of the process. (Larger groups take a long time to get through the critique and feedback steps, so it’s important to split groups larger than about eight people into smaller teams who can each go through the following process in parallel, converging at the end.)
Process
Design Studio works within the following flow:
Problem definition and constraints
Individual idea generation (diverge)
Presentation and critique
Iterate and refine in pairs (emerge)
Team idea generation (converge)
Supplies
Here’s what you’ll need:
Pencils
Pens
Felt-tip markers or similar (multiple colors/thickness)
Highlighters (multiple colors)
Sketching templates (you can use preprinted one-up and six-up templates or you can use blank sheets of 11″ x 17″ [A3] paper divided into 6 boxes)
25″ x 30.5″ (A1) self-stick easel pads
Drafting dots (or any kind of small stickers)
Problem definition and constraints (15–45 minutes)
The first step in Design Studio is to ensure that everyone is aware of the problem you are trying to solve, the assumptions you’ve declared, the users you are serving, the hypotheses you’ve generated, and the constraints within which you are working. This can be a formal presentation with slides or it can be a group discussion.
Individual idea generation (10 minutes)
You’ll be working individually in this step. Give each member of the team a six-up template,
which is a sheet of paper with six empty boxes on it, as depicted in Figure 4-3. You can make one by folding a blank sheet of 11″ x 17″ paper or make a preprinted template to hand to participants. (Some teams like to hand out small individual whiteboards to each participant. These are great because they’re easy to erase and tend to make people feel relaxed.)
Figure 4-3. A blank “six-up” template
Sometimes, people find they have hard time facing a blank page. If that’s the case, try this optional step. Ask everyone to label each box on their sheets with one of your personas and the specific pain point or problem they will be addressing for that persona. Write the persona’s name and pain point at the top of each of the six boxes. You can write the same persona/pain point pair as many times as you have solutions for that problem or you can write a different persona/pain point combination for each box. Any combination works. Spend five minutes doing this.
Next, with your six-up sheets in front of you, give everyone five minutes to generate six, low-fidelity sketches of solutions (see Figure 4-4 and Figure 4-7) for each persona/problem pair on their six-up sheet. These should be visual articulations (UI sketches, workflows, diagrams, etc.) and not written words. Encourage your team by revealing the dirty secret of interaction design to level the playing field: If you can draw a circle, square, and a triangle, you can draw every interface. We’re confident everyone on your team can draw those shapes.
Figure 4-4. A wall full of completed six-up drawings
Presentation and critique (3 minutes per person)
When time is up, share and critique what you’ve done so far. Going around the table, give the participants three minutes to hold up their sketches and present them to the team (Figure 4-5). Presenters should explicitly state who they were solving a problem for (in other words, what persona) and which pain point they were addressing, and then explain the sketch. Each member of the team should provide critique and feedback to the presenter. Team members should focus their feedback on clarifying the presenter’s intentions.
Giving good feedback is an art: In general, it’s better to ask questions than to share opinions. Questions help the team talk about what they’re doing, and help individuals think through their work. Opinions, on the other hand, can stop the conversation, inhibit collaboration, and put people on the defensive. So, when you’re providing critique, try to use questions like, “How does this feature address the persona’s specific problem?” Or, “I don’t understand that part of the drawing. Can you elaborate?” Questions like these are very helpful. Comments such as, “I don’t like that concept,” provide little value and don’t give the presenter concrete ideas to use for iterating.
Figure 4-5. A team presenting and critiquing drawings during a Design Studio
Make sure that every team member presents and receives critique.
Pair up to iterate and refine (10 minutes)
Now ask everyone to pair up for the next round. (If two people at the table had similar ideas, it’s a good idea to ask them to work together.) Each pair will be working to revise their design ideas (Figure 4-6). The goal here is to pick the ideas that have the most merit and develop a more evolved, more integrated version of those ideas. Each pair will have to make some decisions about what to keep, what to change, and what to throw away. Resist the temptation here to create quick agreement by getting more general or abstract. In this step, you need to make some decisions and get more specific. Have each pair produce a single drawing on an 11″ x 17″ (A3) six-up sheet. Give each team 10 minutes for this step.
When the time is up, ask the team to go through the present-and-critique process again.
Figure 4-6. A team working together in a Design Studio exercise
Team idea generation (45 minutes)
Now that all team members have feedback on their individual ideas and people have paired up to develop ideas further, the team must converge on one idea. In this step, the team is trying to select the ideas they feel have the best chance for success. This set of ideas will serve as the basis for the next step in the Lean UX process: creating an MVP and running experiments (both covered in the next chapter).
Ask the team to use a large sheet of self-stick easel pad paper or a whiteboard to sketch the components and workflow for their idea. There will be a lot of compromise and wrangling at this stage, and to get to consensus, the team will need to prioritize and pare back features. Encourage the team to create a “parking lot” for good ideas that don’t make the cut. This will make it easier to let go of ideas. Again, it’s important to make decisions here: resist the temptation to get consensus by generalizing or deferring decisions.
(If you have split a large group into multiple teams in the Design Studio, ask each team to present their final idea to the room when they are finished for one final round of critique and feedback, and if desired, convergence.)
Using the output
Before you break, decide on next steps. You can use the designs you’ve created in this process as the basis for building MVPs, for running experiments, for production design and development—the process is very versatile. Just ensure that, having asked people to spend a lot of time contributing to the final design, you treat their contribution with respect. Decide together on next steps and then stay on top of the progress so that people keep their commitments and follow through.
To keep the output visible, post it on a design wall or another prominent place so that the team can refer back to it. Decide on what (if any) intermediate drawings people want to keep and display these alongside the final drawing, again so that team members can refer back to the ideas. Regardless of what you keep posted on the wall, it’s generally a good idea to photograph everything and keep it in an archive folder of some sort. You never know when you’ll want to go back to find something. It’s also a good idea to put a single person in charge of creating this archive. Creating some accountability will tend to ensure that the team keeps good records.
Figure 4-7. Output of a Design Studio session
Design Systems
So far in this chapter, we’ve focused on the ways that teams can design together. In practice, this usually means that teams are sketching together, either on paper or at a whiteboard. It almost never means that teams are sitting together at a workstation moving pixels around. In fact, this kind of group hovering at the pixel level is what most designers would consider their worst nightmare. (To be clear: don’t do this.)
And yet, design isn’t done when the sketch is done. It’s not completed at the whiteboard. Instead, it’s usually just getting started. So how do we get design to the pixel level? How do we get to finished visual design?
Increasingly, we’re seeing teams turn to design systems. Design systems are like style guides on steroids. They were an emerging species when we completed the first edition of this book but have now become an accepted best practice for digital product teams. Large organizations like Westpac (see Figure 4-8) and GE use them. Technology-native companies like MailChimp and Medium and Salesforce and countless others use them, too. Even the US Federal Government has released a design system. There are even entire two-day conferences dedicated to them. But, before we get into why design systems are having their moment, let’s talk about what they are.
Figure 4-8. The GEL design system website from Westpac
Design Systems: What’s in a Name?
Style guides. Pattern libraries. Brand guidelines. Asset libraries. There’s not a lot of common language in this part of the design world, so let’s take a moment to clarify our terms.
For years, large organizations created brand guidelines—comprehensive documents of brand design and usage rules for those companies. In predigital days, these guidelines were documents, sometimes a few pages, but frequently large, comprehensive bound volumes. As the world moved online, these books sometimes moved onto the Web as PDF documents, web pages, or even wikis.
At the same time, publishers and publications often maintained style guides that co
vered rules of writing and content presentation. College students in the United States are familiar with the comforting strictness of The Chicago Manual of Style, The MLA Style Manual and Guide to Scholarly Publishing, and others.
The computing world’s version of a style guide is exemplified by Apple’s famous Human Interface Guidelines (HIG). The HIG is a comprehensive document that explains every component in Apple’s operating system, provides rules for using the components, and contains examples that demonstrate proper use of the components.
