If You Need to Explain, You've Got a Design Problem
The title of this post is a wee bit binary, but it's a topic worth discussing. I was just reading a post by Rob Adams, who is working on Adobe's Thermo project, about the value he finds in paper prototypes, and some of the problems.
I'm in the middle of developing a new application with my super-great team, and we're moving from paper prototypes to a clickable, HTML prototype. There's a lot of discussion with the client during this time, and they've now seen four versions of the application on paper. At one point in his post, Adams makes the following salient point:
Correct any mistaken assumptions that are an artifact of the low-fidelity paper, but make sure you record points where you have to help them or explain something - these are design problems you need to fix.
It's very, very easy when settling in to a routine of back-and-forth and discussion with a client to easily explain away a question they have about the interface (and therefore the workflow) without realizing that this, in all likelihood, is a design problem that needs to be solved. If they're asking you "How will this work?" or "What is this for?" or "Will it do [x]?" when that task is represented on the prototype (or is supposed to be represented or implied in the prototype), then you've got a design issue that you need to handle. If they're asking about how data is stored or background workflows not covered by the prototype at hand, then that's not necessarily a design issue that needs to be addressed.
Sometimes you're so focused on just getting through the key aspects of the prototype in the hour that the client allows you to meet with them that it's easy to quickly explain something they don't understand in regards to how the application will work. Have a second set of hands with you to note all the questions (something else that Adams recommends) so that you can go back later and say "They didn't understand this, and it's supposed to be self-evident. Let's take a look at how we can improve the design."
If someone in the prototyping process has a question about how the app is supposed to work, then you can be sure that there will be lots of people who use the app who have the same question. By listening to the workflow or application operation questions being asked and not quickly explaining them away, you'll find the design flaws and be able to fix them before they become a headache in production.
