This excerpt is from Flex 4 in Action, by Tariq Ahmed, Dan Orlando, John C. Bland II, and Joel Hooks. This excerpt is published with permission.
Principles of User Experience Design
User Experience Design, often abbreviated as UXD or UED, has its roots in human factors and ergonomics, which study the way humans interact with machines in the effort to build better systems. UXD has evolved to become a multidisciplinary field that encompasses aspects of psychology, anthropology, computer science, graphic design, industrial design, and cognitive science. In this article we’ll focus on the concept of building around user stories.
Building around user stories
User stories originated with—and are loosely related to—the concept of use-case scenarios. With use-case scenarios, however, a developer attempts to identify the expected use of the application by the user. Eventually people began to realize that this methodology was backward. Microsoft is probably the software developer that has been best known in the past for using use-case scenarios as the focal point for development. Why doesn’t this methodology work? Software programmers don’t think the same way that someone from a specific, targeted user demographic does. Figure A demonstrates how a programmer might think through a particular set of requirements. Notice the number of things that aren’t accounted for, such as types of errors that could occur and how each type of error should be handled.
Figure A In comparison to user stories, flow diagrams seem almost worthless
As hard as we try to put ourselves in the user’s shoes, the simple fact is that we’re incapable of seeing the world through their eyes, just as they’re incapable of seeing the world through ours. For this reason, a large part of the UXD process must take place prior to commencing development. This begins with the creation of fictional characters who in their daily lives experience some sort of pain that’s described in the user story. The following example is a user story that I recently wrote.
User story example
DJ La Bamba has 12 electronic music devices that can all communicate using the MIDI (Musical Instrument Digital Interface) protocol. Currently, musical instruments are forced to run in a master-slave mode when synchronizing beats per minute between music-sequencing devices. Therefore, during live shows and in the studio, DJ La Bamba is forced to set the tempo using a laptop. With so many devices, though, his laptop isn’t always within reach. Yet, every one of his musical instruments has a Tap Tempo button, where he can change the tempo by tapping the button or pad at the speed at which he wants the song to play. But the Tap Tempo functions on all of the devices are disabled except for one (the laptop) because of this master-slave paradigm that he’s stuck in. Nonetheless, DJ La Bamba believes he should be able to set the tempo of the music he’s playing using any one of the Tap Tempo functions on his musical instruments, and they should all synchronize automatically to the new beat clock. Reasonable as this may seem, it’s surprising to find that such a thing isn’t possible with the MIDI communication protocol or any other method of time-clock synchronization between computers and musical instruments.
Notice that the user story above is built around a fictional character, which allows the reader to use their imagination, making the story feel more real. This helps in understanding the pain that the proposed product will alleviate for the character in the story. It also infers on the end result that will take away the character’s current pain.
Considering context
When it comes to user experience, context plays a vital role in the decisions you make. When creating a mockup for an interface, it’s common to create a design similar to the interfaces you may be used to working with. This can be a huge mistake, which is why context is so important.
Three major categories of experience design rely heavily on contextual implications:
§ Visual and interaction design
§ User feedback
§ Responsiveness/performance
Let’s look at each of these elements to better understand the role that context plays in the decisions you make about these things.
Visual and interaction design
The first thing you’ll notice about this category is that it consists of more than visual elements, such as color scheme, bevels, drop shadows, and the like. It also includes navigation, interactivity, and metaphorical references. For instance, an application’s toolbar is arguably the first place the user looks when figuring out where to access certain commands. For example, regardless of the type of application, an individual usually expects to see a familiar set of icons at the upper-left corner of the application’s main window. This is demonstrated in figure B.
Figure B A set of standard icons that use metaphorical references
Right now you might be thinking that this is all obvious, but that’s where things get interesting. In the past, this section would have ended at the last paragraph. Until fairly recently, user response to visual stimulus was often treated as a common consistency among all people who use software applications, with no regard for the context in which a given application is being used by a specific individual. This mindset is reminiscent of older UML standards, where a user was seen as an object.
Ironically, the only other time we refer to people as users is when referring to drug addiction. The implication here is that addicts are viewed as objects until they develop the ability to make decisions based on their own logical reasoning and are therefore no longer being controlled by the addiction, suggesting that users don’t think for themselves. They’re like robots that choose a specific path to completing a task within a software program time and time again as if they’re programmed to do it a specific way every time without fail. We call this the happy path.
Any developer who has coexisted in the real world, however, will laugh at this type of reasoning and argue adamantly against it, and for good reason. There’s no predicting the paths that individuals will take to accomplish their goal, and therefore your job is to require as little thinking as possible on the part of the individual working in the software. That greatly reduces the chances of choosing an obscure path, which could lead to a dead end. Figure C shows the user interface for a Flex application I put together to demonstrate the merging of various social media and RSS-based informational content into a single application. Keep in mind that I’m not much of a designer, but there’s no denying that this application scores well in terms of usability.
Figure C The design may be a little weak, but this app shines in regard to usability.
User feedback
Feedback has many implications related to the audience for whom you’re building. For example, unless you’re writing an application for IT professionals, it probably wouldn’t be considered user friendly if you were to show the corresponding AMF stack trace in an Alert control if the application experiences a server error; nor would it make sense to show the server’s hexadecimal response because it wasn’t what the client application was expecting. Similarly, using generic global notifications such as “An unknown error occurred” will quickly make the user feel helpless and frustrated.
For the sake of best practices, you need to provide an informative error message to the user and give them some direction as to what they should do next. It’s usually a good idea to dump stack traces to a log file when an error occurs. That way, if the suggestion is to contact customer support, the help desk can help the user locate the log file and send it to the help desk for troubleshooting. All this work pays off when it leads to the fixing of a bug and the release of a patch that saves thousands of users from being frustrated by the same bug. This also saves the company money in support calls and what could have been a lot of lost confidence in the product.
Responsiveness and performance
A data-driven Flex interface, when combined with animated effects and transitions, can quickly come to a grinding halt, ultimately stalling out or crashing depending on the severity of the situation. Unfortunately, the Flash Virtual Machine (FVM) can’t take advantage of more than one processor core, and graphics can’t be off-loaded to the graphics processor. In highly customized, rich enterprise Flex applications, it’s not uncommon to find yourself in a situation where creativity may be required to overcome performance obstacles. This may involve such strategies as caching, or buffering of data on the client side so it’s available immediately upon request.
In a world where we’re seeing online applications that run from a web browser competing with the desktop applications of yesteryear, application performance and responsiveness can make or break its usefulness.
In order to shed more light on the things we’ve discussed so far, I created what I call the VIBE Model as a way of simplifying the development process of applications that are centered on user stories as opposed to traditional means such as UML modeling and complex flow diagrams. In the next section, you’ll learn about what the VIBE Model is, and then you’ll have the opportunity to see VIBE in action.
The VIBE Model
I use the VIBE Model as a way of measuring the overall user experience of a software product. VIBE is an acronym for
Visual appeal
Interactive experience
Business optimization
Extensibility
Webster’s Dictionary defines the word vibe as follows:
A person’s emotional state or the atmosphere of a place as communicated to and felt by others.
As you can see, the word used for the acronym is fitting. The key phrase in the definition is emotional state. Any product can be evaluated by first asking the question, “What VIBE am I feeling from using this product right now?”
TIP
When conducting usability testing and Quality Assurance (QA) analysis, the question should be modified to, "What vibe are you feeling from using this product right now?"
The answer should always be limited to one or two words that describe feelings and emotions only. For example, “frustrated and annoyed” qualifies as a legitimate answer to the question, whereas “clunky and slow” expresses an opinion of the software’s functionality—or lack thereof—which is the cause of an emotional state that the individual failed to describe. Your goal in this first step is to focus on the effect, not the cause.
Use-case scenarios have been the traditional approach to starting off user experience design, but this developer-centric approach focuses on functionality when it’s the user who matters. Using user stories, we can capture the current experience a user may be having and the experience we want them to have.
As you begin designing your next application, start by creating the stories your users will have. Allow them to interact with the interface—which doesn’t attempt to anticipate the best way to accomplish a goal—provide feedback that guides the user along, and think about what kind of performance and responsiveness users will need.
With Flex, you have a powerful technology capable of delivering great experiences, but you need to couple that technology with a sound user-experience methodology to achieve that. Following these tips will get you started in the right direction!