How to gather requirements - Storyboarding

One of the biggest challenges in building a report for an end user is extracting their requirements. When we ask users “what do you want to see?” typically one of two situations occur:

• The user isn’t sure and asks the report developer to come up with something first. Once that prototype is put in front of them, they realise that isn’t quite what they need and proceed to ask for changes until, bit by bit, we edge closer towards what’s needed.

• The user knows exactly what they need and prescriptively goes through every single visual on every single page describing in explicit detail what should be built, despite the fact they have no experience in data visualisation and the report also needs to be used by five other people.

The first situation is more common in my experience, and while slow, does get us generally towards a report that is acceptable and fi for purpose. The second situation might seem ideal but is actually more difficult. It can require a great deal of convincing that “no, a pie chart isn’t actually the best visual for this use case”, and disentangling why the user wants these particular visuals.

In reality, these issues are our fault. Our initial question was far too open-ended and provides the user too much freedom, resulting either in decision paralysis or a power trip.

We need a way to work out what our users need to see and why they need to see it, but in a focused structure that avoids the issues above.

User Stories

User stories seem like a good fit here. For anyone that isn’t aware, user stories have the following structure:

As a <user> I need to see <requirement> so that I can perform <action>

They provide a more structured way for our users to indicate what they need. In fact, a common recommendation is for users to write them themselves, often on sticky notes, collaborating with other colleagues and sticking them to a wall. This however, isn’t always a workable idea in practice; I was once working with a Police force who informed me that previous consultant had come in and tried to ask a Chief Inspector to get up and write out some user stories on sticky notes. This did not go down particularly well with the Chief Inspector, who flat-out refused to participate in the session.

User stories also let us split our requirements by groups of users thereby helping us to determine how to group our visuals, and they provide us with a reason for the requirement so as report developers we know what to highlight in our visuals.

The main issue I have with user stories however, is the lack of structure between stories. How do we know how they fit together? What’s their priority? Does every requirement have an associated action, or is it a combination of multiple requirements?

Even if we assign a priority using numbers or use MoSCoW, I still think we can do better.

Adding structure

I like to start requirements sessions by outlining the business’s objectives for the area and users we’re talking about. Take the following example for a Marketing Manager at a charity:

This us a great starting point to ask more specific questions. For the example above, we can take the first objective and write down the obvious question:

Next, we ask our users what answers this question. Typically, this would be a measure compared to something, or broken down by something. For example the answers to the above question could be:

We need to ask questions like:

• Do you have any KPIs (Key Performance Indicators) for this objective?

• Do you have any targets for this measure or KPI?

• What time period is significant or useful for comparisons?

• What context is needed for this number?

We need to be careful not to jump to the answer too soon. I often see business analysts capture user stories such as:

This misses the important context of why the user needs to see the number of Members, and also fails to capture the situation where a question is answered by a combination of multiple measures or KPIs. Instead, we simply get a list of measures.

Once we have captured our question and answers, we need to find out what comes next.

I like to ask questions like:

• If this measure is up/down then what would your next question be?

• If the measure is low/high for a particular category then what would you want to know about that category?

We then repeat the above process for the next question our user has, and capture what answers it.

This is the key bit - by linking user stories to each other we are mapping out how our users think about their data. This means we can now build our report to match our users’ thought process, highlighting the information they need and guiding them to the next answer intuitively.

We can even start to work out how to navigate between answers. A single pathway leading to a one measure answer might best suit a tooltip, whereas multiple branches, measures, or categories probably needs something more significant (like a drill-through to a new page).

How does it end? What do we do when our users have no further questions? Well we need to ensure we aren’t just performing analysis for the sake of it. Our users need to do something with the information we provide.

Therefore, we need to ask them: What decision or action would you take with that information? This could be anything from talking to a colleague, applying a discount to a product, or cancelling a contract.

Once we reach the end of a path, we go back one user story at a time and determine if there are any other possible analytical paths. This gives us a web of questions, answers, and actions that maps our user’s thought process.

But how do we deal with multiple groups of users?

User groups

It’s rare that only one group of users need to analyse a dataset. More likely, multiple groups of users will have similar but slightly different requirements from the same set of data.

Expanding our Membership example from above:

As we can see the Donations team share the first two objectives, but have a different third objective. We will still perform the same process with the Donations team as we did with the Marketing Manager, but where user stories are shared between multiple groups we can use colours to signify which user stories belong to which user groups.

Conclusion

I think this storyboarding method provides a clear, logical way to capture and structure our users’ requirements.

• Context. The question and answer structure provides context for every measure, helping us determine not only what visualisation to use, but what to highlight, what sort order to use, and what comparisons are most useful.

• Navigation. Linking the questions in analytic paths helps us to determine the order in which visuals should appear, and the size of subsequent question and answer cards makes it easier to know whether a tooltip, bookmark, or drill-through will be more appropriate.

• Action. Having all our analytic paths end in a decision or action ensures we’re not performing analysis for the sake of it. Instead, we know we’re building a tool that will directly help our users perform their jobs.

Another benefit of this method is that it’s focused around a business process (e.g. Charity Memberships) rather than a specific report. By gathering requirements at this higher level, we can determine what individual reports are required for this area by examining groups of analytic paths. If there’s no crossover between two groups of analytic paths and user groups, then we should be building two separate reports.

This is the method I’ve found most effective when gathering requirements for analytic reports, but is obviously a bit overkill for simple, tabular operational reports. There are plenty of other methods I’ve seen work for analytic reports, so let me know if there’s one you prefer or your thoughts on my methodology in the comments.