Before you read my blog comments, take a minute to sign up for my upcoming Webinar about The Right Way to Do Mobile BI. Click here to register for this informative Webinar on September 5.
Recently I was at a client site discussing the impressive adoption rate of a Mobile BI project that had just gone into production compared to some previous similar projects that had not fared as well. As we white-boarded the particulars of each application’s adoption, we realized that the main difference was how each project had come to be in the first place.
The lackluster projects had started as a request to ‘mobilize’ an existing set of reports in an effort to give the users in the field another option in terms of delivery method. The successful project was a completely new reporting request. Once we realized this important difference, the applications themselves began to take on a different look and feel. Clearly, the successful application was “better” because it was designed to take much more advantage of the capabilities offered by the Mobile BI platform being used.
As I thought about this over the past few weeks, I thought back to the other Mobile BI projects that I have seen and quickly realized that all too often the BI community is failing to understand that we are in the midst of a paradigm shift.
I believe that Mobile BI is often a perceived as shortcut to providing ‘value’ or ‘improved ROI’ for the majority of those who implement it because, if we’re being honest, the idea of taking an existing report and delivering it on an iPad seems like a ‘can’t lose’ scenario. We’re delivering a report that likely already has proven valuable in a medium that is exciting and easy to sell. Who wouldn’t go for this approach? Unfortunately this often leads to overlooking the unique experience that can be offered on a mobile device because proper development requires more time and effort to rework and retest past efforts. Most Mobile BI platforms provide features developed specifically for mobile purposes that we, as developers, should be more open to incorporating into our application designs.
So, while it is wonderful that there are new widgets to incorporate in our Mobile apps – what does that have to do with adoption and project success? If we look at the environment where mobile apps compete for user’s attention, it turns out there is more to proper development than you might think. Take the iPad home screen where our business customer launches our application for instance. What other apps does this person have surrounding our little icon? The vast majority of these icons have been developed solely to be accessed from a mobile device and have had hours of design and user testing focused on them before being released. The icon may not have anything to do with BI, but does it matter to our casual business end user?
The bar for the look, feel and usage of our mobile BI apps has been set by the high quality mobile applications they use all day long. If our users move from a slick app such as Facebook to our Mobile BI app, we need to ensure we have put some adequate time and effort into providing more than just a grid report on a small, mobile screen.
Beyond the immediate visual impact we have to provide is the subconscious sense of trust that is instilled in us when we use a quality application (mobile or not). A user is more likely to want to use our application when they feel like the developers “cared” about developing it for them by doing their homework and working hard to make it usable. Some might argue that we’re comparing apples to oranges: Facebook is a recreational app while our Mobile BI app is something our user HAS to use because it’s part of their job. Maybe, but as BI becomes increasingly pervasive in business life we would all prefer that the email we get from customers be about the next big mobile project they just can’t wait to get underway instead of complaints about why their mobile app usage is so pitiful.