Milbery’s “Maslow” hierarchy of application needs

Almost everybody is familiar with Abraham Maslow’s famous paper outlining the various levels of human motivations.Maslow’s hierarchy is built as a pyramid, with its foundation based on physical needs: food, water, and oxygen. The second layer is safety and security. Next up is love and belonging, followed by esteem, all leading to the top of the hierarchy—self-actualization. Whether or not you believe Maslow’s sociological framework applies to man, the hierarchy is an interesting model for application software.

I’ve developed a pyramid-shaped hierarchy of my own to outline my requirements for any application that I use or build. In a stunning display of originality, I’m calling it Milbery’s Hierarchy of Application Development Needs. I suspect that many of you will agree with the principles of my hierarchy, just as I believe that you will all disagree with their individual placement within the pyramid.

Let’s say I’m creating an airline app. Ideally, I will not advance to a new level until the preceding one is airtight. This is especially crucial with the pyramid’s base levels.

Level 1: Speed.
The foundation level of my pyramid is speed. FAST trumps everything; it overshadows the good, mitigates the bad, and forgives the ugly. Elegant design? Who cares if those elegant screens take FOREVER to load. Poor error handling? Users may overlook crashes if they can access basic services—in this case, checking a flight status—really fast. Speed. Speed. Speed. Users will tolerate applications that are clunky and offer limited functionality as long as they are FAST. Slow screens are a constant annoyance to users. If it takes two minutes to load up your flight status, what’s the point? Nothing else matters when your program/website/mobile-app isn’t fast.

Level 2: Error Handling.
The second level of my pyramid is intelligent error handling and logging. Users absolutely HATE it when things go wrong. They especially hate it when something weird happens and they don’t know the state of their work. Did I lose the order I was working on? Did the credit card transaction go through? Just what happened? If our friendly airline application consistently crashes while you are checking your flight status, you certainly are not going to want to use it to BOOK flight reservations.

Level 3: Productivity and Reasonable Defaults.
Once you’ve nailed down the first two levels, your application needs to offer productivity. A fast, error-free piece of software will limit user frustration, but if it doesn’t really offer any reasonable functionality, then there is no reason to use it. If our airline application lets you check flight status but doesn’t allow you to change flights or seats, it’s not very productive. You might not delete it from your phone, but you aren’t going to use it very often.

At this third level, applications are also equipped with reasonable defaults. The default installation is configured with the standard features and options that would appeal to most of its users. Our airline mobile application might default to sending me notifications for every flight change, including all delays, cancellations and gate changes. This would be turned on by default, so that I would not have to go hunting for these settings as soon as I start using the software. It is important to anticipate the functions users will want most, and then spare them the trouble of setting it up themselves.

Level 4: Native.
The next layer of my pyramid is the “native app” or what I call, “runs well on my platform”. Whatever the program/website/mobile-app is supposed to do, it needs to run natively on the user’s platform to be worth anything. Running on a Mac? It needs to be a native Mac Cocoa-based application.

• “Runs on a Mac via Parallels or VMware Fusion”? NOT a native application.
• A web application that uses a screen-scraper to front-end an old client/server application? Doesn’t qualify.
• An HTML5 application without an Android wrapper application on your Samsung Galaxy? Nope.

The lack of a native interface causes the user problems every day. Even simple things like cut and paste may not work. Worse, the user often has to add third-party software to make the whole thing function. Ugly. I don’t want a browser-based airline application on my iPhone. I want a native iOS application that takes advantage of the native platform features, caches my credentials, integrated with notifications, the whole shebang.

Level 5: Highly Configurable.
As we reach the top levels of the pyramid, we are reaching for perfection. At the fifth level I want my software to be configurable. In the beginning users don’t want to have to fiddle with the software to get it working, but by level five they are used to working with it and want to start making configuration changes to adapt it to the way they work. Take our airline application. Maybe the default behavior is to notify you via messaging about every flight change. After a bit you might decide that you only want to be notified if your flight is delayed by more than 15 minutes (which should eliminate a TON of messages). My Level 5 app will be able to let you easily make those changes.
Level 5 software is highly configurable, letting me change things in order to match the application to the way in which I work. Updated versions of the software maintain these customizations without forcing me to re-apply them.

Level 6: Elegant.
The highest level of the pyramid is the most difficult to describe—elegance. Elegant applications delight you in unexpected ways. They automatically adapt to the way that you use them without requiring you to manually change settings. They often provide you with a new, more efficient and appealing way of accomplishing standard tasks. They bring to mind that age-old saw —”I can’t tell you what art is, but I know it when I see it”.

Elegant isn’t some defined set of features and functions, it is deeply entwined with the software. But it can often be explained via certain features that are unique to the task at hand. If we take our fictitious airline application to Level 6, it would automatically detect when a “better” seat becomes available for me—and I mean a “better” seat according to where it knows I like to sit on planes. A truly elegant application would make the change and prompt me to approve the choice with little fanfare while giving me all of the information that I need to make a decision either way.

These are the things to consider for the mid-market company that provides software to their customers, be it web site, or desktop software or a mobile application. Level three is my absolute minimum for any “production” class software. Anything beyond level three is a true customer delight.

This is simply one man’s view of the software universe, but I challenge you to offer a better pyramid by commenting here, or hit us up on twitter @ParkerGaleCap