Facets of User Experience
Here is an interesting perspective on user experience design. I have always believed that there was alot more to building an experience for users than just simply the concept of usability. I have taken a little time out to try and expand on some of these concepts because as a designer/developer/architect I believe that a clear understanding will help:
a - Keep me on track in regards to the overall goal of any project.
b - Help me convey the value of user experience more effectively to our clients.
So after a bit of pondering the diagram, I decided to rework it just a little:
It seemed like a better idea to stack the two concepts of Utility and Affordance rather than have them on a slant (I will explain why later). I also altered some of the names of the facets as my description of them would be slightly different than the original blogger's. But hey this is all just an exercise in understanding really.
You could use this honeycomb as an Axis graph to try and associate values with the different facets. While doing this may not be something that yields 100% measurable results, it would be a good way to benchmark priorities for developing a user interface.
After more thought I realized the the end-user experience is really only half the battle for the applications we build for our clients. I see there being a second honeycomb:
The experience of offering a user experience to the end-user is an experience in itself that can define the success or failure of an application. This diagram is an attempt to put that experience into the same context.
Great, so all of this brings a bit more clarity to any conversation on the value of experience. But I felt that there was another factor missing.
As I began playing with the idea of charting numbers, I realized that those values that I would come up with, would have absolutely no value without another relative measurement to bring it all together. What would justify on what scale you would measure those facets, and what then would measure how well an application actually delivered on them.
Well the answer is target audience. "Who is your target audience?", hmm that just doesn't sound right. A traditional marketing background kind of coaxes you to think that way, but that is certainly not the right word to use for the relative measure I am looking for. The term assumes you are aiming at one group when really there may be no way to group people together other than "people that are interested in a service".
Flickr for example. What is the target audience?
Anyways, I have been thinking about a better way to go about things. Rather than focus on demographics, lets assume that anyone in the world no matter who they are may use an application, and it is their expectations of the application that is really the most important factor.
Expectation of Service - I define it as the preconception of how a potential user envisions themselves being served by a service. This expectation is based on what they would already consider being the standard level of service based on past experiences.
Intent to Serve - The actual claim that an application makes as to the level of service it offers to the end user.
I took a quick stab at making a diagram to convey the relationship:
If you consider both measures to be perfect circles for the time being, you could imagine the above scenarios.
Power User: Someone who's expectation of service has almost filled out the application's intent to serve.
Short Term Positive: The user has a relatively high expectation of service, yet the application provides enough depth to the end user that they must invest some time to explore the possibilities.
Long Term Positive: The application's intent to serve will encompass the user's expectation for quite some time. It will take the user quite awhile to know it inside out. Imagine this to be pro desktop software for example. Long release cycles mean that the app must continue to be a great experience for quite some time.
It is important to note though that just because the intent is way beyond the expectation, that does not actually mean the result will always be a good one. It actually may lead to intimidation. If you sat my grandma down in front of Outlook for the first time and asked her to use it for email, she may be overwhelmed.
Negative: Obviously, if the expectation stretches beyond the intent, then the experience is sub-par. It is less than what is considered standard.
If a user over time fills in the intent, it is important to note that at that time the experience has not lost it's value. Instead, that experience has become what that user would consider standard level of service.
So using this view, it becomes easier to set priorities, because as you look at different target audiences, it becomes a little bit easier to get down to decision making when you measure their likely expectation in relation to intent to serve.
you know, I am not positive about the next one, but I will bet that certain facets will assume higher priority as users move from experiencing for the first time leading to becoming power users:
If you consider the above, I would bet (it is obvious) that new users would be concerned with Affordance where established users are more concerned with Utility. Filling out the facets of Affordance quickly is what in my mind leads to a successful application, where users can quickly move to exploring features offered.
So one last concept I have been thinking about. Experience Resolution. I stated above that just because the intent extends way beyond the expectation, that does not mean the experience will be a good one. The reason for that is what I am calling resolution:
Resolution to me in this context is the relationship between Useful and Desirable. If the application leans heavily on Useful with Desirable being low, then the application is over delivering on it's stated Intent to Serve.
This would be like me helping my grandmother set up Outlook to do her email, when Gmail or Hotmail would have done a better job for her.
The intent was, manage your email, but we all know that Outlook is not really for entry level users. The experience is way to thick for the user to realize the stated intent.
Raising the level of desirability is what counteracts this thickness.
Apple is obviously a master of this balance. Unix without the OSX interface is certainly not for everyone, but with the desirablity layer that is Aqua, it becomes very approachable and less dense.
So feel free to comment, whether you agree or think I'm full of BS 2.0. I am continuing to explore some of these concepts and see if I can draw any parallels with Design Maturity (That should be pretty straight forward).