One of my favourite ways to solve problems that involve different departments is by using a whiteboard.
In order to solve any problem, you need to be familiar with the tools. I don’t mean fancy pens or the latest wireframing software, I mean the methods and approaches that you use to solve problems. Over the years I’ve had many design problems to solve.
I have found that there is no silver bullet, no “single process fits all”. Every project is different, with different constraints and requirements. Problem solving is a skill like any other, and if you know how to approach different problems, you increase the probability that one of those approaches will be the right one.
Solving Design Problems on the Whiteboard
There are many ways to solve a problem, and by knowing them you increase your chances of finding the right solution. Just last week, there was a problem between 3 different departments. We gathered at a whiteboard, and within minutes, the problem was solved. This is the power of collaborative design solutions. It’s why “Whiteboarding” is first on my list every time.
At the whiteboard, everyone gets a marker and everyone has a voice. There is a nice equality when people from different departments (development, brand, marketing) can stand around and everyone can feel like they are included in the design process.
As the designer, you are expected to lead this session (and yes, even if it’s just casually standing around a whiteboard, it is still a design session). Here is my process for keeping the session on track and ensuring that you work to a solution.
Step 1: Assemble!
If it’s a problem that involves different departments – make sure every department has a representative. Suggest a time and send around an email to see if everyone could meet for a sync up. As a designer, I tend to lead these sessions, so it’s up to me to find a time and a place that suits everyone.
Step 2: Get All the Facts
This is a critical step: get all the facts. Write the problem statement in caps at the top of the whiteboard so everyone agrees what they’re supposed to be solving eg. “How can we improve the customer on-boarding process?” Are there some particular dependencies that you need to consider? Write those up also. “Users will be logged in” or “price information can change mid-flow” – these are the kind of details that can have an impact on the user flow.
Step 3: Brainstorm
Start with “what if” statements. “What if we asked customers to sign up when they finish the checkout? They would only need to add a password…” “What if we sent out an email after their checkout? Asking them to join when they have received their order?” Consider each person in the group by asking what they feel about each of the proposed solution. Each department might have a different set of concerns that other departments hadn’t considered. Beware of the word “No” in this situation. The word “no” shuts down the conversation, much in the same way as it does in improvised comedy.
Step 4 : Try Not To Disagree
One of the problems I’ve encountered when you’re collaborating with others to find a solution is when someone flatly disagrees. When someone disagrees with a proposal, the conversation stops dead in it’s tracks.
At this point, I would also highly recommend you check out Tina Fey’s Rules for Improvised Comedy – as they apply to the whiteboard.
- The first rule of improvisation is to AGREE.
- The second rule of improv is to not only say YES, say YES, AND.
- The next rule is MAKE STATEMENTS.
- THERE ARE NO MISTAKES only OPPORTUNITIES.
Step 5: Keep Things On Track
Keep the discussion on track, don’t let people ramble off topic or you risk boring the rest of the participants and will make the discussion feel less relevant. Similarly, if you notice someone being less chatty than the rest, ask “We haven’t heard what Julie thinks yet” to make sure everyone has their chance to chime in. You don’t want a bulldozer taking over. Keep things level.
Step 6: Make an Agreement
When you’ve exhausted the “What if” statements, find the one that you agree on most as a team – the path of least resistance. Clarify this by repeating this approach, and ensure that it is technically feasible and will provide a good user experience (no multiple logins, no nasty pop-ups)
Agree that you are going to focus on the statement, and as a designer you are going to ensure that everyone is satisfied with this outcome.
Take a photo of the whiteboard with your phone when you’re done, incase you need to look at it when it’s time to prototype.
Step 7: Low Fi Prototype
As soon as possible, mock up a low-fidelity prototype, or simple flow, that illustrates what you have just agreed on. Send it around so that everyone is clear on what’s going to happen. If you try to do this soon after the whiteboard session, it will still be fresh in everyone’s mind. You also have a nice record of what was agreed upon in the session.
So that’s my design process when it comes to the whiteboard. It’s quite detailed, and I don’t always need to take every step. I’d love to hear from you – what is your process when it comes to the whiteboard?