What the end user of software experiences while they are actually using a program is something that gets a lot of discussion among software developers. Developers have learned the hard way that if software does not help the user in the pursuit of their goals (which may not be the same as what the developers think that they are), they get the aggravation of it all shoved back into their faces in a most unpleasant manner. In many situations, developers are the ones that will get burned by the fire.

The UX stalwarts

But what exactly does that user experience consist of? The sum of all the things that happen during the use of software by someone is called the “user experience.” It’s more than just the result of the coding that the developer does. It’s what occurs when that software is actually running and being used.

Don Norman was the guy who popularized UX (the commonly used notation for the user experience) while working at Apple in the 1990s. He has stated that “I invented the term because I thought Human Interface and usability were too narrow: I wanted to cover all aspects of the person's experience with a system, including industrial design, graphics, the interface, the physical interaction, and the manual.” His work is still used as a touchstone for today’s designers. Much like Jimi Hendrix’s influence on guitarists of today, Norman is a rock star designer.

In 1995, Jakob Nielsen came up with a list of ten usability heuristics (or rules of thumb) that is still being referred to today (they can be found here). Each of his ten points is as valid now as when they were first written. All of them should be considered when constructing the UX.

UX is different from the user interface, which is usually defined as the method that the user communicates with some piece of software. It is much broader in scope and extends over the entire product. The manuals that ship with something are as much a part of the UX as the results that show up on a computer screen. UX strives to ensure that users find value in what is being provided to them.

Peter Morville designed the “UX Honeycomb” in 2004, and it has been widely adopted by the UX community. It centers on information that is valuable as the goal in the middle of the honeycomb. Surrounding the center are several factors that all contribute to the “valuable” center. The first is “useful”—that is, will the goal serve some purpose. That’s different from the next facet “usable” which means ease of use from a human-computer interaction standpoint. “Desirable” addresses the elements of “emotional design” (that Don Norman also popularized) which is making things more attractive.

"Findable” is simple: users can find the information they need. “Credible” means that users trust and believe what they are told from the information. “Accessible” means that people with some disability can still access the information. More about the honeycomb can be found on Morville’s website at semanticstudios.com.

All along your watchtower

Since user experience lives in the real world, not the abstracted software one, we have to look there to find what the user is up to. The primary real world effect that impacts UX is the latency involved in the system that presents things to the user. Latency is fairy simple to grasp: It's how long it takes for the user to see a reaction in the system from the input that the user provides.

Low latency is good, primarily because the user isn’t distracted by the system’s response time acting like a purple haze and getting in the way of the things the user is doing. A low latency gets the extraneous stuff out of the way and puts the focus back on the user’s actions.

Just because the network has some localized port available for use with a fast connection, don’t assume latency can’t still be a problem in the UX. For instance, WiFi may cause latency problems of its own if the WiFi access point is misconfigured or in a noisy (many APs sending out SSIDs at the same time) environment. The AP can get confused, going from one extreme to another - an electronic manic depression.

Centering around the user

UX is built through user-centered design methodologies. Some think that a good outcome can only come after user research. This research has as its goal learning user behaviors and needs. Observation of the user, along with task analysis or other feedback mechanisms, can be useful in finding out the needs of the users.

Another user-centered methodology is usability evaluation. This looks at how well the user can understand and use a process in the pursuit of the project goals. Finding input from satisfied and unsatisfied users can only help here.

Interaction design is where tech folks tend to hang out most in a project, because they are the ones that can make a concept into code. The idea of ID is to make whatever it is that is being done engaging to the user, keeping them involved in the process. This part of the design is where the effort goes to create well thought out behaviors and actions of the program. No one questions that this is an important area of the design phase, but it is easy to consider this part of the design as being the only part that is important. The designer must go wider in their view. They need to look at not only what the user does, but why it is that they do it.

I will experience you

One of the most successful app designers recently said the success of his work was due to “concentrating on user engagement, not just downloads.” The apps he makes always have as a design goal to give the user a positive UX. That is why it succeeds. Your work can succeed too if you remember that in the end you do it all for the user. Give them an experience they will like.