Tag Archives: team

Collaborative sketching builds a shared vision

Defending the wrong thing

Something used to trouble me. As I presented design documents to my team they would focus on minor details rather than the big picture. The question of whether a loading spinner should appear in the center or top left of a dialogue became more critical than if the feature to be built was compelling for a user in the first place. People would say things like “I would expect to see….” or “I like it when…”. What about what the customers would expect? What about what the customers like? I felt like I was defending my ideas, constantly. I needed more collaboration from my team members.

A better way

Through collaborative sketching (design charrettes), my role as designer has evolved into a more meaningful activity: helping the team understand what we are making, and why people want it.

The design charrette

Charrette literally means “chariot” in French. Back in the early 19th century on the streets of Paris, France, student architects were seen frantically sketching last-minute details for their final presentations in the school cart (charrette). The term “charrette” befittingly recalls the fact that teams often make important decisions at the last possible moment.

Participants

Designers, Product Managers, Developers (the team) should all participate in the charrette. When charrettes are frequent and the team co-located, some team members may prefer to focus on their current activity. Totally fine, but the designer and product manager may decide that those who have the necessary context should attend.

Rules

These rules ensure a safe, creative, and free-flowing environment:

  1. Engage with an open mind
  2. Check your ego at the door
  3. Leave your preconceptions behind
  4. Listen, then respond
  5. Acknowledge the contributions of others
  6. All ideas have value
  7. Begin with the end in mind
  8. Ensure the problem that brought you all together is better understood when you part

Other teams

When people who work outside of your daily team learn about the design charrettes, they will probably ask if they can join. The opportunity to allow outsiders to catch a glimpse of how your team collaborates will increase the visibility of the problems you are trying to solve. In every case I have seen this play to the team’s advantage since most teams within an organization share similar goals as well as barriers to innovation. The increased transparency will lead to better decision-making and organization-wide recognition of interesting solutions to common problems.

Tools and materials

Sharing works best when the right tools are provided.

These tools are required:

  1. Black sharpies
  2. 8½×11 printer stock

These tools are optional:

  1. Transparencies for communicating state changes on a UI
  2. Blue, red, or green sharpies
  3. Scissors for making shapes out of the paper and transparencies

Division of labor

In a smaller 5-8 person charrette the designer should be able to frame the context, pass around materials, and play time keeper. In larger 8+ person charrettes the designer will require assistance with dividing the group up into smaller manageable groups. The groups should hava a balance of roles and specialties.

Objective

The convergent-divergent nature of the charrette ensures many ideas are generated very rapidly. Time-box each iteration of sketching and feedback phases to maximize the 1–2 hours an effective charrette requires. The goal is not quality. The goal is a high quantity of ideas.

Begin by framing the problem at-hand. Spend around 5–15 minutes describing and framing the problem that brought everyone together. At minimum, an effective design problem describes:

  1. A precise definition of the activity context
  2. The participant(s) in the activity context
  3. The outcome(s) of the activity context

Creating an activity diagram together, prior to sketching solutions, will increase the shared understanding of the activity context. This understanding will invariably lead to relevant questions and proposed solutions during the sketching activity.

Don’t worry about being too specific. Any pertinent details will emerge during the charrette. This is called inquiry through design.

Iteration one

Ask the group(s) to generate 5 ideas in 5 minutes. In this first iteration, individuals should be sketching independently. People should not talk during this first phase of the activity. Sketching 5 ideas in 5 minutes will get people warmed up and allow the fuzzy and naive solutions to release out in the open.

When the 5 minutes are up, tell everyone to put their sharpies down. Each individual in the group (or groups) now have 2 minutes to describe their ideas at a high level. The 2 minute time limit for each person will ensure everyone gets the opportunity to share their ideas. Let people know they will have more chances to refine their ideas if the charrette stays within the time limits.

After each person has shared their ideas, ask everyone else if they have questions or feedback regarding the ideas. When it appears the conversations have reverted to solution-finding, move on to the next person and ask them to share. Remember, all ideas have value.

Iteration two

Ask the group members (or each group) to generate at least 2 solutions in 15 minutes. In this iteration, the group members can talk openly and even ask detailed questions of the designer and/or product manager as they talk through and sketch out their ideas. Allowing group members to collaborate ensures a convergence of ideas from the previous iteration.

