The Designer’s Guide To Requirements Elicitation

The ability to ask great questions might not just be the foundation of great relationships, it could also be the foundation of great solutions. As business analysts, this ability is required to hold elicitation sessions which could lead to great products.

I remember listening to Diary of a CEO author, Steve Bartlett, asking his guests very detailed questions about themselves on his podcast. I remember asking myself “what if I could be this articulate during interviews or elicitation sessions?”

While this question played in my head, my mind went to my wife, who is a student of leadership. I remembered how easily she makes friends simply because she has the ability to ask great questions. I began researching key characteristics of people who asked great questions; and about my inability to. I learnt that one of the challenges I faced regarding this topic was my tendency to avoid deep conversations. Unlike me, people with this skill do not tend to ask shallow or “safe” questions and in turn, they give off this vibe of possesing empathy.

During my research, I read an interesting article on HBR written by an independent researcher and senior advisor, Tijs Besieux. Instead of finding key characteristics of people who asked great questions, the articles highlighted key characteristics of great questions. I may not have hit the moon, but I may have landed on the clouds.

Besieux distilled these characteristics into 3: 

  1. A great question should demonstrate that you are thoroughly prepared for the conversation.
  2. A great question illustrates the expertise you bring to the table without showing off.
  3. A great question invites others to deepen or broaden their thinking, and challenge held beliefs.

With these three characteristics, I felt I was ready to deploy. But then, how would a business analyst benefit from these characteristics when trying to elicit requirements from stakeholders?

This led me to take another look at questioning from a designers point of view.

Lead With Empathy:

When trying to elicit requirements, it’s often better to start the conversation by trying to understand the humans behind the needs. This means starting with questions that uncover the pain points of the individual or team so as to create a safe-space for them to share their experiences.

Example: “I understand that you are responsible for receiving customer tickets and logging them for the technical teams which could be quite demanding on a good day, but could you walk me through a typical day in your role?”

Questions like this focus on the human part of the system first which can be a great foundation for further conversations.

Explore the Context:

One of the best things about design is the ability to zoom out to see the bigger picture before zooming back into the detail. As a business analyst, this approach allows you to explore the broader context of the problem you are trying to solve.

Example: “I noticed there are 3 other teams that are involved in contributing to this report; which of these teams will be impacted by this process?”

This question helps you explore dependencies, if any, and it also makes the stakeholder understand you have done a little homework regarding the problem you are trying to solve.

Ask “Why?”:

There is a reason the “5 whys” is a staple technique for business analysts. It is used to peel back the layers to a problem as each “why” brings you closer to the root cause of the problem.

Example: “It appears the purchase order needs to be uploaded before the invoice can be generated. Why does that need to happen?”

Challenge Assumptions:

Designers often question the status quo, so do Business Analysts. Do not assume an answer is obvious. Ask about it anyway.

Example: from what you have told , i understand that the customer’s feedback is required before the team can close the ticket. What if we eliminate that step where the feedback is required?”

Prototype With Your Questions:

Hypothetical questions can be used to help the stakeholder test for possibilities or explore potential solutions.

Example: “What if a tool could extract the key details from the email and populate the worksheet immediately the email is received? Would that help the team perform better?”

Great questions lead to great conversations which are the basis for great engagements. By adopting design thinking skills in enquiry, business analysts can deepen their understanding of user needs and build strong communication channels with stakeholders which in turn lead to better solutioning.