A most important milestone in building a dashboard is the meeting among all the stakeholders, especially end-users, to discuss and agree on the deliverables. This process is called requirement gathering meeting. At Visual BI, we call these sessions design workshops as we believe that requirements are a designed product, created as an outcome of the collaboration among stakeholders. Here are the critical points of the discovery process to deliver what users need without spending days on user research.
1. Don’t gather requirements. Discover them.
The word “gather” infers two dangerous assumptions about our requirements. First, it tells us that requirement is already there, like fruits on a tree, and our job is to pick up or ask for it. Secondly, it inherently assumes that users know what they want. That will lead us to the most fundamental mistake – asking the user “what do you want?”
So here is the first principle of user experience design:
People don’t know/ realize what they really want.
The downside of asking that question is that people will give you the wrong answer. Since it is not common for people to admit that they do not know what they need, end-users tend to give us what they think is the solution to their problems. Wearing the hat of an experience designer, we need to discover what users need by listening to and understanding their problems and motives in the first place. In other words, we care about the users so much that we don’t take their words for granted. Thus, the first step towards discovering requirements is to clear your head of any preassumptions, be genuinely curious to be in users’ shoes to understand their problems, and an excitement to discover requirements.
Then, how do we look for what users want? By investigating their goals, workflow and pain points.
2. Understand the user’s goal
The function of a dashboard or any BI tool is to help the user achieve specific goals. It does not matter how many cool features or functionalities the tool has, our user needs to accomplish those goals to be satisfied. Since goal-setting is not a technical process but a human process, it is crucial to have a focused and separated conversation about goals and objectives, without referring to the tool.
What users want to achieve has a lot to do with their job and responsibilities. The first step is to identify the target audience for your dashboard and what their roles and responsibilities are in the organization. For example, within the Sales department, different user groups have different roles:
- A Sales Representative needs to meet sales targets or maximize sales within a specific time frame.
- Sales Manager needs to evaluate sales representatives’ performance to determine bonuses and promotions.
While looking at the same sales transactional data, they will look for different answers.
A typical Sales Representative will need to know:
- How far are they from achieving their sales target?
- How many days are left in their sales cycle?
- What is the total value of unclosed deals? Will those help them make their target?
- What are the potentials of each deal closing? How soon can it be closed? (predictive analytics)
A Sales Manager will want to answer questions such as:
- Who have met sales targets and who have not for this month/quarter/year?
- How consistently has a sales representative been able to keep up with the goal?
- Top or bottom performers in a specific category such as product type or region.
Understanding what questions users need to answer is an essential step to designing meaningful visualizations and storyboards.
3. Understand users’ workflow
After identifying the user’s goal, we need to ask about the current path user takes to achieve it. This end-to-end process starts with the trigger, initiation of seeking out information, and ends with the final accomplishment. Analyzing this flow means we’re looking into the details of the user’s decision-making process. A dashboard or report is an information portal and just a part of this process. The structure and interaction within the dashboard need to closely align with this workflow so that the user can find the information they need as quickly as possible. Knowing what triggers him to seek out answers from the data will give us an insight into the context the user has in mind. As a routine, does the user look at the dashboard on a weekly, daily or monthly basis? Or, is it after receiving an alert from someone else? This context will help us prioritize the information or messages that are most important to users.
The second aspect of analyzing the user’s workflow is to identify which steps directly contribute to users’ decision-making process, which steps are friction and should be eliminated. Here, we can quantify the values of our solution by specifying how many steps it can save the user.
4. Understand users’ problems
People love talking about their problems. That is an opportunity to get users engaged by focusing on solving their most critical pain points. Make sure the problems are directly related to achieving users’ goals. For each problem, we need to evaluate the feasibility of solving it: the resource, technical and time constraints. Then we can prioritize our solutions within the scope of the current project. These problems can include:
- Users don’t trust the data they see (data integrity)
- It takes a long time to get what they want
- Manual manipulation of data is involved and is difficult to validate
As we lay out the plan to take away users’ pain, they will recognize the benefits instantly. Users might not see the potential values of new features yet, but they can feel the relief from solving current problems. Getting user excited about the values of the project will motivate them to stay engaged and be more open to sharing their thought process and feedback.
5. Write a user story
It’s time to consolidate everything you have learned about your user in a story. For each target audience of your dashboard, write a story about a user and the journey to accomplish his goals. Let this hero have a name (make sure no one is uncomfortable with the choice of the name) to make it specific and relatable, then describe every possible scenario that our hero might encounter.
An example story about how a test engineer does his job
Mark, a Test Engineer is notified by the QA manager of test code that it is affecting a production line (Trigger). He needs to investigate the history of occurrence for this test code on this production line. Mark needs to know how often this failure has occurred. Then he opens the scope of the search to other product lines and parts. Within each test code, there are many different descriptions of the problem. Mark needs to find out which are the most frequent ones and how these issues have been addressed in the past (Status: fixed or not fixed). After understanding the issue, Mark summarizes his findings and proposes a solution to his manager.
A story like this will help users get into the right mindset, better visualize their workflow, and give you more meaningful feedback on how to improve the process. Therefore, the story should be specific and relatable to users.
To finish the meeting, summarize your findings of users’ story and make sure everyone agrees on them:
- The target audience for the dashboard, their roles and responsibilities (who are the users?)
- Main goals that can be accomplished with the dashboard (by the target group of users)
- Questions users need to answer to achieve those goals
- Current workflows followed by users to solve the above questions
All these findings will not only provide a concrete blueprint for your dashboard but also help evaluate the values of the final product. During user acceptance testing, users will assess the proposed values:
- Can I accomplish my goal with the tool?
- Does the tool help improve my workflow?
- Does the tool solve the most critical problems I have?
The six steps above align with the principle of design thinking or human-centered design. This approach focuses on discovering and solving people’s problem by collaborating, iterating and visualizing.
Reach out to us for a Design Session here.