Derek's Hierarchy of App Needs 52

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 CrackBerry.com, 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.



























52 Comments
Glad to hear that Sprint news!
I'm not sure if that's sarcasm or not, lol.
As to my opinion, however, I agree 100% with functionality being the most important aspect in an app. However, from a user's standpoint I believe attractiveness and intuitiveness to be very important -- both are ignored far too much in the webOS app catalog. Developers think (and rightly so) that as long as their app fulfills its intended function that people will like it. Unfortunately, in the land of people addicted to special effects and instant gratification, that is not the case: the look and feel (including how intuitive the app is) of an app is highly important.
I'm not DEFENDING this situation, but I realize it IS the situation currently.
Looks sell, that's why Apple is making such a killing.
i have to agree as well, some of the apps might be functional but as far as looks go they are very generic.
Personally, my own pyramid is the exact opposite of yours. Funny that. ;)
You'd rather have a pretty app that does absolutely nothing? I are confused by your priorities.
I was kidding.
I think that the pyramid metaphor is just confusing. Attractiveness is at the top which implies that it is the most important thing. While functionality is the base which should signify that it's the most important thing but looks like it's less important since it is also on the bottom.
As he said in the article, it's based on Maslow's heirarchy of needs, in which the most primitive/simplistic needs are at the bottom and the most complex are at the top.
Generally, the lower levels must be fulfilled before the higher levels can be. In that way it does make sense. After all, you can't build a pyramid by starting with the top ;-)
(lol, I guess doing a year of management has finally paid off ... sort of)
Yes I think it has.
Or maybe Derek should turn the Pyramid up-side-down so the lame ppl can understand...lol. Its a Pyramid and you can look at those in Egypt.
So hows that iPhone working out?
jk, jk =p
Nice pyramid; I would agree with the order of every single level.
This is great, Derek. Definitely great for any developer, rookie or veteran.
Love this article! I'm down with this order except for 4 and 5. Attractiveness before customizability (both important) but I'll take attractive over customizable all things being equal.
I have to agree. If it works well like mentioned in the bottom tier of the pyramid, I'd prefer attractiveness over customization as well.
functional -> intuitive -> efficient -> attractive -> customizable
That's my order.
functional -> efficient -> intuitive -> attractive -> customizable
My logic is I would rather have a functional app than none at all. I would rather have a functional and efficient app than just a functional app, etc. However, as customizable is only important in some cases, I rank attractive over the need to customize an app (as long as it provides the other three tiers).
Mine is that more time is wasted looking for a button on a non-intuitively designed app than is wasted waiting for an inefficient app to process a request. Otherwise we agree.
Looks like the food pyramid.
I thought the same thing. Then I got hungry and had a huge sandwich. Now it just looks like a pyramid.
It's how it fits into your workflow that matters. If it's perfect out of the box, or if it requires tweaking, neither matters, as long as it works how I want somehow. Intuitivity (not 'Intuitiveness') and customizability are the same coin. Neither is really necessary. If an app is good enough, how intuitive it is doesn't really matter. How customizable it is doesn't matter, as long as it'll let me use it the one way I think it should be.
Must have been reading my mind.
Great article, Derek. An argument could be made to extend your base-level (Functionality). Not only is it important for the app to do what it was designed to do, but, equally important:
'Was it designed to meet the needs of the end-user?'
-->An app built perfectly to-spec yet missing functions people want/need is still not good enough (think the WebOS eMail or Calendar apps). No matter how efficient or pretty they are, the glaring functionality omissions will keep you from moving up the pyramid of needs.
I'm confused...Where do poultry and fish fit in your pyramid?
Intuitiveness.
Yeah...I should have known that...thanks!
I'm glad to see something like this up. I have placed many posting on the forums and here that demonstrate exact examples of what is needed. I believe if they find a combination and use some of the better applications(outside of twitter) they can create higher quality applications.
Regardless, it has come down to the development platform itself. Developers are not willing to develop on a platform that takes twice as long to produce simplified applications in developer module that is more difficult then it produces. To add to this the low number of users are difficult to overcome as well. I have been asking for the developer of WebOS platform's name or contact information as the one who is designing the platform for development is needed to be involved to move anything major forward.
For apps it may be that way, but for OSes, customization is a bit higher.
Functionality: i would add that the app also must do what the the customer wants. it may do what it is designed to do but if it doesn't do what the customer wants it's pretty useless. Like hypothetically, if an financial institution app only gave me my bank account balance but didn't allow me to trade stocks i would find it kinda useless. I think all too often an app is made but not always with a mind to what the user really wants.
oh Hai Derek I am ur biggethst FANNN I am CUTHTOMITHABLE fur ur pleathures! WhEEE Let's have a couch! A bang bang bangity bangity bang.
Well Done, Said, written and executed Derek! Agree whole heartedly!
I agree totally with your view. The problem is you can sell a program that looks nice but not one that functions great. I have been in the software development business for years and in the IT field for 30. I have seen a number of programs make money that were of no value to the user. I have also seen a number of really good programs never make a dime.
I think Attractiveness should be more important than customize-ability.
sheldon cooper would most likely disagree with you
Interesting article. From my perspective (which is not as an engineer):
1.) Attractiveness - I wish this weren't necessarily the case, but in practical application, Attractiveness is #1 by a LONG shot. You have to be able to grab someone's attention when they're looking at THOUSANDS of options competing for their time/money/interest. If you produce an unattractive app, your chances of getting that attention drop precipitously. This varies depending on what *kind* of app you're creating, but you "eat first with your eyes" - build something hideous but totally awesome, and you'll still miss most of your audience.
2.) Functionality - Already well stated, with the addition that you should be building something that people will need, or something you can easily convince them they want.
3.) Intuitiveness - While I'd probably have put this lower in the past, we've recently done a lot of user-testing on Fleck which has completely convinced me otherwise. The threshold at which a user's frustration causes them to quit is very, very low, and if a user's trying to do something but can't figure it out, they'll close your app and never open it again.
4.) Efficiency - Uses as few resources as is reasonable. User experience "efficiency" is categorized as "intuitiveness", above.
That's it, really. Not all apps need to be customizable, so it doesn't belong in the pyramid, IMO. And frankly, every app is going to have its own needs. As a game maker, my priorities are different than say, someone who's making a budget-tracking tool. I'd personally still approach it in the same way, but I can understand why someone would have a different set of priorities.
But I think the interesting comparison is the difference between what a consumer *thinks* their pyramid consists of versions what their actions tell us. :)
So would you say this pyramid is also applicable to your needs with WebOS? (or any mobile OS for that matter?)
Nicely done, Derek. Well thought out. I think I'd switch customizable and intuitive, though. I say that because the very act of customizing makes it intuitive to the person customizing it.
Ease of use is more of an issue when organizing lots of features that aren't used by most people. So it has to be intuitive to find the stuff they need amongst all the stuff they don't. Customization means I can add/change/remove stuff to fit my needs, and that makes it intuitive for me.
At that point, what needs to be intuitive is the process to customize, and then the cycle repeats... so never mind (grin)
You seem to miss the same 2 fundamentals, that most programs for webOS miss and I sincerely think this should be first priority...
1. The functionality must match or exceed "old" palmOS programs, when we talk about basic functions... As showing the priority and if there is a note in ToDo programs, just to mention two missing functions of six!
2. Smartphone have rather small screens and many heavy users work with a lot of information, so they need to see as much as possible without scrolling... So a program should first use the very limited screen space efficiently (as most apps in palmOS did) and also allow the user to set how big he want the fonts, including a matching line space...
It may look fancy with a lot of empty space everywhere, but the user should have at least 4 choices (instead of NONE now) and you need only 33% more space, for accurate finger navigation - if you have normal fingers!
I understand that this facts is something you not discover directly when you begin to use a new program, but if you really begin to use it (or try to use it) will it handicap almost everything you do!
So "Screen effectiveness and size options" should come before effective code...
And I also agree that the functionality should become what the USER want and not just match the programmers intentions...
This is great stuff, and as an old "Barney Rubble" Army Officer, I like the big rocks. Nothing does that better than a simple chart. Well presented, and an excellent evaluation tool.
I was actually thinking about this last night when I was wondering why I prefer interfacing with my Pre and Evo over using my laptop. Also, I was wondering why I really wanted a tablet. I think it comes down to the natural intuitiveness of multi-touch devices.
The only reason I can tolerate Android over WebOS is because of the widgets. Widgets are the most intuitive item on any multi-touch device. It is natural to reach out and touch soemthing when you see it. From the time we are a toddler we naturally learn to manipulate directly with our hands. Indirect manipulation becomes a learned quality, but not natural. It isn't natural to search for buttons to force manipulation.
So, before I ramble any more, I would pose a potential alterantive pyramid with intuitiveness next to functionality. Thanks for sharing this!
This post convinced me to follow you on twitter. Now watch you make a fool out of me and the first tweet I see from you has something to do with Jersey Shore...sigh.
So...what's in the tombs below the pyramid?
The Palm Folio.
Bam.
Derek: this read turned out to be not what I thought it would be.....
How about nearly the same article but prioritizing what apps and type of apps are really needed to propel webOS forward...
ie. Document/Office compatability and editing for true business use....
Logmein ignition would be awesome....
major entertainment apps like netflix and sling
speech to text services
etc. you know better that I
Yeah, Derek, quit fussing around and do some real work for a change!
Umm, is this stuff gonna be on the final?
They have you covered with Typography, seeing how there's only one standard font on webOS (which is a great font, by the way).
Doesn't anyone else consider one day's battery use with moderate to heavy use an essential!?
For the SMARTPHONE, yes. This is about APPS.
For a CAR, too, I would throw out.
I think it's impossible to choose one universal pyramid. Everybody has their own different priorities. Some people want a super-customizable app and don't care if it's pretty, while others only want eye candy and could care less if an app has a ton of functionality.
So I think it's important for developers to strive to achieve all 5 attributes because any given user will find at least 1 of the attributes important.
See Also: http://www-01.ibm.com/software/ucd/designconcepts/designbasics.html
I miss WPS...
A follow up post to my first post above...
Im surprised and confused... Does nobody care about the basic / core functionality in an application - so a new "third party" webOS application at least become as good as the applications, that was included in palmOS?!?
The 6 lost functions in webOS task application, made me look at third party alternatives - but they focus all on additional functions, that not is needed in a ToDo application and none target more than two of the 6 misses - http://www.vantechmag.com/bestbuy/dicam.html#vital
And I find that prioritising very strange...
Then find I it even more strange that nobody else seem to care about all the totally useless empty space and unnecessary big fonts in webOS that make a rather tiny screen, just half as "big" compare to what it could be - if it was possible to select a bit smaller fonts and tighter line space PLUS design the program so it use max of the screen, as one main prioritising!!
Yes, my clearly smaller screen in Treo 680 show more than twice as much ToDo information (with 11 longer lines, instead of just 6 short) than webOS and it could at least show the same, including 33% extra space for easy finger navigation!!
And everyone seem to dream of bigger screens - but even if we got 4.5 inch screens, would you anyhow see less much information than you would see with 3 inch, if you only could select one step smaller fonts (except the tiny fonts they use in calendar events) and that would still be rather big text in most applications... And if we get bigger screens, plus use the screen good and can select smaller fonts with matching line space - then would we be able to view FOUR TIMES as much info (compared with today's pre) without scrolling all the time!!
Wouldn't that be great and something to prioritise VERY high?!?
Any third party developers that think on this two basics, will also get a BIG advantage over the competition - because this is very easy to see, if it's presented right...
This two main limitations in webOS and third party programs, make it impossible for me to desert my faithful palm Treo 680 because I have TON'S of info in my 15 ToDo list's and it would as one example be a pain in the ass to manage my projects, if I had to scroll (totally unnecessary) half the time!
Then is it many other fundamental / basic functions that still is missing, as you can see here... http://www.vantechmag.com/bestbuy/dicam.html#vital
And that list is written to help everyone that really use a smartphone for heavy information management - but these people have maybe already left webOS for Android or Symbian?!?