If you've been following the news in the web and/or RIA industry at all lately you've undoubtedly come across two little letters (probably quite frequently), "U" and "X." UX of course, is the abbreviation for the big trend in application development right now known as "User Experience." UX sometimes moonlights as "experience design" (XD) or "user experience design" (UXD) but it all essentially boils down to the same concept -- creating the best possible experience for the users of your applications.

You've worked hard to become a great developer. You've learned the best practices to write bulletproof code, you've even mastered a crazy framework. Now it's time to go to the next level, you need to create an exceptional experience that matches your solid code. Before we get too far though I should explain that I'm not a designer. I'm also not what you'd call a "hardcore" developer. I'm somewhere in the middle. Throughout my career I've been fortunate to work with several like-minded people. People who aren't designers but understand and appreciate good design and can speak a designer's language. At the same time, these people understand the complexities, limits and capabilities of application development and can likewise speak the language of the developer. These type of people and this mindset are crucial to the UX revolution. As Christian Saylor, Senior UX Design Specialist at Universal Mind puts it, great UX comes from "...a firm grasp that great experiences are enabled through a thoughtful relationship between art and science."

Why Does UX Matter?
A good application experience can be just as valuable as good customer service. This can be a tremendous differentiating factor for you application, and by extension, your business. If two apps adequately perform the same tasks, all else being equal, why wouldn't you choose the one that offered the better experience? Not only does good UX lead to more users but a good experience is worth more. In general,we are willing to pay more money (within reason) for exceptional service. There's no reason this shouldn't translate to applications as well. If you can show that your application offers a better user experience, which many times translates to higher efficiency and cost savings, than your competitor's app then you can command a higher price. Apple is a perfect example of this. Everyone knows they are going to pay a little more for their iPod or MacBook but in the end it's worth it because you are getting a better product with arguably the best UX in their respective industries.

Alright, I'm sold. Now what?
So you're convinced UX is the way to go with your next app (or you're at least willing to give it a shot), but what does that mean? Good question. You could probably ask 10 UX "experts" and get 10 different answers. Essentially it boils down to this. Good UX allows users of your application to achieve their goals in an enjoyable, efficient, and effective manner. It is important to differentiate between goals and tasks when thinking about UX. Goals are the ultimate results we hope to achieve, tasks are the steps that get us there. While it is certainly important not to lose site of the tasks when building our applications all too often they become our central focus. It's easy to look at a list of tasks and build requirements from it. In many cases however, that may not provide the best experience. It's possible that you could modify, combine or eliminate certain tasks while still meeting the same goal(s) and provide a much better overall experience for the user. For example, let's say you are building a replacement for a manufacturer's data entry system. The goal is to provide the administrative staff with an online tool to enter new parts and products into the system as quickly and accurately as possible. Currently one of the tasks is to open up the suppliers web site and/or email and copy/paste the information on the part into the data entry system. While this method works it certainly is not ideal and is prone to errors. What if the new application could somehow automate this process by tapping into a feed from the supplier or by importing a standardized file with all of the product information contained within? The end result is the same but we've just made the process much simpler for the user by modifying the tasks necessary to complete it.

