With the expanse of a new year stretching out in front of me, I thought I'd share my resolutions concerning the practice of User Experience Architecture, and my contribution to it. Far be it from me to suggest that anyone else out there take these to heart; they are mostly for my own benefit, and posted here almost entirely because writing them down in a semi-public place seems the most reliable way of keeping them in mind.

So, in no particular order, here are my 10 UX Resolutions for 2004:

1. "I don't know" is a perfectly good answer.
   Not knowing the answer to questions like "how should this feature be built?" is acceptable, even among "experts". The web is still an evolving medium; 10 years after the invention of television, wide-spread adoption of color TV was still a quarter-century away. Reality-TV would take another 30 years. Though the web may evolve faster, being an expert doesn't mean knowing how everything should be done - it can mean knowing what others have tried, succeeded, and failed at; it certainly should mean knowing how to figure it out.
2. "I don't know" is best delivered as a precedent to "but let's test it".
   
   It's a great standby, and unfortunately some people see it as a cop-out. But testing design ideas with people is a great way to find out if it's going to work. You don't need a lot of money, you don't need a complicated setup. In fact, you can get by with plain paper, a pen, and a pad of stickie notes. It doesn't matter if you believe 5 users is enough or not. This much is certain: if you don't test you won't find any usability problems in your product... until your customers start buying it.




3. It's OK to let your budget and timeline constrain which user's needs are met in what order; but doing so carries certain risks.
   
   No product is developed in a vacuum, avoiding the intersection of competing goals, internal team politics, and external competition. Budgets always run short of what we'd like them to be, and timelines are often based on when the next upcoming tradeshow occurs, or the close of a fiscal quarter. These are legitimate factors in planning the execution of a development plan, but treated like the Holy Grail, they can undermine a project's success. Beware the need to "launch something by <insert date>". Instead, launch the right thing as soon as possible. Shooting for a date can obscure the more important metrics for a product, like whether or not customers were happy with it.
4. Beware the limits of "best practices".
   
   The coverse will do just as well: "Be careful where you innovate." For the vast majority of sites, the same type of shopping cart will do just fine. Some best practices have been well established, in the sense that most sites do certain things the same way. So there are de facto standards which you can and should leverage. Innovate with features that no one else has tried before, or that no one else does well. Otherwise, start with a well-worn design pattern.

   There's an important caveat here, and it relates to the last resolution: if you're going to innovate, you have to test. If you're going to differentiate yourself with a novel offering, you need to try it out in several variations, and plan for a few itterations before you launch. Otherwise, you're just gambling.

5. Practice what you preach
   
   There are parts of this site in particular that are terribly unusable. I'm making a concerted effort to change that in the coming year. At the same time, I use this as a testing ground for interface ideas. But since I don't make my living through this website, there's little risk involved when I introduce a feature that doesn't work well. Still, I hope this site can serve as an example of an accessible, usable, interesting and informative site. If only so I can say, "There's no excuse for being unusable - my site is, and I work on that in my spare time."
6. Be mindful of the difference between personal preference and judgements based on research.
   
   Design is a collaborative process between team members, clients, agencies, customers and other stakeholders. Everyone has an instinctive sense of what works best for them - the problem is, the people who make a product are rarely representative of the people who'll end up using it. Try to be unemotional in making arguments for or against certain design features or styles. Rely instead on analysis, research, competitive examples or customer input. Because in the end, it's not about what you like - it's about what the end-users like.
7. Pay attention to theoretical research, but be wary when attempting to apply it.
   
   Not a day goes by when I don't read a new paper, study or article about one aspect or another of the user experience. Theoretical research (utility of heads-up displays, new Human-Computer Interface techniques, and generally anything that involves eye tracking studies) is great for generating new ideas about how a product should be developed. Occassionally it provides a basis for making a design decision. But take the time to look at the details: who did the study? What was the hypothesis? What was the methodology like? How many people were tested? What did the measurement criteria look like? The devil is in the details, and relying on an exploratory or unreproduceable study can come back and bite you hard.
   
8. Better usability comes through itteration
   
   The best products aren't produced the first time out. Assuming you need to launch something before it's perfect, find the critical problems that affect the most people, and fix them first. Then focus on the non-critical problems that are easiest to fix. Revise, test, and repeat. Then release.
9. Good instructions are no substitute for ease-of-use
   I can't remember who first said it, but I'm often have to remind myself that, "if it needs instructions, it's too hard to use." Instructions are for the 5% of end users who absolutely won't start using something until they've read the entire manual cover to cover. Instructions are not for the 95% of people who only look for help when they can't figure something out.

   I'm not saying that you shouldn't include inline, context-sensitive, intuitive and useful help in every site or product. I'm saying that product should be simple, unintimidating and enjoyable from the start, so that no one will need that fabulous help system you built.

10. Building a great user experience is a process, as much for the organization as for the product.
    
    Few organizations live and breath user experience. Google comes to mind. Tiffany is another. Red Envelope provides a recent example where, to their own substantial financial detriment, told their customers "we can't provide you with the experience we thought we could, so you might want to cancel your order."

    But I think that, as time goes on, more organizations will realize that the user experience is their competitive advantage. Making this transition isn't easy, and it needs to occur throughout the organization. Whenever I start a new project with someone, I will try to explain that a superior user experience begins with an organization-wide commitment to customer-centric product development.

I think it's an ambitious list, but I think it's an appropriate one as well. User Experience, as a field, is changing rapidly, but it's also gaining wider attention. My hope is to focus on what I think are "the basics".

We'll see what happens.