What follows is an excerpt from Chapter 4 (Collaborative Design) of Lean UX: Applying lean principles to improve user experience by Jeff Gothelf and Josh Seiden
The most effective way I’ve found to rally a team around a design direction is through collaboration. Over the long haul, collaboration yields bet- ter results than hero-based design (the practice of calling in a designer or design team to drop in, come up with something beautiful, and take off to rescue the next project). Teams rarely learn or get better from working with heroes. Instead, designing together increases the design IQ of the entire team. It allows every member of the team to articulate his or her ideas. It gives designers a much broader set of ideas to draw upon as they refine the user experience. This collaboration, in turn, breeds increased feelings of ownership over the work being done by the entire team. Finally, collaborative design builds team-wide shared understanding. It is this shared under- standing that is the currency of Lean UX. The more the team collectively understands, the less it has to document in order to move forward.
Collaborative design is an approach that allows a team to create product concepts together. It helps teams build a shared understanding of the design problem and solution. It allows them to work together to decide which functionality and interface elements best implement the feature in their hypothesis.
Collaborative design is still a designer-led activity. It’s the designer’s responsibility not only to call these meetings but to facilitate them as well. Sometimes you’ll have one-on-one sessions with a developer at a whiteboard. Other times, you’ll gather the whole 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 that 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 critical to maintaining the malleability of the work, which allows the team 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 documenting and detailing that approach.
Collaborative Design in Practice
In 2010, I 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 I was struggling to make it all work. Instead of burn- ing too much time at my desk pushing pixels, I grabbed a whiteboard and called the lead developer over. I sketched my original idea about how to lay out all the content and functionality for this dashboard. We discussed it and then I handed him the marker. He sketched his ideas on the same whiteboard. We went back and forth, ultimately converging on a layout and interaction schema that was not only usable but feasible given our two- week sprint timeframes (see Figure 4-2). At the end of that two-hour session, we returned to our desks and started working. I refined our sketch into a more formal wireframe and workflow and he began to write the infrastructure code necessary to get the data we needed to the presentation layer.We had built a shared understanding through our collaborative design session. We both knew what we were going to build and what it needed to do. We didn’t need to wait to document it. This approach allowed us to get the first version of this idea built within our two-week timeframe.
Figure 4-2. Whiteboard sketch that we arrived at together.
Style guides
One tool that makes collaborative design easier is the style guide. A style guide is a broadly accepted pattern library that codifies the interactive, visual, and copy elements of a user interface and system. Style guides (also known as pattern libraries) are a living collection of all of your product’s customer-facing components. If it’s made of pixels, it goes in the style guide. Headers, footers, grids, forms, labels, button logic, and everything else that goes into your product’s user experience goes in the style guide. Because they capture all of the detailed elements of your design system, your collaborative work sessions can focus on customer need, business problem, interaction, flow, structure, business rules—all things that are productive to work on in a team setting.Some companies use wikis for their style guides, which allows the collection to stay current and accessible to everyone on the team. Other teams choose to create “live” style guides. These are repositories of front-end code and design that not only define how the product looks and behaves, but actually function as the underlying markup and stylesheets for that experience. If you change the style guide, you change the product.
Style guides create efficiency. They provide a repository of ready-to-go, approved interface components that can be assembled and aligned to form a workflow. By minimizing debate over mundane elements like the placement of labels in forms or the never-ending debate over left/right placement of the “positive” action button, developers can get started creating core UI components without waiting for a designer to define and specify these assets. The assets are already designed, defined, and collected in one place.
Interaction and visual designers benefit as well. They no longer have to recreate representations of experiences that already exist. They become free to focus on new design challenges—novel interaction problems or extending the visual system to new elements. Approval cycles are streamlined because the repetitive elements (e.g., the treatment of the global navigation) are no longer up for debate. Reviews become more focused on the core product challenge and broader views of the proposed solution.
Creating a Style guide
There are two basic approaches to creating a style guide:Big bang
In this approach, your team takes a limited amount of time (e.g., one to two weeks or sometimes months) away from their current efforts to document all of your product’s UI elements in a style guide. The benefit here is that the style guide gets created in a relatively short amount of time. The negative is that your team is not learning anything new about your product during this time.
Slow drip
In this approach, your team adds an element to the style guide each time they create or change one for the project. The biggest benefit here is that the team continues to work on the project. However, the drawback is that the style guide is rarely completed and therefore fails to provide some of the efficiencies that a complete one does.
Maintaining a Style guide
When planning your style guide, it’s important to plan for maintenance. You’re going to need to create a process and dedicate people to keeping your style guide up to date. Think of a style guide as a living process that you launch and maintain, rather than a static thing you create. When you have an up-to-date and easy-to-use style guide, you make it easy for the team to actually use the style guide—and your goal should be to make it easier to use the style guide than to avoid it. You want to make compliance easy! So plan to dedicate people and time to keeping your style guide current.Want to read more? Order the book.
Interested in applying these ideas but not sure where to begin? The authors are also the organizers of Lean Day: UX, March 1st, 2013 in NYC, brings together 9 practitioners of Lean Startup and Lean UX in the enterprise sharing case studies of how they put these tactics to use every day.
