Derek's Hierarchy of App Needs | webOS Nation

Derek's Hierarchy of App Needs

by Derek Kessler Tue, 25 Jan 2011 5:01 pm EST

Recent discussions on Twitter and elsewhere have prompted me to take a look at what I view as being important in software design. I’m not a programmer by any stretch of the imagination - I can barely hack my way around an HTML table, let alone code a working app. What I am is a user, and I look at app design through that lens. What is important to me may not be important to you.

The discussion in question revolved around discoverability and intuitiveness, which led me to think about what else is important for a successful app. I’m not going to look at marketing or competition in this piece - this is a focused look at what it takes to make a good app, and I call it Derek’s Hierarchy of App Needs.

I’ve taken inspiration from two sources: Abraham Maslow and Kevin Michaluk. Maslow, as you may or may not be aware, was the creator of the hierarchy of needs (popularly illustrated as a pyramid), a theory of psychology he introduced in 1943 to help explain the development of personality and motivation. (I’m as much a psychologist as I am a developer). Kevin you may know as the editor of our network sister site, and it was his Hierarchy of Smartphone Needs that gave me the gumption to try this myself.

According to Maslow’s theory, there are certain needs that must be met for an individual to progress further along the hierarchy of needs. For instance, the need for food, shelter, and water takes precedence over intimacy, respect, and morality. The pyramid presentation of the hierarchy sets the basic needs (sustenance, shelter, etc) as the base of the pyramid, with each successive layer built upon the success of the prior. As with all of psychology, this is a theory and not a law, and there are plenty of things to critique about Maslow’s hierarchy. Whether or not you agree with the concept of a hierarchy of needs or Maslow’s grouping and ordering, his theory and Kevin’s excellent smartphone adaptation have prompted me to recognize that there is a similar hierarchy of needs for apps.

Derek’s Hierarchy of App Needs

At the top of this article you’ll find my app-oriented interpretation of Maslow’s hierarchy. It’s a summary, but is read from bottom to top (as a pyramid is built). Below I’m going to take an in-depth look at each level, working from the base to the tip.

1. Functionality: Above all else an app must be functional. If the app simply doesn’t work, then it’s not going to be of use to anybody. Functionality is not a function of how easy it is to use - it’s a function of the app’s ability to do what it was designed and described to do, as well as being capable of doing what users expect it to do. If it can’t do that, then it’s going to fail - that's why this is the base of the pyramid. Additionally, functionality must be maintained in the face of changing services. The timeliness of updates is key to maintaining functionality - even a day’s worth of downtime due to a late update to address a changed API will shake a user’s confidence in the app and the developer.

2. Efficiency: After achieving functional status, an app must be efficient. Efficiency has many aspects, both user-facing and behind the scenes. As I said before, I’m no developer, but I know enough to know that a poorly coded app is an inefficient app, just as a poorly written article is not a good article, no matter how great the content. Sloppy coding makes for difficult updates, complicating both the time required to correct errors and implement new features, as well as dealing with changing systems. Inefficient coding also wastes CPU cycles, thus consuming more power and shortening battery life, while making the user wait longer for an action to be completed. Efficiency’s user-facing component with regards to the interface: actions must be able to be completed as quickly and with as few steps as is reasonable. For complex apps, achieving an efficient user interface is a balancing act that must prioritize common actions over the lesser used, while still providing easy access to the latter.

3. Intuitiveness: It must be clear to the user how the app works. While some apps may require a tutorial on first launch to explain how it works, for an app that was designed to accomplish a goal one must question if an app with a tutorial may have been overdesigned. Intuitiveness is built heavily upon user interface efficiency: basic functions of an app must be readily apparent, while more advanced features should be easily discoverable. The usage of gestures, key combinations, menus, icons, etc. must simply make sense both with regards to the operating system’s paradigms and the expectations of the user. Apps should not pander to the lowest common denominator, nor should they require a master’s degree in rocket surgery to operate. Additionally, an app must be consistent within itself with the use of colors, icons, and menus and the locations of common controls.

4. Customizability: With the base of the hierarchy pyramid satisfied, one moves to levels that may be considered optional, and depending on the app may not even be necessary. Customization is a tricky slope to climb, just as self-esteem is in Maslow’s hierarchy. Developers need to balance a user’s desire for making an app “their own” with the developer’s own desire for the app to be used as conceived. Customizability also affords the developer the opportunity to offer additional options to more advanced users. Customizability is of significant importance for apps that make use of background services. The option to adjust how often an and what app does in the background reflects back to the app’s efficiency and the user’s desire for a pleasant and efficient experience when using the app in question as well as other apps.

5. Attractiveness: Only once the groundwork for functionality, efficiency, intuitiveness, and customizability has been laid can the issue of attractiveness be broached. While an attractive app is admittedly pleasing to use and easier to market, a pretty app with a poor interface and slow operation will not be a successful app in the long term. By and large, smartphones and tablet users are mobile and an easy-to-use app is of importance. It’s acceptable for desktop applications to have less-than-stellar interfaces because the user is generally seated and using a cursor interface to interact with the computer. For most developers it will be difficult to predict under what conditions an app will be used and how much of the user’s attention the app will have. Thus it is important that it be a functional app before it is a pretty app. Even so, it’s a basic human desire to not want to look at things that aren’t pretty. It’s one of the reasons we have windows in our homes and offices. Many apps that are fully functional have been passed over because of the lack of attractiveness, but oftentimes the ugly factor is an extension of a poorly designed (i.e. neither efficient nor intuitive) interface.

So why does this all matter?

As with all hierarchies, it is possible to achieve certain levels of success without having mastered the lower levels. Apple’s iPhone was an enormous success due to its attractive and intuitive interface, despite the lack of customizability (at least initially). Contrastingly, the Universal Search feature of webOS was underused by the general webOS userbase due to its lack of discoverability (intuitiveness), and was rebranded as Just Type and given a easily discovered and explained search box on the webOS home screen.

It’s important for us as passionate smartphone enthusiasts to take a step back and look at our apps and how we use them to ask ourselves if we are doing it correctly. In the long run, apps have a tendency to sort themselves naturally based on the hierarchy. But it stands as a guide for both the developer and the user as to what makes a quality app. Every developer will have to interpret the hierarchy differently for every app, as the purpose of the app will determine which levels are the most important. But the process of achieving a whole and functional app from conception to release stands: a good architect designs from the ground up, building a foundation upon which to place rooms with a logical layout and flexible functions. Only once the bones are in place can the work of making it look good happen.