Kim Dowd, Jake Burton-Denmark and I have been working together on a project for the last few months. Throughout the project we’ve adopted and iterated on the following sketching technique (credit to David Sherwin who exposed us to this approach). We use it for kicking off new features or revising existing ones and we apply it to all sorts of tasks, from developing big, broad feature sets all the way to small specific interactions where the solutions might seem obvious at first.
HERE’S HOW IT GOES:
The designer that picks up the user-story from Tracker briefly explains the context of the story, its background, and the constraints involved.
In this case the story was: “A Physician can indicate that a patient is leaving the ER.”
An example requirement is: “She can indicate what happens with the patient next.”
The context was stated as: “Typically, she does this after looking at the results of tests, and recent vital signs.”
Once the timer is running, each of the designers on the team (3 of us) grabs paper and a Sharpie and spends the next five minutes sketching out wireframes and flows for three potential solutions that meet the story’s requirements.
It’s important to remember to only use broad strokes and not get into the details of the wireframe. We are just looking to get an idea across, not to draw a perfectly accurate wireframes.
Each sketch is no bigger than about 1/4 of a letter sized piece of paper. The small canvas forces us to stay general and prevents us from deep-ending on the details.
Once the five minutes are up, we always seem to need an extra 30 seconds to finish :)
After five and a half minutes of sketching, we each walk the team through our sketches. It is important to keep it brief, not more than four minutes each, tops. We find it useful to point out the advantages and disadvantages of each of our suggestions.
As we go around, one of us takes notes of questions that come up, missing requirements that need further clarification and anything that would requires user feedback (these then go to a separate running list of things that need user validation).
CHOOSING THE RIGHT SOLUTION
You’ll find that sometimes all participants come up with more or less the same solutions. In this case we say “Great!” (apparently the solution is obvious and no one on the team identified a problem with it). Other times, we’ll each go in completely different directions. This typically means we need more clarification around the goal of the feature in order to decide which direction makes the most sense. This is when it gets interesting.
Usually what we find is that each of us has made an assumption about the requirements (e.g., “I think the form should only be 2 fields” vs “I think the form should be long” or “I think the user needs access to this other page while filling out the form” vs “I think the user has all the information they need in their head while filling out the form”). When this happens, it usually means that in order to choose the right design we need further clarification.
The owner of the story will then collect all of the sketches and questions and is responsible for collecting the information needed to pick and execute the appropriate design.
WHY WE FIND THIS SO USEFUL:
- It’s a great way to keep all the designers on the team up to date on the features that are rolling out.
- This activity reduces the risk of inconsistencies when multiple designers are building out the same product. It ensures we are all adhering to the same design patterns, using the same language, etc.
- It provides an extremely fast way to explore many directions, get feedback on those directions, and select the most relevant one.
- It is a great way to expose issues early on in any particular design direction. By talking through it with the team, we are able to surface these types of issues right away.
A NOTE FOR SOLO DESIGNERS:
You’ll find it challenging to do this exercise when there is only one designer on the team. If this is the case, you can bring in external designers, from other teams or people from your community, etc. and go through this process with them. Another alternative, which we haven’t tried at Pivotal yet, is to work with non-designers on the project such as PMs or developers.
This is process is working really well for us and the results for our clients are great. I’d love to hear if you implement this process, how you find it and ways in which you do it differently. If you have other processes you use, please share them in the comments.
About the Author