So, how do we do it?
Like most things in life, creating a great user experience is easier said than done. Luckily there are some processes and best practices in place to guide us along the way. One of the most respected names in the interaction design and user experience field is Alan Cooper. His company, Cooper (http://www.cooper.com/) has developed the Goal-Directed Design process which is an excellent road map for heading down the user experience path. For an in depth look at this philosophy I would highly recommend the book; About Face 3: The Essentials of Interaction Design. Much of what follows is based on the concepts presented in that book.

Research
Step one, research. I'm not talking about simply going out and looking at what the competition is doing. That's important, and can help you come up with some good ideas and possibly figure out how to come up with solutions to certain problems, but it's only a small piece of the puzzle. You need to research your user, find out what makes them tick. Whenever possible, observe your user on the job. Watching someone work in their "natural habitat" can provide valuable insight into how they use the tools available to them. If you're there in person it becomes much easier to ask questions about why they do things a certain way. Could their job be easier if that task were changed or removed from the process? Direct observation is also helpful because many times users cannot articulate their needs or how exactly they do things. As an outside observer you have an opportunity to offer a unique perspective because you are not hindered by the prejudices that can develop when one performs the same tasks day in and day out. It's a perfect opportunity to break out of the "that's just how we do it" frame of mind.

While you're observing, interview your users. Ask questions geared not only towards what they are doing and how they do it but also why. What are their motivations? What are their goals, not only for the application but in general? If you can develop the application in such a way that it not only meets the immediate goals of the project but also addresses their overall goals (e.g. increased productivity) you will have succeeded on multiple fronts and the experience will be that much better. The key here is not to make the interview seem like an interrogation, you want it to be more of a conversation. Use open ended questions to elicit more meaningful answers. Rather than asking "If we add feature x to the application will it help?" Try something more along the lines of "If we add feature x to the application what will it allow you to accomplish that you cannot do with the current system?" Be sure to take good notes during your research. This information will be the foundation of the decisions you make going forward on everything from feature priorities to color palates.

Personas
Now that we've dutifully gathered all of our research together we need to mold it into something useful. To do that we create something called personas. Cooper defines a persona as "detailed, composite user archetypes that represent distinct groupings of behaviors, attitudes, aptitudes, goals, and motivations... ." In other words, a persona is a fictitious user that you create based the research you gathered during the first phase of the project. You want to make the persona as concrete as possible. It needs a name, gender, personality. He/she should have needs, wants, and desires associated with them. You should have a picture for your persona to help you visualize the "person" as you talk about them. This might seem a little over the top at first but personas play a crucial role in the UX process. Your persona(s) add a personal touch to the research you gathered which helps you to make decisions about the application based upon that research. It allows you to step into the role of the user more easily. You can say, "How would Kelly feel about the way we've laid out this screen. She is very detail oriented so having the ability to get very granular with the details quickly will be useful to her." It can help you prioritize features as well. "Steven takes 10-15 calls per hour on three main topics. He needs to be able to quickly reference data on those three topics. The rest of the data is ancillary to him and can therefore be made far less prominent." You can quickly see how personas can become very valuable in creating user stories and developing scenarios around how the application will be used. By walking through these scenarios with your various personas you can iron out details and more easily focus on details important to your users. By focusing on the behaviors and motivations of a persona you can identify and eliminate features that might have seemed crucial to you as a developer but upon further examination mean very little to your users.

Personas can also be used to defend design/development decisions. By basing the traits of your personas on concrete, qualitative data obtained in your research you can provide more compelling reasons why certain decisions were made. For example, using a persona scenario you could easily explain why you decided to go with large, visual cues instead of textual ones because "John" is typically far away from the monitor when he needs to navigate a particular screen.

Wireframes
Okay, we've done our research, we've organized it and created some user persona's, now it's time to put some structure into this application. We do this using wireframes. Wireframes are graphical representations of the layout and components that make up the various views and/or pages of an application. The level of detail in wireframes varies from simple line drawings to fully skinned representations that show what the final app could look like. Some wireframing tools even allow you to add basic interactivity to your wireframes. A lot of times you don't have the time to fully skin your wireframes but you do want to have enough detail so the concept you're trying to convey is clear.

Wireframes are our first opportunity to give our application some structure so don't expect to get it perfect right out of the gate. Part of the purpose of wireframes is to try different things out. Think of the wireframes as the blueprints for your app's experience. With the help of your personas you've determined which features to build into the application. You use your wireframes to layout those features and determine the flow of the application. Later the designer will use your wireframes to develop the design comps that will eventually become the "skin" of the application.

My personal preference is to build out wireframes using Adobe® Fireworks®. The drawing and layout tools provide plenty of flexibility and ease of use to create complex interfaces. Some of the other good tools out there include:

* Lovely Charts; http://www.lovelycharts.com/
* Balsamiq Mockups; http://www.balsamiq.com/products/mockups/
* FlairBuilder; http://www.flairbuilder.com/
* iPlotz; http://iplotz.com/

These tools offer some nice features that can help you spice up your wireframes. As I mentioned earlier, some of them will allow you to add interactive components which can be nice if you want to demonstrate to a client how certain interactions will work. Many of them also include Flex and AIR specific components that allow you to quickly and easily add that familiar look and feel to your wireframes.

When you've completed your wireframes it can be a good time to gather some early feedback from your client and even potential users. Use this opportunity to make refinements based on the feedback you receive, it's easier to do it now than after design and development have started. It's important to make updates and refinements based on your feedback but it is also important to keep your personas in mind. Don't just go about making changes willy nilly. Look at them through the eyes of your personas and be sure they make sense. If you find that you have a lot of conflicts between your feedback and the point of view of your personas it could be a sign that you went astray somewhere along the line. Either you inaccurately interpreted your personas or your test group isn't representative of your true end users. You'll want to consult your original research and try to determine where you went wrong and either tweak your personas or try to find a better test group.

Design and Application Skinning
Often times you will work closely with a designer during the wireframing stage of the project but once the wireframes are complete the design team really steps in to put the face on the application. The designers will use the wireframes to create design comps of all the views and components that you've laid out. This is another area where you shouldn't expect to get it right the first time. Plan for some iterations here and possibly even some quick low level prototypes if necessary to demonstrate a particularly complex interaction.

Once approved these comps will be used to create the various skins for your application components. Some programs like Adobe® Fireworks® make this very easy by having export commands that can export your skins directly for use in Flex. Another tool from Adobe, Flash Catalyst, aims to make this integration even tighter. With Catalyst designers will be able to import their comps, add states and basic interactions and then save their work as a Flex project that developers can use as a starting point in their work. While it remains to be seen how well this will work in the real world early indications based on alpha and beta releases are that it does a fair job. It appears that Catalyst's greatest strength, at least initially, will as a rapid prototyping tool. It will be exciting to continue to watch this unfold. You can keep an eye on the current update at Adobe Labs (http://labs.adobe.com).

Another popular method for skinning Flex and AIR applications is the Degrafa framework. Degrafa is a declarative graphics framework that can be used to create rich interfaces, data visualization, graphics editing, etc.... I don't have room here to do Degrafa justice but I wanted to be sure to bring it to your attention. If you haven't played around with it yet I'd strongly encourage you to check out there web site http://degrafa.org and give the samples a whirl. You can really do some amazing stuff with it. Below is a nice example by Joe Johnston from Universal Mind, of what you can do.

Development
From here we move into development. Depending on the size, complexity and budget this could go a couple different ways. You might jump directly into production development and churn out the final application. If the budget, timeframe and complexity of the application allow for it you might move on to something called a vision prototype. A vision prototype is a prototype version of your application that can be used for a variety of things including user testing, marketing, and testing new interaction paradigms. Often times vision prototypes are limited to large, complex projects and by nature, require a bigger budget. They can be an incredible useful tool however, in creating a great user experience.

We've covered a lot of ground here. We discussed the what UX is and why it's important. How it can help differentiate your application to give you the edge over the competition. We went over some best practices and the steps used in creating a good user experience. We talked about the importance of research in developing user personas that will help you determine the best features and interactions to provide the target users of your application with the best experience possible. Next we discussed how building wireframes can give your application the initial structure that can be used for early testing and eventually create the framework that the design comps are built from. Finally we talked about skinning the application and moving it into the development phase. Hopefully this was enough to whet your appetite and get you excited about creating fantastic user experiences for your applications. Good luck!

Read more from Tim Todish.