Let’s deep dive into the DEFINING stage.
We will cover the process, the people and the tools that need to be involved. Note that this framework is generic, and will require adaptation to your environment (start-up vs big corporate, data-literate environment vs not…).
There is A LOT we need to know before we even talk about data. Remember what we said we need to keep top of mind? That a dashboard is meant for people to take decisions. So…let’s start by understanding
- Who is the dashboard for?
- What decision do those people need to take?
- What information do they need in order to take those decisions?
Then only we look into what data we need to pull. This might seem obvious but this is often overlooked, or done too quickly, or done assuming many answers to those questions.
Let me give an example of why this is a key step. Let’s say we want to build a sales dashboard. Is it for global management, for regional sales management or for field based individuals? Those might all work in the same department, but they have very different decisions to take, and thus will require different information. Sometimes it can be the same data but aggregated differently. And this makes a huge difference.
- Global management might need to decide which region of the world require more investment than others.
- Regional sales management might need to know if there are best practices to leverage within their sales team, or if their coaching is leading to improved outcomes.
- Sales representative might need to know which customer to focus on.
Those are all very different decisions that need to be taken. And as a consequence very different information that need to be displayed.
That exercise requires good understanding of the business, and most importantly a great dose of curiosity and emotional intelligence.
Some organizations will facilitate this part as they will be very structured and teams will have very well defined KPIs — easy. Some organizations won’t, and that’s where the fun begins!
There is a lot of talk lately about the concept of Analytics Translators, who create the bridge between the business side and the data side of organizations. This is where they can be extremely powerful. It does not have to be a role as such, depending on the size of the organization. It can also be someone from the data side who has strong emotional intelligence or someone from the business side with data knowledge.
During this phase, it is very important to involve the right people:
- stakeholder and /or executive (both in bigger organizations)
- end-user (always! ideally 2–3 of them at least)
- eventually IT, depending on the size of the organization
Once you have defined your group, then only you can start answering the questions we listed above. I recommend to run 1–1 discussions first and then gather everyone together for alignment.
During those 1–1 discussions, you should really have a discussion, and not go through the list of questions (aka no, you cannot do that through an online questionnaire!). It is key to understand where people are at, how willing they are or not to see a dashboard, what they have been looking at so far…and so on. This will enable you to understand a lot about your audience (how data literate are they, how eager are they to see something new, do they already have something they think is sufficient…?) and thus develop relevant stakeholder management strategies.
Bottom-line, you are developing a product — a data-product. And all project management and stakeholder management strategies applied in product management should also apply here.
At this stage, I like to develop a simple framework, namely a TABLE (i know, fancy, fancy!). Something that would look like this:
Ok, so that’s when we start talking about data.
Now that we know which information everyone needs, we can define what data needs to be pulled and how it needs to be aggregated for each target group.
I won’t discuss this step — we run SQL requests, check our data etc etc. You know the drill.
What is important then is to keep in mind our dashboard is meant to help people make decisions! So how do we ensure it does?
What is really key here is user feedback. What I like to do is to build a prototype (more on that in the tools section) and then do some user-testing. As you have defined what decisions need to be taken, you can get straight into assessment, provide your prototype to a few end-users (separately) and ask them to take some decisions that were listed.
- It doesn’t work? Back to work.
- It works but it is complicated? Back to work?
- Works easy? Great!
It usually takes a few iterations until you get it 100% right. It’s ok.
Here again, curiosity and emotional intelligence are key.
Beyond assessing that end-users are able to make decisions based on the prototype, it is also key to assess whether they can do that in real life.
Yes, you know, in their usual habitat. Their office, their car…wherever they have to.
We could have lengthy discussions here on what is the right tool for prototypes.
I personally like doing them in excel or google sheet — just because it sets expectations it is a prototype and people will be less inclined to provide detailed feedback on the layout, colors and so on. At this stage, it isn’t the point really. This comes later.
Once the prototype is stable, then I move to the Bi tool (Tableau, Power Bi, QuickSight…whatever you use) and we do a second round of user feedbacks, focused on layout details.
And then — we’re done!