The days of the humble report are surely numbered. Infographics, self-service reporting, BI dashboards and real-time analytics have usurped the humble report. Instead of knowing how many widgets we produced last month, now we want to know what the likely impact is going to be of next month’s unforeseen event on our ability to reach the financial measures of our balanced scorecard for the current financial year.
When I first began business analysis work, we’d focus intently on process and data requirements. After rounds of analysis and reviews, we’d have a detailed sense of what it is the system needs to do. In the planning we’d make some time available for designing reports towards the end of the requirements phase. We’d use this time to identify some logical counts of activity, aggregations relative to business structure, etc.
At a macro level, it is clear that our design focus was very much focused on what the system needed to do. If we got the system’s ‘what’ right, and counted those meaningfully, we’d provide handles on the levers that management needed. Or so the theory went.
Today’s designers should be focusing on a system’s ‘why’. Why does this system need to exist? Why is it important to solve this particular problem? How does solving this problem contribute to our organisation’s strategic ambition?
A top-down focus changes the design perspective entirely. The focus of the team becomes ensuring that processes and transactions are designed with an end-to-end outcome view rather than just addressing specific transactional issues. With that in mind... what does this system need to do?
An example - let’s take a point-of-sale system. It’s pretty obvious that a store needs a point-of-sale (POS) system to process transactions. Most stores stop there, roll-out any number of off-the-shelf POS solutions and don’t give it a second thought. Apple’s why is about being a disruptive innovator with a focus on simple, beautiful solutions. If you go to an Apple store, the till comes to you. If you’ve got an iTunes account, you’ll have a receipt in your inbox before you’ve even left the store.
It is my fervent hope that at some point in this process, the design team said to themselves ‘How can we make this process consistent with Apple’s strategic ambition?’ shortly followed by ‘It is essential that we delight customers, how do we do that?’ Sadly, I wasn’t there to witness it but I can be sure that if they’d started with the question ‘How long do we want the average queue to be?’ the outcome would’ve been vastly different.
This post isn’t really about reports. It’s about how we’re recognising the need to flip the design process on its head. Rather than starting by identifying key transactions, we should frame a design in the context of why the solution is important. Reports are a useful metaphor because they used to measure the outputs of a process. Now we can use them as a framework for contextualising the organisation’s strategic ambitions by imagining the requisite management levers and using those to inform the design process.
An early analytics design session can even help inform the detailed process design as it will give the analysts considerable insight about what information management need. This information will ultimately need to come from somewhere within the operational processes. It should be designed-in from the outset rather than added on as an afterthought.
In this world, the reports don’t need to be an afterthought. Instead, they should demonstrate how the transactions that the system performs are / aren’t enabling the transactional performance required to meet the organisation’s strategic intention. Understanding what could affect the performance (next month’s unforeseen event) can also help design more robust processes (within reason).
There are two primary takeaways from this reflection.