The power of requirements gathering: Aligning analytics to user needs and business goals
 
 

The power of requirements gathering: Aligning analytics to user needs and business goals

 

What is the ultimate goal of BI (business intelligence)? Some might use analytics to make sense of all the data an organization has accumulated, letting the available data dictate the analytics assets that are created. They take a whole bunch of data, push it into a BI tool, and see what happens. Simply visualizing data doesn’t always equate to business value, though.

 

Instead, the goal of BI should be to solve business problems and meet business goals. Data analytics should be useful, actionable, and contribute business value. Developing BI from a value-driven approach can be achieved by bridging the gap between business and data science while relying on tried-and-true methods from the UX (user experience) design world.

 

How do you move away from useless charts and graphs towards powerful insights that an organization can leverage to make informed business decisions? The key is understanding what analytics insights are needed through a process called requirements gathering.

 

Gathering requirements in 7 steps:

Before design or development comes discovery, a gathering of knowledge, information, goals, and challenges. Requirements gathering is collecting all of the pieces of information that will contribute to the most effective and impactful analytics dashboards and portals. Whether developing a single chart, a BI dashboard or a BI portal, it is important to following these seven steps to gather the essential information needed

 

 

1. Identify the cast of characters

First, seek out a list of essential people whose input will determine the success of the project. Who are the end users, the executors, and the decision makers? Identify all of the participants and note their roles. In most cases, the cast will include stakeholders leading the effort, end users, executives, an IT manager, a data scientist, an analyst, a BI developer, and possibly, a consultant. Each player contributes a unique perspective, so it is important to get to know the cast. Take note of goals, willingness to participate, reluctance, or foreseen obstacles.

 

2. Start conversations (but mostly listen)

Now that the stakeholders and end users have been identified, it is time to talk to them. This is the most essential step of the requirements gathering process that will provide the information needed to move forward. This information can be gathered either through one-on-one, structured Interviews, through group workshops or both.

 

From stakeholders, understand the high-level perspective of business goals and objectives trying to be achieved through analytics. End users will provide a different perspective, answering questions about how the right analytics will provide value and efficiency in day-to-day tasks and help employees move towards achieving personal work goals. In all conversations, it is also important to extract information about current processes, challenges and potential obstacles that may come into play when developing new analytics.

 

3. Develop Personas

After talking with stakeholders and users and gathering information about needs, behaviors, goals and challenges, it is time to consolidate all of that information into a few distinct user personas. A persona is essentially a fictional character derived from real user information. One user persona could represent interview responses from multiple people in similar roles, and becomes the north-star representation of those users throughout the entire process of building analytics.

 

A stakeholder persona should focus on business value of analytics and list the top objectives and business outcomes expected from analytics insights as well as the biggest challenges to achieving those objectives. Meanwhile, a user persona would focus on current challenges of navigating an existing system from an end-user perspective. A user persona would also detail the end-user goals expected to improve day-to-day activities.

 

4. Identify Persona Questions

What are the top questions each user persona wants answered by analytics in order to improve performance? Developing these questions is an important next step to the goal of aligning user needs to the design of an analytics asset. The top persona questions can be formulated based on the goals and challenges listed in each persona. For example, a stakeholder for a HR analytics dashboard might ask how to reduce overall cost of attrition while the HR end user might ask to see a chart detailing how many people they have onboarded. These questions reveal that different user personas have different objectives when visualizing the same data.

 

5. Scenario Mapping

Get the sticky notepad ready. Scenario mapping is the process of collaboratively discussing and then mapping out step-by-step how each user persona question would be answered within a new BI dashboard. For example, could the user find answers through a KPI summary at the top of a page or will a certain type of chart be needed? What steps will the user take to find the information they need, and what are the actions they will take to remedy a problem? This exercise is a great way to verify that the new analytics insights will actually be discoverable, useful and be a tool for solving business problems. Because scenario mapping walks through a series of events in the shoes of the user personas, it forces a focus on user experience design and considers the context in which data is likely to be used.

 

6. Group similar items

Now it’s time to move from thinking in sticky note trails to determining how all of the information will be organized to serve the personas in a streamlined and user-friendly interface. Group questions and associated tasks together by similar topics, themes and personas in order to move towards organizing analytics within dashboards and tabs of a dashboard. From these groupings, questions will begin to emerge about whether separate dashboards are needed for each persona, if topics can be separated by tabs, or if a blended view of charts and KPIs is the best approach. The process of grouping sets up the taxonomy of analytical assets and sets the stage for a unified and simplistic navigation flow in the design phase.

 

7. Data Check

The last step becomes the moment of truth. Can the existing data actually support the analytics needed to benefit the organization? Check each persona question against the current data and determine whether the data can reliably answer the questions. In order to ensure end-user confidence in the analytics, the data must be available, of good quality and have sufficient velocity.

 

If there are questions that can’t be answered with current data, plan to answer those in later versions of your BI dashboard. A realistic view of V1 will begin to emerge, and goals can be set for evolving data gathering needs for future versions. Use this opportunity to discuss with the stakeholders whether they want to make the data investments to be able to answer those unresolved questions in the future.

 

 

These seven steps of requirements gathering are essential for answering the question – What are the most valuable analytics needed for end-user and overall business success? Once that question is answered, design and then development of a new BI dashboard can begin. Depending on timeline and budget, requirements gathering can entail several weeks of in-depth interviews and collaborative meetings with key players or it can happen over a 1-2-day workshop. Either way, it is important to take the time to work through all of the steps thoroughly.

 

When it comes to analytics, it is not enough to just be data-driven; it is important to be value-driven first. Aligning analytics to user and needs and business goals will lead to actionable and high-value returns of BI investments.

 

 

 

Follow Nicholas Kelly on LinkedIn

 

 

 

 

I'd like to schedule a complimentary 2 hour training to learn the dashboard design process*

*Logic20/20 can conduct 2 hour training sessions in the US