Build Business Apps Like Blizzard Would


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.

Game IT

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.


Job Description

Leave a comment

Post Inspired By a Rands In Repose blog.

Back Then

Here’s the thing: I’ve been in software development for 20 years. Started with client-server. I actually deployed HyperCard client-server applications at a big medical device company. Back in the day. Then, Smalltalk client-server applications at a big medical device company. Back in the day, +1. Then a brief, faintly embarrassing period of Oracle Power Objects. Same company. Back in the day, +2. Same great boss — guy wanted to try everything, every new technology that came out. And he let me play with all of it.

Then came the web, and people who got their chops coding for the web are, in my opinion, a different breed of developer. Why? Because we weren’t necessarily people who cared about how much memory a float took up compared to a long. We weren’t bits and bytes guys. Not to say we were kiddie scripters, either, and we would be offended in future job interviews when the question was “what port is typically used for telnet?” Eff you, Priceline (love the Shatner though).

The successful ones were, and are, application developers combining several areas of expertise: software development, user experience design, interaction design, graphic design. At two ends of the stack, we became HTML wizards and SQL gurus, with stuff in between.


Nowadays, I’m in charge of a Java shop. While I have some bits and bytes players, I’m trying to convert them to what I am. I don’t need to build a runtime formula evaluation tool, because I can use the hell out of JEP (and in a past life used it to build out a sweet forecasting and analytics tool that got my company bought by a bigger fish). I’m not going to build a library that converts SVG to high resolution JPEG’s, I’ll use Batik for that. This doesn’t make me a kiddie scripter, it makes me a guy that’s going to use the work of bits-and-bytes people to do my job. I’m not building the girders, I’m building the building.

And that’s what I need — guys who can build apps that work, from the ground up, that look good, and ease a user’s pain without replacing it with a steep learning curve and a thousand clicks of death.

Back Then, Again

Back in the day, we didn’t have UxD, interaction design or graphic design — at least, not people that knew jack about software. So we became those people, and the ones that were good at it built applications deployed over the web that were sexy, did their job without getting in the way of the user, and did it with a minimum of animated fire GIF’s.

Granted, we all went through our phase of using massive JPEG’s with imagemaps for clickable areas. Hell, Netscape’s first home page was one big frickin’ GIF that probably brought ISP’s down to their knees. Made the lights dim in our IT department every time someone launched their browser.

But we learned. We stopped using ;, and we did it before browsers made us stop using it. We started thinking about how the users would use the tool, and started creating pathways through the software that optimized how we wanted the chief functionality of the tool to be used. We started shifting the least-used functionality to the nether regions of the user experience, calling them into play when it looked like the user was headed in a particular direction.

We have a keen eye for what works, and what doesn’t. We get the use of color, and we know when we’re overdoing it. We know that hiring a design guy will never, ever make our stuff look worse — but we’re confident in the knowledge that it will only make it incrementally better.

And we learned by looking at things that appeal to us on the web, sites that combine aesthetics with functionality in a way that just scratches us where we itch.

And when the tablet came… Well, that was a game-shifter. Now we want to inform our desktop browser designs with the efficiencies required of us by the real estate of the tablet. And let me tell you — web sites designed for the tablet rock on the desktop. The focus on user interaction and workflow is laser-sharp. Ancillary graphics are not at a minimum — they don’t exist. The wrong use of colors and images on a tablet creates a visceral response.

The UI gets out of the way. I’m betting on a lot of desktop sites looking like tablets, and I know that I’m tasking my team to pick up on the sensibilities embodied by good tablet app designs.

Don’t Insult Us, We Who Have No Name

We get all hot and bothered when a product development guy tells us he’s putting a user experience designer on our team, some dude with earrings who’s fresh out of college with exactly 1 year of experience under his hipster belt. 1 year. 1 year and a resume that includes screenshots of his customized Yahoo-generated web site, a form that he built all by himself that emails him your contact information, and a couple of animated GIFs. And maybe an auto-playing MIDI. Points for the earrings, but it’s very nearly an insult when this guy is put on the team, and one that is short-lived.

Respect the experience. If you’ve been doing this since the web was born, and doing it successfully, and made a career out of it, you’ve earned it.

%d bloggers like this: