Our web is a complicated web, because people are complicated beings. The web is made for people, and the web is made of people, so if we don’t understand people we cannot understand the web. These are the basic truths of the Internet. It was made by people, and it serves people, and it requires people to keep it working.
There are a lot of questions wrapped up in those thoughts. That’s fitting. Without questions, there is no web. There is no understanding – no “user experience” and no “responsive design”; no “content strategy” and no “agile development.” There’s no reason. It’s just words and websites and images. It’s form without function.
So we probe. We learn. We confirm and reiterate. We ask questions not just to learn, but to shape the conversation.
Some questions help us teach complex concepts, providing breaks in the conversation for reflection. Some questions help us listen, the answers not as important as the process. Questions are fuel for discovery and method – from those that produce single-word answers (and the underlying currents that those answers produce) to those that make us rethink our entire process.
The web is complicated, because people are complicated. And that makes the questions we ask – both their wording and their function – complicated.
The traditional view of a question is as a method for gathering information. It is a tool for learning – a formal request for knowledge we don’t have.
We see this when we open a project. Getting started with a new group or a new initiative – whether it’s a single-page brochure site or a stand-alone service like Facebook – requires a certain level of grounding, where we rub our eyes and look around at the landscape. This initial process – “discovery” or “kickoff” or something else – is where our first thoughts are developed.
Regardless of the project, we can start with a boilerplate of questions that will serve as a compass, showing us the initial direction and familiarizing us with the main parties:
We ask about project audiences:
We ask about expectations:
We ask about workflow:
These are just a handful of questions we ask from project to project, depending on scope and stakeholders. There are more questions out there, and you may have your own. We especially like stuff from the following resources:
Yet these initial questions only start the conversation. It’s the detailed questions we ask to keep the ball rolling – questions that follow the basic concept of The Five Whys, where real knowledge is gleaned from several layers of follow-up – that are so valuable to us.
Follow-up questions are created out of a need for clarification, and serve to either narrow down an answer or, on the other end, broaden an answer. We may be looking for more specifics, or we may be looking for more context. Regardless, we’re looking for something. If our initial boilerplate questions are like road signs showing us the next Interstate exit, follow-up questions are the street signs that get us from the Interstate to our destination.
All of the questions in the world won’t matter if we don’t know what we’re trying to discover, so there’s value making that determination early. This can be done as part of a kickoff agenda, or it can be done in our heads. For example, if our goal is to better understand the client’s workflow, we need to write out a certain level of expectations:
Interview Goal: To better understand the client’s workflow.
These expectations help us ask effective follow-up questions. They don’t lock us in to a set of questions, either – we can still go off track if a specific branch of questioning is uncovering something we didn’t expect – but they at least keep us honest and on track.
Hold on, though. Questions aren’t just about answers.
The basic construct of a question is simple. You have the need for information. You form a query. You communicate the query. You wait for a response. You receive a response. These are the building blocks of exploration, and while the communication may vary and the responses may come or not, these elements form the basis of discovery and curiosity.
But not all questions are meant to gather information. There are times when our queries are meant to spark discussion or, often indirectly, to teach.
Anyone who has seen 15 minutes of Law and Order (CHNG CHNG) knows it’s in a lawyer’s best interest to never ask a question to which he or she doesn’t know the answer. Questions are meant to steer discussion toward the expected answer, to make aware of the situation.
For example, we can ask a question like:
“Who will be responsible for this section of site content?”
We probably know who is going to be in charge – it would have come up in our discovery workshop or during weekly conversations – but that’s not the point. The point is to reiterate that someone has to be responsible. If we don’t ask the question, the answer may never show its face.
This is not always a deliberate process. While we might use probing questions about process to steer the conversation toward ridding companies of their silos and politics and other internal strife, we also stumble across these teachable moments by asking simple everyday questions.
Say, for instance, in the midst of collecting information for a new manufacturing client, we ask for a list of product categories. We expect a simple response: “We’ll send you a list of categories by the end of the day,” or “We typically group our products by application, so that is where our category separation lies.” But sometimes we get something different.
Sometimes we get dead air on the telephone. Sometimes we get a blank stare. Sometimes we don’t get the answer we want, and that’s what makes our job so fun.
It goes beyond pointing out issues and potential complications. In Kevin Hoffman’s 2011 Netmag article “How to Run an Effective Meeting,” he talks about “the constant,” a tool that helps keep everyone oriented around the purpose of a workshop or meeting. He says:
Using “the constant” in a long workshop is a powerful tool. As you move thought the day, it could be something as simple as a single question on the wall, written in large text, where everyone can see it:
How will what you are doing right now create the change that we seek?
In this case, we are using a question not to get an answer, but to lead the group toward a common goal. The question has become a way to teach focus and commonality.
In these moments, we shift from practitioner to teacher, deftly switching gears to turn the focus from the answer to the question itself. Teachable moments are where we stop focusing on the project and we start focusing on the people – the editors and the client and the end users – in a way that furthers the cause.
Ready for it? There’s a third kind of question, too.
While questions are designed to gather information and, if given the chance, drum up teachable moments, they can also play a subtle role in raising awareness and fostering a community of change.
Every project has stakeholders, but not every stakeholder is created equal. Some are active and vocal, leading the charge for site content and dynamically filling the room with confidence. Others are disconnected from the project – too busy or too hard to pin down – and even more are passive, staying quiet in the face of change and secretly hoping that nothing will change.
Those vocal stakeholders are valuable, yet they drown out the opinions and needs of the non-vocal minority. Our job is to make sure everyone gets equal time – or, at least, some time at all – to voice their requirements, weigh in on proposed change, and become an active part of the project.
In this way, the questions we ask may not be designed to gather information, but instead serve as a platform. A soapbox. An opportunity to speak in a process that can often be pushed faster than change management can keep up with.
Bringing stakeholders into a project – even by asking questions and listening to their answers, regardless of those answers might impact the project – promotes buy-in. It fosters ownership. And, what’s more, it may uncover dependencies that we never knew existed.
These questions come in two forms:
Is asking questions automatically going to ensure everyone is on board? No. Of course not. Is asking questions going to help the process in the long run? Probably. Is it worth the extra effort? Absolutely.
Let’s not assume that all questions fit neatly into these three categories. Often, we ask questions with multiple purposes in mind – a question asked to learn can also be a question asked to teach, while those we use to listen often help us learn things we might not otherwise have gleaned from our key stakeholders.
The point is bigger than those categories. We must ask questions thoughtfully, not just to collect data but to drive discussion and develop strategy through conversation and critical thinking. We must ask questions that do more than fill in boxes – we must ask questions that create more questions. Each person houses feelings and information and answers and problems, and each question is a quick peek into a doorway. We must work to get past the doorway, into the room, where we can take our next step and help create something that’s usable, useful and memorable.
On paper, questions are just a few words and a squiggly mark. In real life, they help us find our way through the darkness, as long as you understand how those questions illuminate the path.