Essential Question: Can User Experience and Usability needs fit into a Maslow’s hierarchy of needs type pyramid?
Ben and I got to discussion a post on UXMovement.com titled “Are You Meeting the User Experience Hierarchy of Needs?” by Anthony. It was interesting and had a bunch of comments. I decided to research it more and share it with you. here:
Everyone ‘sort of’ understands Maslow’s pyramid. They may not understand it fully. It may be like Darwin’s theory of evolution – everyone can give you the basic tenants, but it is probably misunderstood. Here’s my understanding of Maslow’s hierarchy of needs. Food and water and shelter are basic needs that take precedence over things like morality and respect of others. You must satisfy the basic, base levels of the pyramid BEFORE you can / want to satisfy the higher levels. Maslow’s hierarchy of needs is often cited when explaining why a typically law-abiding person will break the law (higher order) in order to get food or sex (lower order). It’s a theory I have problems with.
Here are my questions: In order to be a whole person do you need to satisfy all needs? Is it harder to meet higher, mid, or lower needs? Does the pyramid establish a sequential order for achieving needs? And, to transition to interface design, must a “quality” website satisfy the all needs? Is it harder to meet the higher needs than the lower needs? Must the design process start with satisfying lower basic needs and move on to higher needs?
This article and chart puts functionality as the base of the pyramid. Together with information, this forms the first half of basic needs. The top half are higher needs with aesthetics below and usability on top.
Usability breaks out of the pyramid top suggesting that it is not inside the pyramid – or this could have been done to promote readability as the font would be very small if made to fit in the tip of the pyramid.
He outlines a model that says you must begin interface design with functionality and move on to content and aesthetics in order to achieve usability. Anthony defines usability as “the ease-of-use of an interface that increases user productivity.” There was some debate on this article and several commenters wanted to put aesthetics at the top of the pyramid – which makes me scratch my head.
Even though Anthony did not like this pyramid Chart, I like it quite a bit. Anthony called it pretty bullshit (which I thought was slightly rude). Just like a cow patty, this chart can teach a lesson. Working from the outside in, the chart establishes two contexts. At the top we have subjective/qualitative and ‘focused on experiences( people, activities, context)’ with an arrow pointing downward. The second context is at the bottom it states: objective/quantifiable ( products, features) and ‘focused on tasks’ with an arrow pointing upward.
Within the context of tasks (going up), the graphic seems to relate that the priority sequence is: functional( useful), reliable, … and peaking at meaningful.
Within the context of experience (going down), the graphic seems to relate that the priority of sequence is reversed – that meaningful is the first priority and functional useful is the last priority.
This chart tries to make the distinction between subjective experiences and objective tasks. That’s what I like about it. It seems state that if a subjective experience is meaningful and pleasurable that it does not have to be reliable or functional. Or that a subjective experience that is meaningful and pleasurable need not be reliable or functional. And this DOES seem to be descriptive of my personal experience.
If you have a meaningful and pleasurable relationship with a beautiful girlfriend, you don’t really care if it’s reliable or functional [Radio Edit]. But I don’t think he’s talking about relationships. If you just love your iPhone , you can subjectively overlook usability [Siri, why can’t I just drag and drop my files from my computer to my iPhone. Siri?] – Think supercars in the 80s – Toyota’s were WAY more usable. If you were focused on tasks, then you just care if it’s useful and reliable (Toyota)-you don’t really care that it’s not meaningful or pleasurable (Ferrari).
The fact that convenient lies in the center of hypercatalecta‘s diagram is important. That says that convenience is of equal value for objective users and subjective users. Both those focused on experiences and those focused on tasks care about convenience.
But here’s my problem: why is it a pyramid?. I have a feeling they just did that to make it look pretty. Perhaps this is why Anthony called it pretty bullshit (He called another guy pretentious ) But, because it defines the subjective / objective vectors, it gives me valuable insights. When working with some clients – subjectively oriented clients – they really only care about aesthetics… but here is where I think folks are missing the point – the reason they feel that way, is because that’s their experience. That’s how they experience the site. It’s their user experience.
This is why I concur with Paul Veugen – and others – that user experience is a super-system of usability. And, user experience is a complex interaction of many facets. Why? That little word USER. People are complex – they are different shapes and sizes, speak different languages, and use websites in different ways and for different reasons. Simply put – WE are the definition of complexity on this planet …currently
Alternatively, usability is technical. Usability can be measured… and can be measured by any asshole. Can you hear me now?
Moving forward –
Ugh… let’s look to Smashing Magazine, surely they are shed some light here.
This article,’Designing For A Hierarchy Of Needs‘ starts off with:
Based on Maslow’s hierarchy of needs, the idea of a design hierarchy of needs rests on the assumption that in order to be successful, a design must meet basic needs before it can satisfy higher-level needs. Before a design can “Wow” us, it must work as intended. It must meet some minimal need or nothing else will really matter.
Is this true? Or could a design that’s hard to use still succeed because it makes users more proficient or meets certain creative needs? Do you have to get all of the low-level needs exactly right before considering higher-level needs? To answer these questions, let’s start by looking at Maslow’s hierarchy.
Notice the author (Steven Bradley) is talking about general design. Ugh! Sure enough, we have some semantic issues here. Damn you language and our plastic language brains.
I feel much of the confusion and debate is sparked by imperfect language and vocabulary. Design, user experience, and usability: These terms are sometimes used inter-changeably. Yet, they can be very different.
Can you use these pyramids to build sites and interfaces? Sure. But, here’s my insight, you CAN test this way – Regardless of if testing Design, User Experience, or usability. First test for the base needs and then test for the higher needs. Why do this? Well, why not. Think of it like a map and a way to segment the complex task into manageable chunks. And, it can help prioritize your testing and help you make decisions and communicate problems to the stakeholders.
For your viewing Pleasure, I’ve collected all the Pyramids on my own private Giza.
Let’s face it – People love charts and pretty bullshit. Pyramids are old and busted – honeycomb is the new hotness. Users are complex.
So! There’s my insight. There’s my learning to share. I hope you enjoyed it. Now, I’m off to share a beer!
Thoughts on my user testing design process
Based on my background with instructional design and guerrilla web building, I’ve tried take a new look at my design process from the perspective of usability and user centered design.
I’m sure it fits in with the larger context and conversation going on in the very robust user-centered design community. My purpose isn’t to make it fit, but rather just notice how I would go about conducting a user centered design. I know it will change- it’s already changed twice this week. It seems I change this design process each time I read an article on smashing Magazine.com or usability counts.
With most good things, my user-centered design process has a beginning, middle and end… Thinking of changing that to include the word terminus which is a beginning and ending, but I digress.
Beginning – “Stand in the place where you are” – R.E.M
I like to start with what I (or the client) know. Business goals should not be confusing, abstract nor complicated. “Sell more widgets”, “Make money”, “Provide health care to my workers”, etc. They should be clearly stated in a business plan or firmly in the mind of the business owner. From these business goals we can derive site goals and page goals.
Site goals can be anything:
- to inform
- to sell
- to build trust
- to reduce paperwork
- to recruit new employees
- to build a community
- to entertain
Each page should have a primary goal-or the thing you want the user to do. Don’t give your pages an identity crisis. Don’t make your users search for the purpose, or ‘call to action’, or banana. Pages, like PowerPoint slides, are free. Use as many as you need. The idea is to have a clear goal for each page. You can test this clarity directly in your user tests.
The clearer the goal, the more straightforward the user test.
Aligning the business goals, site goals and page goals is key. If the business goal is “to sell” and the site goals are “to entertain”, then there’s going to be a problem. The biggest problem I see in websites is unclear or confusing site goals.
The last part of the defining what you know is to collect information for baseline performance. You may need to survey company employees or site users to collect this data. Much of this information is”laying around” or extant within the organization. Examples of this are business plans (for business goals), previous website’s design documents or web traffic data (for redesigns) or advertisements or marketing materials.
Now that you’ve collected and define what you know, it’s time to make a few estimates and educated guesses. This could be called a hypothesis. You’re going to make guesses about the users, and how and where they use your site. Why is this important? One, this is what you will confirm or refute with your test results. Two, a Saturday morning website is very different than a Saturday night website. Other questions are, are people using the site at work? At their desk? On the couch? On a mobile? Users determine how your site will be used and you have to make design decisions based on these assumptions.
You want to dive deeper into who these users are. What are their goals? Why are they going to your site? How did they get there? What are their demographic attributes?
Closing the beginning of this design process is choosing the testing environment and tools. Basically-whether you use technology or not – it comes down to interviews, surveys, and small-group testing [watching / observing the user interact with your site]. I suppose for websites you can also add automated reports and services like the W3C site checkers.
The middle part – a.k.a. the fun part
Once you have all of your “knowns” about the business and you’re educated guesses about the user and their context, you are ready to draft and refine your testing instruments. What sort of things are you still unsure of? Which assumptions are not agreed upon-there will be some in any group. That’s what and why you test.
You generally test a website or any system for these three things:
- Effectiveness – Can users do what they ( And you) expect? mechanically, does it work?
- Efficiency – Is it easy to use? Does it work naturally or does it take concentration?
- Satisfaction – Sometimes called the ‘smile test’. Do people smile when they use it? Are they happy to use it? is it delightful?
I won’t go into too much detail here, but the general structure of a user test is:
- Pre-test Questions
- Participant Tasks
- Post-test Interview
- Post-test Survey
Before you conduct the test there are a few steps to follow. You have to:
- Choose a facilitator-preferably one without much experience with the design or site itself. Recruit testers-preferably of the target market demographic
- Decide on the links and location of the test – preferably close to the environment that the user will interact with the site, at home, at work or in a mobile situation.
- Prepare a script for the facilitator-this avoids bias delivery and provides a standard control especially if you’ve got multiple facilitators
Fin – the end
The last part is to collect, analyze and report the results. If you prepared and conducted a well made test (lucky?) clear patterns will emerge from the test results. You may see that people are unclear about your menus and can’t find certain information. Or you may find that there is a loophole in the structure such that people get in but can’t get out.
It’s important to remember to test the user experience – not your design. The users are experts in their own experience. They couldn’t care less about color scheme or fonts. They won’t tell you that experience and less you ask them. If you ask about design, they will tell you about design.
The goal of all of this is to make new assumptions about your users. These assumptions are now based on your test results. You have a more complete picture of your users and your site. Hopefully there aren’t some clear improvements you can make to your site. You can make those changes and test again to see if “The needle moved”, the changes were effective as anticipated. Then, you start the process over and test again. Each time you will get a more complete picture of your users and insights into how to make their experience with your website better.Thanks to Flickr: Sebastian Bergmann