Saturday, October 16, 2010

User Experience for Developers

User experience (UX) is an enigma to many developers, but is something I think developers should have a firm grasp on to excel as well as create apps that not only impress, but also work for (as well as with) the end user. Many developers do not understand the difference between UX and UI (user interface). UX defines how a user interacts with your application, whereas UI is the actual implementation of the patterns selected for the interaction. If UX is not considered in detail up front, I always expect several iterations of extra development resulting from user acceptance testing (UAT).

I had the unique opportunity to work with Will Evans and watch a master in action which really sparked my interest in user experience design. I don't have the opportunity to apply his overarching tenet that 'You are not the user' in full, I always keep it in mind when speaking with clients and while developing the UX for any app I architect.

A few important assets to understand in getting you started in UX are listed below.

User Personas
User personas were something that were uncomfortable to me at first. I was used to defining different types of users while architecting systems and agile user stories, but adding information like salary, education and age seemed uncomfortable at first. Properly defining descriptors like this help to develop usage scenarios. The user persona allows us to understand how a specific user will access the system, where they will access the system from, their technical proficiency and even if they need adaptive technology to overcome a disability. Also, being able to identify deeply with users really helps when creating stories and process flows. Performing user interviews really helps! So does observation of users performing their tasks or interacting with an existing application (if one exists).

User Stories
Much like standard application development, UX involves the creation of user stories. In software dev we generally build these stories by working with the product owner and their understanding of the system. During UX discovery it is a great idea to look beyond standard requirements and involve additional stakeholders, and EVEN MORE IMPORTANTLY: a sampling of end users. These user stories define not only a user's interactions with your application but also the process flows identified by the stories. Unlike Agile development stories, UX stories can be much more verbose, and also define personas within the context of the system.

Information Architecture (IA) and Content Inventory
For developers, this is a very familiar deliverable. Consider this a sitemap, but even more importantly, the hierarchy of how information is organized within your application. This defines how users will find information or services. IA is a huge topic in itself, and we won't be going into it in detail in this post.

Process Flows
Another familiar asset for developers, these flow diagrams are perfect for demonstrating user interactions for common system tasks. I like to create these as UML activity diagrams. Being able to walk a user or stakeholder through a workflow is very helpful and saves time in the longrun, especially considering how visual users are.

I'm pretty sure every developer has been in a client meeting at some point explaining some complex method of attacking a problem using a image, and the client turns to you and says, 'You know what, I think that shade of blue should be slightly darker, and perhaps the logo should be larger, and maybe we need a san-serif font here that blinks and ....'. Somehow they've entirely missed the decision they were supposed to be concentrating on and got caught up on ancillary topics. Wireframes are an awesome solution to this problem for a few reasons. Aside from just allowing you to focus on process and function over form, they are also simple to create and take much less time than full visuals. Wireframes allow you to develop experience and interaction first, managing visual design at the appropriate time once the processes have been clearly defined. Wireframes generally do not stand on their own and require annotations that call out specific details.

UX Design Patterns
I could dedicate an entire series of posts to UX patterns. Just like in software development, user experience designers have also identified common problems and sets of solutions that address said problem. By understanding the needs of your users by observation and interviews, you can apply the correct pattern (or work from a pattern) to provide a good experience. Yahoo! has a list of pattern libraries to get you started. I also highly recommend Martijn van Welie's pattern library.

When creating high fidelity visuals (also referred to as comps) it is important to remember that you don't need to create visuals for the entire site. Generally you will have a few variations of pages that will need created. I still find lorem ipsum text important during this stage with some clients to allow to to focus on the proper items. Make sure the visuals tell enough of the story you are attempting to convey within the application flow. Many times this step is handed off to a visual designer, but ti is imperative that the UX designer remain engaged during this stage. Not always necessary, but important nonetheless, sometimes mood boards help define the artistic direction (especially when developing an entire brand experience). Mood boards can also be used to demonstrate design concepts and themes to a client before creating fully fledged visual designs.

Style Guide
A style guide is an important asset to deliver with your UX design. This allows developers to easily recreate your vision utilizing the correct hexadecimal colors and fonts. Creating a cascading style sheet is simple utilizing a style guide, and prevents developers from taking too many creative liberties with the design.

These are just a few assets to get you started. I have quite a few good examples of UX in action that I'll post depending on interest. If anyone wants additional information or examples on a single asset above, let me know and I'll wire them up.


  1. Yes, I'd love to have more info and examples. Right now I'm working on a spec document and am considering several groups who will be using the application.

  2. I'd be happy to continue this series. What specifically would be of help to you Lola? Just a write-up of persona identification in general, or a more specific focus?