.png)
Making reports look good isn't optional - it's a must. I’ve learned this from years of building reporting solutions. Why? Well, here are a few key reasons:
- First impressions matter
- It boosts adoption
- If it's unattractive or confusing, no one will use it
- People genuinely get excited about using a well-designed solution
However, we can’t forget that the KPIs must be meaningful and closely aligned with real business objectives or challenges. If we don’t have this, if we haven’t gathered the right requirements, it doesn’t matter how pretty your reports are, I promise you they will get BINNED!
Too often, we rush through design and development without pausing to consider the value we’re supposed to deliver. How can we know if we’re on track to hitting our goals or at least heading in the right direction without a solid set of KPIs? They help us measure progress and understand when it' time to panic to make the right changes.
👉 Running a business without KPIs is like sailing a ship without a compass - you’re moving, but have no idea if you’re heading in the right direction. Eventually, you're bound to hit trouble - GPT gave me this simile 😉
So, here are some steps to follow:
1. Ask the Right People
Who are you building the report for? Whoever it is, ask them. They’re the best people to tell you how they track progress towards their goals and tackle their challenges. Some might say, "But they’re not senior enough to set the KPIs in the first place!" Well, that’s a whole different issue. If KPIs don’t exist in the organisation, that’s a conversation that needs to happen at a higher level and fast.
But if people are working in an organisation, chances are, they’ve got some sort of targets or goals, right? So, no one is better equipped to tell you what’s going on than the ones actually tracking the KPIs.
Now, here’s what I hear REGULARLY: They’re not senior enough… they’re too junior… someone higher up says, "I can tell you everything you need"… they’re too busy. Honestly, the list is endless. This kind of talk worries me! My advice? Speak directly to the people who are actually going to be using the solution. Not possible, raise it as a risk… I sure do! But start from here!
2. Business Objective or Business Challenge
Where are you trying to go? What are you trying to do? Now that you've got the people we're building the report for, it’s time to ask them about their pain points. What worries them? What tools would help them do their job better if they had access to them?
Why start here? Well, if you’ve got a clear objective, it helps in a few ways. First, it stops us from collecting 50 KPIs. This focus ensures we zero in on a single objective or challenge, which then drives the selection of the KPIs. If a KPI doesn’t directly impact the business goal we’re aiming for, it gets pushed out. No need to let pointless KPIs steal valuable screen space and attention from what really matters… The business objective… The business challenge… Business being the keyword.
Second, it makes sure there’s a TRUE need for the report in the first place. I'll be honest, when I get to this stage in a reporting project, I have specific questions I like to ask, but they change based on the end-users. Never the same - you just need to learn to ask right questions which comes with practice. The key thing is, if they can’t point to a real business objective or challenge that the solution will help them with… should we really be spending time/money/effort on this?
👉 I recently saw a few posts/comments/conversations on LinkedIn dismissing dashboards due to them not being used. Dashboards aren't the problem, it’s the questions we ask at the beginning to get a solid understanding of what we are building and if it's truly needed.
Finally, it prevents a very common problem I run into… Being handed a long list of KPIs and being told, “We’ve got them ready for you, no workshop needed.” This one really gets to me 🤦 Sure, I’m all for getting things prepped upfront, but just because we have a list of KPIs doesn’t mean we should slap them all onto a single report canvas.
3. Derive KPIs
While we look at the Business Objective we want to achieve or the Business Challenge we want to overcome, let’s ask ourselves how do we know if we’re moving towards those goals or away from them? If senior leadership asks for an update, what numbers would we need to give them?
From my experience, when running workshops with users who can provide a business objective or challenge, they’re often able to provide relevant KPIs as well. If KPIs aren’t being provided, I’d start to worry. Seriously, ask why aren’t KPIs relevant to this solution? If you have a clear objective and stand by it, how can you know if you’re moving towards it without KPIs?
Also, if the goal is to "Increase sales by 10% by the end of FY 2024," your KPI can’t just be something broad like "Sales" or "Footfall/Visits." A KPI is an actual value versus some target value. As Stephen Few says, context is key, otherwise, how do we know if something’s positive or negative?
Also, I often see online that people suggest a target should be 8.5%, 15%, or setting precise targets in the workshop like 20K, etc. In my experience, depending on the industry and the end-users, this level of precision is usually unrealistic. So, at the very least, compare your KPIs to last year (LY), forecast, or previously set targets. I’m all for keeping things SMART, but sometimes, things get missed and that’s okay.
👉 The point I’m making is, we don’t always work in ideal conditions. Do the above, and your reports will be better off.
4. Where is the data?
Up until now, I haven’t mentioned anything about actual data. Why? Well, I picked this from Mico Yuk (one of my favourite people in the industry and my go-to for topics like this). After running many workshops to gather KPIs - some good, and some not so good, I now make it a point not to talk about data when we’re collecting KPIs in the initial workshops. Sounds crazy, right?! But here’s the upside, with a real example to back it up.
It opens up conversations that may have never happened. It forces us to think about what we need to achieve the business objective or overcome the challenge. The tech or the data isn’t holding us back. Yes, some people might question this approach during workshops or planning, but what I always say is: there will be a time to see what’s available and what’s not. Just set that expectation from the start.
In one case with a client, guess what happened? We discovered what would really be valuable, and after a quick check, we found that with a little extra effort, we could start tracking the requested KPI. Total gold! If we started with only what we have available, this would not have been the case. But again, after working through the process above, make sure to reserve time to see what’s possible and plan things out in phases.
5. Approval
Once you’ve gathered everything, make sure to summarise, clean it up, and send it back to the group you collected it from. They must approve it before moving on to the next step. Workshop fatigue and saying the wrong things (I’m guilty of this!) are real issues, so it’s only fair to send it back for review.
Plus, I have to admit, it helps hold people a bit more accountable. I can’t count the number of times I’ve collected requirements or KPIs, and when we move on to design or development (depending on the scenario), the end-users are suddenly like, “Ummmmmm…” Not good! It’s not fair on the ones conducting the workshops and gathering the requirements, to end up in this position and to have the fault.
6. After Go Live
Once you progress through the relevant other stages, model design/build, wireframing, development, GO LIVE… We must give the users some time, and set up a follow up meeting to ask how they are getting on. Are the KPIs being tracked, what actions have come out of the solution. If none… WHY? Also, are the KPIs still relevant or has the organsiation, team, function shifted priorities elsewhere and an update is required.
Once you’ve gone through the other key stages such as model design/build, wireframing, development, GO LIVE… it’s crucial to give users some time and then set up a follow-up meeting to check in. How are they getting on? Are the KPIs being tracked? What actions have come from the solution? If none… WHY? Also, are the KPIs still relevant, or has the organisation, team, or function shifted priorities elsewhere, meaning an update is needed?
Summary
More time should be spent talking to the actual end-users of the solution. We need to ask more tailored questions to ensure the solution we’re creating delivers real value. I keep hearing people say dashboards are destined for the bin, but it’s not the dashboard itself, it’s what we put on the canvas. And that comes down to gathering the right requirements, nailing the KPIs, and understanding their true purpose.