When the 15 minutes are up, tell everyone to put their sharpies down. If working with multiple groups, choose a group to be the first to present and call the other groups over so everyone can clearly see the sketches and hear the presenters.

Again, allow the group members 2 minutes to describe their ideas.

Continue running iterations in this manner. As ideas emerge and reemerge, capture them succinctly on a whiteboard. The reemergence of ideas may culminate into patterns. Encourage the group to name their patterns. Examples I have seen are magic card and funky tray. These patterns eventually made it into the product with only slightly different names.

Outcomes

The charrette will invariably result in a shared understanding of the problem and the design space. Further refinement and analysis may be required. In software projects the charrette sketches may be easily translated into working prototypes or even production-ready code.

Make the output of the charrette visible so that folks who did not attend may see and experience the journey your team just embarked upon.

Approaches to collaboration

mblongii: What is your process like? Build and iterate or design specs/mockups?

designer: It depends on the feature. At TheAgency it was largely specs/mockups and toss it over the wall to the developers. At Mobi I’m the sole design person on an engineering team of 6 in US and 50 in China so I’m pretty much the gatekeeper for all things UI/experience and work side by side with the engineers.

mblongii: How much prototyping do you do?

designer: LOTS of engineering prototyping to prove out concepts, which often become the final product. What’s nice is I can design something (I still do plenty of mockups/wires/specs) and send it off ot the China team, and the next morning there’s an app I can install on my phone that is exactly what I designed.

mblongii: Exactly? Whoa.

designer: Very close. You always encounter the unexpected during the prototyping, but of course that’s the beauty of it.

mblongii: Why do you think TheAgency was very ‘throw it over the wall’? I mean, why do they operate that way?

designer: Because that’s how they’ve operated for ages and their clients work that way. By positioning themselves as a ‘design’ or ‘experience’ design company, they are asked to provide just that: Design or an experience. Unfortunately it’s very seperate from the development/implementation. Even for projects that are created entirely in-house, the designers and developers don’t talk the way they should. Much of it comes down to projects being scoped incorrectly and expectations not being communicated properly.

mblongii: People have told me in the past that Mobi’s design teams don’t have enough influence over engineering. What do you think changed since then? Because your environment sounds quite the opposite.

designer: Well, I’m the only design/ux person in all of engineering here :] so my role is sort of an exception. Mobi has a design department. I’m also sort of a liason between engineering and the design department. I’m on a software engineering team, but I also meet daily with the lead engineers working on various other hardware.

mblongii: Are you picking up electrical engineering skills?

designer: Well, I’m learning the language. Enough to understand what is needed to optimize the user experience even down to the finest detail. I annoy people by my persistence i’m sure, but because I do that, often the manufacturers have to re-write their drivers to optmize for the best experience. So I’m definitely able to influence the entire process, which is quite nice.

Product design is rapid and continuous learning

In my experience as a designer on complex software projects, I have come to realize that all people involved on a product team (developers, designers, and stakeholders) need to share certain universal values which influence the design of a software product.

These values are:

  • Collaboration vs. process and protocol
  • Making the product work vs. defining how the product works

In short, the quality of design is a reflection of the quality of communication. Likewise, progress is measured by how much effort results in working software delivered to the customer.

Improving communication between designers and developers is as simple as placing designers side-by-side with the whole development team. The positive side-effect of doing this is a reduction in time to report issues and request changes.

Other positive side-effects of co-locating designers with the whole team might be:

  • Experimentation with novel and useful features
  • Fast and simple solutions to complex problems
  • Improvement of the overall customer experience

It seems counter-intuitive, but product design is not the conscious act of generating designs. Instead, it is rapid and continuous learning. Learning about how customers use the product, and pivoting in response to that feedback throughout every software development phase.

Customer feedback can be obtained through frequent usability testing with working software, and informal customer interviews that reveal underlying customer motivations and needs. By sharing information with the whole team through rich communication channels such as workshops and retrospectives, the learning is naturally integrated back into the software development cycle.

Design is an evolutionary and collaborative activity. When people embrace this fact, cool and interesting things happen.