There are few things that web professionals can agree on unanimously. The nature of this business relies heavily on “best practices” that can often be of a subjective point of view. That being said, there are few people in this industry that would disagree on how important it is to ask the right questions and, more importantly, really hear the answers.
Coming from primarily an Engineering background, working in Business Development has opened my eyes to the need for all of us to not only be good at the technical aspects of our job, but excel in communication as well. As buzzwords take over the business, this becomes even more critical. How many of us have heard one of the following phrases from clients?
“I want it to be Web 2.0!”
“I want my users to share content!”
“Can you build me a Social Network?”
“My users should be able to tag articles!”
Before we explore the reasons why statements like this can lead to dangerous results without further clarification, let’s discuss why they are made in the first place: We ask the wrong questions.
Most clients who would use these types of phrases in the discovery stage are simply victims of a maelstrom of media that have used, and misused, these terms for as long as they have been introduced. Our clients should not, and often do not, know at the start of a project what a “tag” is, or what makes up a “social network” any more than we should know what allows their “Widgetron MST-3000” to produce the beautiful widgets they are selling on the web.
So what are we left to do? Inexperienced professionals make the decision for the client with no additional feedback from them and no follow-up questions. They estimate some hours, put together a scope document/specification/wireframe/whatever (which is as vague as the statements that produce them), and get to work on the development.
What happens then? Here’s a scenario that some of us who have worked in the freelance world can instantly recognize:
3-4 months after the project’s intended launch you are still fielding changes from the client who you claim “will never be happy” or “doesn’t know what they want”. By the time the project is (finally) to their satisfaction, it barely resembles the product you thought you were building and therefore is filled with hacks and workarounds trying to achieve the intended result with as little additional cost to your team as possible.
One of my favorite books, which I read when I was still a new student of the Web, is Database Design for Mere Mortals by Michael James Hernandez. He discusses not only the abstract concepts of database design but the interview process involved with it. The following excerpt, from Chapter 6 of the book, is, in my opinion, applicable to more than just database design. I feel it applies to the entire discovery process as a whole:
“You use both open-ended and closed questions throughout an interview, alternating between each type as the interview progresses; the open-ended questions enable you to focus on specific subjects, and the closed questions allow you to focus on specific details of a certain subject.”
Let’s use an example from our list above and see how this would play out in a “real” interview. Bear with the simplification for the purposes of example:
Client: “Can you build me a social network?”
You: “What would you like your users to be able to do?”
Client: “Tag content, post stuff and send messages to each other.”
If we ended the interview there and went on our merry way, we might go and build a Facebook-style application with an Activity Feed and the ability to free-tag the posts that users generate. Sounds like what the client wanted, right?
Let’s see what happens when we add a couple of our closed questions to the mix:
Client: “Can you build me a social network?”
You: “What would you like your users to be able to do?”
Client: “Tag content, post stuff and send messages on the site.”
You: “Ok, so users can create their own categories, right?”
Client: “No. Categories? Why would they need those?”
You: “I thought you had said you wanted users to tag content.”
Client: “I do. So they can come back to it later.”
You: “Ok! I understand. You want them to have a list of favorites!”
Imagine, additionally, if the interview ended with “send messages on the site” – we might automatically, if using Drupal, grab the Private Messages module and be done with that feature. However, if we had asked the right question as a follow-up, we might have found this client had something completely different in mind.
For example, if we asked this closed question as a follow-up:
You: “Should the users be able to send messages to a) each other b) the whole site or c) members of a group?” Client: “The whole site. I want them to discuss topics of interest to them.” You: “Ok. I see. So, you want a forum then. Let’s talk about a forumŒƒ.”
While the interviews above are contrived for the purposes of example, it serves only to show how critical the balance between asking the right questions and being thorough in your understanding of the answers is to the success of a project. Remember that your technology-fueled definition of a Blog could be vastly different from that of a client who spends their days building their landscape business. Sometimes we have to adapt our style to get what we want from a discovery session. And other times, we just need to listen.