BI Like StarCraft
The interface between a user and the functionality a software solution provides is critical. I’ve presented software of my design to med device, pharmaceutical, banking, entertainment and consumer packaged goods companies, and if I’ve done a good job, the feedback tends to include the comment “that is so much easier to use than x’s”, where “x” is the competitor. I focus on simplicity, I focus on the bare essentials of solving specific problems faced by my customers. This doesn’t mean I deliver under-powered solutions, it means I deliver front-and-center the functionality that will be used 85% of the time, and shift the rest elsewhere in the experience.
What is my guiding principle? Pretend I’m building a game.
Why can my 8 year old create armies and buildings that have specific build orders and interrelationships with each other, create multi-step workflows and battle plans, but most adults struggle with adding an order in SAP? Why can my 10 year old manage the intricacies of building up the economy of a city that she created, but a veteran subject matter expert has difficulty creating a customized bar chart in leading BI tools?
There are deep usability flaws in many enterprise and niche software solutions. Many developers confuse a complex information hierarchy with a positive marketing image — they think, “the more I put on this screen, the more robust the app will look.” By throwing everything on the screen, it looks like it has twice the functionality of a cleaner-looking competitor. I’ve been a victim of this myself — I’ve bought backup software that looks like it belongs at NASA Mission Control, only to ultimately replace it with one that essentially says “Click Here to Back Up”.
Where games succeed at creating simple interfaces to processes that are often far more complicated than a typical business process is in the presentation of an appropriate information hierarchy. The graphic design — the use of colors, images, shadows, placement, text — draws the users attention to where it needs to be. Navigational elements such as menus and buttons will clearly identify where users can go deeper into other functionality based on where they’ve navigated, sensitive to the context that the user has placed themselves in, and with a clear path back. Targets for physical interactions such as mouse-overs, clicks, swipes and taps are obvious. Feedback is constantly provided — if something is going to be less than instantaneous, there will be some indication that you are being asked to wait, whether it is a busy cursor, a semi-opaque screen overlay or a well-placed but non-obtrusive message, so the user can continue viewing the screen while they wait. Games take advantage of asynchronous processes, so that the user’s time is not completely wasted while they wait for something to happen. Features that are not usable based on the user’s context are minimized, if not outright hidden in the information hierarchy.
Build your apps as if you were building a game — games succeed in delivering complex functionality in packages consumed by children.
Rip apart the functional requirements, and assign each one a relative factor of frequency of use and of detail granularity — and build your solution based on those frequencies. Build relationships between those functions — one-to-one, one-to-many, many-to-one, many-to-many — and put together an appropriate information hierarchy that will let users move seamlessly from higher frequency, front-and-center features to related but less-used (or more detailed) functions.
If you start thinking about apps as games, you are on the path to creating compelling and inviting user experiences that will differentiate you from your competition in the most significant of ways — making the end user feel comfortable with your software, and confident that they will be productive by using it.