Recently, a client asked for a series of dashboards to help him understand certain usage trends in his company. After a detailed requirements phase, I completed the dashboard development and presented the product. Upon seeing the dashboards, he realized they didn’t quite hit the mark. Instead, he wanted some basic reports he could use for analysis.
Any gaps between developers and users can—and will—be filled with client expectations. Even weeks or months after the requirements phase ends, the user’s mind may still be churning. The user may be imagining the visual appeal of the final product, which could include drill-down capabilities, interactive graphs or automated report delivery—none of which were addressed during requirements.
The organization and presentation of reporting, as well as accompanying visuals and functionality are important components of the BI experience. How can we bridge the communication gap with our clients and produce a product that exceeds their expectations?
We need a prototype we can develop quickly to accurately represent the organization, functionality and substance of the product we believe the client has requested. BI developers have an advantage over their app developer counterparts—access to a fully functioning development application. So why not use it for some quick prototyping?
Qualities of a Good Prototype
A good prototype should:
- Be quick to develop. If your reporting prototype takes weeks to create, then its called development.
- Contain relevant data. It need not contain a complete set of data, however the data should represent elements of the information required by the client.
- Showcase BI functionality. When possible, your prototype should demonstrate some features of the BI environment that would be available in the final product (i.e., drill-through, hierarchies, etc.).
- Highlight challenges. If something will be a challenge to develop or may be confusing to the client, you should build that into the prototype which should help avoid issues later on.
During a recent engagement, my client wanted two facts combined into a single report, however the data would not support this combination without substantial transformation work. To address this challenge head on, I developed a quick prototype that highlighted the problem and like magic, all became clear.
BI Prototyping Tools
Unlike application developers, BI developers do not have a host of dedicated prototyping tools at their disposal. In the past, I have attempted to leverage flowcharts, spreadsheets and visual mock-ups as a feedback mechanism for requirements. However, these tools are all lacking in one way or another. They might represent the report structure, but not the UI. They may represent the flow of data, but fail to impart how it will be presented or how the user may interact with it.
Lately, I’ve been using data visualization applications (like Tableau and Qlik) to create my prototypes and found them to be an exceptional tool for quick prototyping that offers users access to relevant data and robust BI application features. We know that their short development cycle and data visualization features make them well suited for self-service BI, however they are not necessarily the client’s choice for enterprise BI (especially if they are already invested in another tool). We can, however, leverage the benefits of these tools to create some excellent prototypes.
Prototyping for BI requirements is now a staple of my requirements approach. It helps users and developers identify issues early on and fill requirements gaps that contribute to a smooth development cycle and a happy client.