Using audits to drive change, Mechanics Bank launched with a new CMS and an improved design that follows web best practices. Find out how. 

The Web of Questions

Our web is a complicated web, because people are complicated beings. So we depend on asking questions – for clarity, yes, but also for education and inclusion.

12/12/2013

Authored by

Categorized

  • Discovery and Scoping
  • Strategy

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 questions we ask to learn.

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:

  • What is the ultimate goal of this project?
  • What general functionality must be included?
  • What role does this site play in your overall marketing strategy?
  • What will make this project a success?

We ask about project audiences:

  • Who will be using this site?
  • Who are your primary audiences?
  • What outcomes do these audiences expect from the site?
  • Who are your competitors and what do you like about their sites?
  • What demographics and metrics are you currently tracking?

We ask about expectations:

  • What do you expect to come out of this workshop?
  • How long do you need to approve documents or concepts?
  • How much research do you already have on hand?
  • Are we using your existing content management system, or are we helping select a new one?

We ask about workflow:

  • Who determines when and what a new piece of content might look like?
  • Who is in charge of general upkeep of the web or content management system?
  • Do you have an existing brand standards document?

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:

Follow-ups: where the real questions start.

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.
Expectations:

  • We will know who is involved in all aspects of content delivery.
  • We will know how content moves from one person to the next, including how long it takes.
  • We will be able to pinpoint inefficiencies in the process.
  • We will better understand how content is initiated and where it lives.

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.

The questions we ask to teach.

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.

The questions we ask to listen.

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:

  • Open-ended questions – Those questions we asked in the beginning? Ask them a lot. Ask them of everyone. Determine a set of questions – questions that relate to the overall goals of the project – that you will ask of every single person that you meet with. This could be as simple as “How do you think users navigate the website?” to as lofty as “How can we better fulfill the mission of the organization?” You will hear a lot of similar answers, but you’ll also be facilitating participation in the process.
  • Confirmation questions – After hearing about the importance of one department’s inclusion on the home page or about the need for a searchable FAQ page, turn to someone at the table who has been quiet and ask, simply, “Does this apply to your department?” or “Do you need the same kind of functionality?” Even if an answer isn’t given at that time, the door has been opened for all-hands-on-deck opinions. They may manifest later, in private, after the meeting has finished. Or, it could manifest in an email. The important thing is that the question was asked.

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.

A guiding light.

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.

Our thoughts on web strategy.

Read articles on web strategy.

The Truth is in the Red Flags Off-site link

Taylor Lopour

When is it time to rebuild a website? The obvious scenarios include big, hard-to-miss events. But more times than not, there are red flags flying in plain sight, signaling it's time to move on.

December 4, 2023 | 24 Days in Umbraco

How Developer Cross-training Helps Projects Succeed

Nick Cobb

Cross-training developers results in increased productivity, more collaboration, and better results for client projects. 

October 24, 2023

Episode 24: Maintain and Improve (w/ David Hobbs) Off-site link

Corey and Deane discuss the people and rules that help run a website after launch. Then, David Hobbs, author of Website Product Management: Keeping Focused During Change, joins to talk about transferring a site from a project to a product — what that means to keep the site going after launch, where it most often fails, and how to streamline requests and set reasonable expectations for the future of the site.

October 17, 2023 | The Web Project Guide Podcast

Read all web strategy articles.