Designing Business Intelligence: Users and Stakeholders

Watch this. No seriously, go watch that video and then come back. Don’t worry, I’ll still be here…

While recently watching that TED talk presented by Timothy Prestero, I was again reminded of something that I learned from Blair Wheadon while working as a product manager for Crystal Reports @ SAP: It is important to clearly define not only who is going to use your product, but also who is going to select it and who is going to pay for it. Timothy repeats this while talking about his quest for developing medical equipment for children in developing countries by using the sentence: “Who would use, choose, and pay the dues for your product.”

In my last blog on my personal site, I talked about the need to determine for whom you are creating your Business Intelligence solution. I also talked about how you can just get real YouTube subscribers from places like themarketingheaven.com. While defining the persona, it is not only important to define who is going to be using your BI services. As mentioned above, it is also important to define who the decision makers will be for choosing to use your defined BI solution over acquiring or building their own. Along with this comes the need to define who will be paying for the BI solution once they have decided to use what you’ve designed. While this may not be critical during the phase of actually designing the content, it is important when you start defining how you are going to charge your businesses for providing them with a service or what may be important in a BI solution so that you can ease your own administrative and maintenance tasks.

Design for Outcomes

Taking the first one into consideration, you have to be prepared to not just lead with the flashy visualizations. You need to deliver useful information that is delivered via a reliable platform. Seems obvious doesn’t it? Unfortunately, when talking to those within the business community who want the BI solution (and, in reality, may be funding it), they want to see the new features. They want the flashy content. They want the pretty charts. As someone who is designing and delivering a BI solution, it is easy to get caught up in moving to the next big platform and using that brand new visualization or new feature without really thinking through how it is going to help the user community. It may be great that you can how use a box plot with WebIntelligence in BI 4.0, but do you really understand how to use that type of visualization? Do your users really understand how to read it? The same can be said for using a flashy dashboard tool. Sure, it can be a great way to get leadership or business users excited about BI content, but do you want to get them excited about something flashy or do you want them excited about being able to make decisions faster? Taking Timothy’s advice of designing for outcomes can be leveraged when designing a BI solution by considering the longevity of not only the platform upon which you are basing your BI solution, but also the content you plan to build and how you plan to deliver information. In return, you will not only have a happier user community, but the ROI for those who selected and paid for the solution will be greater.

Design for Manufacture or Distribution

The second consideration may seem useless when talking about a BI solution, but it can still apply. You just need to tweak it a bit. Rather than designing for “manufacture or distribution” what about designing for information creation and distribution. Those users who are viewing content are not the only important users. You must have content created and you must determine how you are going to distribution information based upon that content. Will your content creators be more productive with the WebIntelligence Rich Client on their desktop or is it enough to let them design in a browser? How will you enable your content creators to collaborate on the creation of new content? Will SAP StreamWork be useful for this or is there another way to make it easier to collaborate? How do you plan to distribute information? Are users okay with logging into a portal or do they want information sent to them?

Design for Actual Use

This leads us into the next point…you need to design for actual use versus ideal use. In my mind, this always leads me to consider one very important point: your users do not care that you have chosen a BI solution. They don’t care that they using SAP BusinessObjects, IBM Cognos, Tableau, etc…. They don’t care if you’ve chosen to use WebIntelligence over Desktop Intelligence or Dashboard Design over Explorer. They care about getting the information that they want and moving on. For some users, this means sending them information to their email at 8AM every morning. For others, it means sending them an alert to their iPhone when a trigger or event occurs. It is important to really understand not only what information the users need, but how they will actually be using it. What about the all too frequent case where users take reports, download them into Excel, and do their analysis? Every BI deployment with which I’ve interacted has these users. Does this mean that you should stop that behavior immediately by turning off downloads and forcing users to do their analysis in WebIntelligence? My suggestion is no. You should understand why they are downloading to Excel. What does Excel give them that WebIntelligence or Explorer does not? What are they doing with the information that requires the download to Excel? In this way, you are truly designing for actual use rather than whatever ideal situation you envisioned when you got excited about all of the great possibilities your chosen BI platform could deliver.

Design for Appearances

The final point made by Timothy is an important one and may seem to contrast with the first point. Appearances do matter. Does this mean you should include all the flash and bling that comes along with some BI tools? No. It does mean that you must give users something that looks modern. The tool AND the content it creates must look like something with which they are familiar. If not, they will not want to use it and they will not get excited about it. Do the majority of user community and your stakeholders use Facebook or Twitter? Great! What about looking at the design elements of those services and using some of them when designing your content or choosing your BI solution? This could be the blatant use of white space. It could be stark colors. It could even mean going so far as to implement a social framework by which your users can collaborate on interpreting and suggesting improvements for the content that you are delivering. The key here is really understanding your user community and those who are purchasing the solution. If they are frequent users of Facebook, Google, Twitter, LinkedIn, etc…and you give them a product that looks like it was released in the early 90’s…they won’t be happy.

While many of the points above may seem focused on the actual users of a solution, remember that it’s not just about them. If those individuals selecting and paying for a BI solution can’t get excited about it, then it probably won’t get selected. If by some chance it does, then their lack of excitement will translate into a lack of support after the purchase has been made.

Thanks for reading.

Coy