donttouchme: Client Questionnaire

During the webcast earlier today, I mentioned that one of the ways I engage with clients at the beginning of the process is to ask a quite set of specific questions.

Most of this is from my previous, self-published book on design process. It's getting old now, but I use it all the time. Much like the way I am constantly borrowing from my own Mobile Design Patterns document (and you probably have your favorite stencil), this is my process cheat sheet.

Workshops

Its always best to get this information directly from the business owners. Who this is will vary a lot (and could be marketing, product development or even business analysts), and will be up to your knowledge of the organization. However, keep the group small. More than about 5-6 people in the room, total, and you will start getting more caught up in conversation than information gathering. If more than that many are absolutely needed, it’s a good hint that the product is too complex and needs to be broken up or narrowed even as a basic concept.

And that has brought up a concern with a number of folks I work with. You only want to interview people in a group very carefully, with a very good moderator, to avoid contaminating or suppressing any one user’s opinion. But for product owners, the product vision is often spread among a group, and no one person has it all in their head; group contribution will be needed. Be careful of politics, and try to have reasonably senior people, but all at broadly the same level. You can encounter yes-man issues if the big boss of most or all of the others is in the room.

This should probably be an immersive session, a few hours (two 4 hour sessions, over two days, works well) to get all the information down. Use all your info gathering skills and bring lots of post-its, paper and markers. Computers and, if possible, phones are off. Close the door, and get everyone to focus.

Questionnaires

Over the years, and after dozens of projects, I added and removed the questions to get the best responses. I tried to keep track of them when I asked in the room, and stuck to the plan so I wouldn't miss something, but it's not a script. Moderating a workshop is pretty open even with a solid plan.

But then I started working projects with remote clients, where I was not allowed to fly to them routinely. And then I went to an agency, where almost all the clients were remote, and hired us because we were quick and cheap. Almost no interactions are face to face, but I have the same needs.

So my questions became a questionnaire. And got tweaked till I get very consistent responses. You can think of this the way you approach usability testing. Ideally, you'd have fifty participants in three geographically-diverse areas. But you can do an 80-90% solution with five, here in town. The few times I have been able to follow up a remote questionnaire with in-person workshops, I am at that level of quality.

If there are enough participants, and I have time, I make online surveys. But you can manage to just send this out in email as well.

This information is to be filled out by yourself, individually. Not only should you not collaborate with others, but do not worry about what others may answer. Your concerns, thoughts and phrasing will be different from anyone else, so there is no such thing as an answer that duplicates what someone else says.
What is the product?
You are in an elevator with a chief executive of your company. He asks, “what are you working on these days?”
In one short sentence, using plain (non-technical) language, explain what the product is.

Now, do it again. Try to answer at least three times (total), in different ways. Make sure each answer is true, even though no one answer can completely cover all the features and capabilities.

What is its one, main purpose?
Eventually, a complete list of features will be created, and from this the design of the screens, the software and the content management systems will flow. Before this, however, there are high-level categories of features (this is similar to business requirements, business needs, etc.). This will be considered by the end user to be the purpose of the product. These are the features you have in mind when discussing the product.
Pick a single feature of the product you think is critical and express it in as few words as possible. 1-2 word phrases are perfectly fine (“receive cards”); these do not need to be complete sentences. Do not consider technology, UI, wording or other content at all.

Now, answer it again. You may answer as many as five times in total. Do not restate any points; each one should be unique.

If the domain (i.e. the mobile phone application) is obvious or always the same, there is no need to state it each time.
What one problem or concern does it solve?
Products are pursued as a result of a business opportunity, or a business problem. Consider any opportunity to be a “problem” in the sense that its something the company is not pursuing (so a missed opportunity for now).
Re-read your definitions above, and answer why you want to build such a product: What is the one problem the product will solve? Do not state how it will be solved, just what the problem itself is.

Please limit your statement to a single, short sentence. Avoid listing items, asides, definitions or prevaricating phrases (e.g. “or other things”).
Who will use this product?
Instead of trying to design the product for everyone, we will be focusing on feature sets, and interface designs that meet the primary needs of a small but focused set of users. These should not be market segments as they exist today; instead consider the manner in which you expect these customers to use the product. Think of:
Who they are

Where and when they use the product

What sort of items they search for and send (or, receive)

Who they are sending the items to (or receiving from)

Who do you see as the core users of this product set? You may answer either as “the most common” or your “most desired” users.

If you have several users in mind, feel free to include them all, but make each one an independent statement.