We had our first client Project last week in the DSAU 17 Melbourne cohort, one of the most challenging tasks in the project is to understand client requirements.
Client requirements describe what users do with the data and dashboard.
For us, an important and difficult step in designing a dashboard is determining what the user wants it to do. Not properly defining user requirements often results in building a dashboard that is not helpful and consequently never used by users.
The first step is to gather as much information as possible from the client. It can be done in both formal and informal ways.
The critical feature of this process is that it helps the project team interview experienced project participants, stakeholders, and subject matter experts who can aid in identifying and defining the features and functions of the desired dashboard.
When holding an interview, we often expect the client to list all their requirements clearly and directly. However, many times we feel that nothing has been defined when the entire interview goes by.
What I’ve learnt from my client project experience is that a better way to capture requirements is to take note of anything the stakeholder says that could lead to a requirement, for example:
“We need …”
“It would be nice if…”
“It needs to be improved…”
“Just a thought…”
“I don’t want to lose the ability to…”
“It’d be helpful to have…”
“As an idea…”
“I’d like to see…”
“Just be careful with…”
A good analyst can listen for requirements, comments, needs, concerns, suggestions, ideas, thoughts, issues, rules, and metrics to develop a list of potential requirements. During the session, they should be captured and validated to better understand what is important and why it is necessary for the dashboard.