Monday, January 12, 2009

User Experience Design doesn't need to be a big deal

I was going through the process recently of gathering together all of the articles I've had published over the years into a sort of portfolio. This included a bunch of articles written by others that include quotes of mine in them.

I was struck by a theme that runs through a number of articles over a four-year period; a belief I seem to hold that I wasn't really conscious of until I saw those articles laid out side-by-side (so to speak). And that belief is this: user experience design - in all it's forms - doesn't have to be a big deal. Sure, it can be complex; and it can be undertaken on a large scale: but if you don't have the time, or the budget, or the people, it's still worthwhile doing whatever you can with the time, people & resources you have at your disposal.

In March 2005 Builder Au published an article titled What users want, written by Ian Yates. In amongst the material written by the author, and the quotes of other industry people, here's what I had to say (sorry for the editing):
I think one of the main problems that people have in approaching usability is the idea that you need a big team of specialists and it is an expensive exercise and something that it is hard to do," says Baty. The simple fact of the matter is there are maybe half a dozen or so good solid usability principles that will improve your work enormously."

For Baty, just asking the right questions can mean the difference between useable and useless. A visitor to a particular Web site should be able to answer a few questions: Where am I? What is here? What else can I get to from here? How can I get back to where I was?" says Baty. The other key thing about usability in particular is to remember that the sites are not for you, the person building it." By a factor of thousands to one the people visiting the Web site do not know your company, do not know you, do not think the same way you do, view your organisation from a completely different perspective and you need to look at it from that point of view, when you build the thing," he says. The end result of incorporating some form of usability thinking into a project is that it will have tangible benefits to what you are doing. The end result will be better. I cannot stress that enough. It is not a fuzzy, you know, look, everybody feels better because we can say we have gone through and done some usability stuff, it really does make the end product better."

Baty's advice to software developers is simple. For people who are in the development area and who look at usability as being something that they either do not understand or think is an expensive exercise, the simple fact of the matter is, it does not need to be, the more effort you put into it the more benefits you'll get out of it. If you need to, start small, but do not just ignore it.

Three years later I wrote a piece for UX Matters (at the suggestion of Russ Unger, and with input from Dan Szuc & Ruth Ellison) called Bite-sized UX. The whole article looked at what to do when time, people and/or resources are short on your project. You can read the entire article if you want, but in it I talk about the need for targeting your limited time at the areas likely to deliver the most value:

Go for Impact

Concentrate on getting bang for your buck. Depending on your circumstances, you may not get many opportunities to demonstrate the value of UX, and when time is short, there can be a tendency to just do something—anything. It’s an urge you should try to resist. If you want to have a greater impact, ask your project team—the project manager, the development team, and the business stakeholders—a few pointed questions before you get started:

  • What are the critical features of the Web site or application?
  • What features would be hardest for the developers to change once they’ve developed them?
  • What are the areas of greatest ambiguity in terms of user requirements, audience groups, or competitive offerings?

And then ask a few more questions:

  • How can I best document my user research findings, so the project team can use them?
  • Do we have time for iterations? And if so, how many?

With this information, you can start planning some activities that focus on the most important elements of the project—the critical features for success; the features that are hardest to change; or the gray areas of the project—and deliver some real value.

When Whitney Hess asked me before Christmas: "What is the biggest misconception about user experience design?" my immediate response was "User experience design will add too much time to the project." Whitney went on to write all of the responses she received, adding in her own contribution to the question, and published an article on just last week: 10 Most Common Misconceptions of User Experience Design.

Here's my quote as it appears in her article:
Steve Baty, principal and user experience strategist at Meld Consulting, combats the fallacy that UX design adds too much time to a project. “Sometimes a fully-fledged, formal UCD process may not be the best thing to try first time,” he says. “It’s extremely important - and totally possible no matter where you’re working or when you arrive on a project - to make small improvements to both the project and the product by introducing some user experience design techniques.”
There was more to the response I sent to Whitney, part which is worth repeating here:
we should be able (and good enough) to tailor our work process to suit the client and their project.

In Whitney's article, my own quote is followed by this comment from Dan Saffer:
“People cling to things like personas, user research, drawing comics, etc.,” notes Saffer. “In reality the best designers have a toolbox of options, picking and choosing methods for each project what makes sense for that particular project.”
I'll end with the same ending I used in the UX Matters article:

If you don’t have the resources of a large UX team, with the budgets and timelines to undertake the ideal user-centered design (UCD) or activity-centered design process, you can still make a valuable contribution to a project. Undertake small, tactical, iterative user research activities throughout the course of the project. Focus your efforts on the areas of greatest impact, and produce documentation that your project team can understand and use efficiently.

If you demonstrate value through a series of small, high-impact UX activities, the extra budget, people, and timeline flexibility you need will eventually come your way. Then, you can come closer to implementing your ideal UX process.


Austin said...

Awesome. I wholeheartedly agree. Get everyone to think the right way and just do something—anything—and the UX just flows smooth like buttah.

Unknown said...

Great post. Are companies receptive to UX?, what is the culture of the company and team you are working with? and what are they being measured on?

My guess is if the company is not customer centric and the culture/project does not reward UX thinking ... you have almost no chance of succeeding - big or small.

Interesting to see how much UX is absorbed in this demo of the new Palm - the passion really comes through -

Austin said...

I really believe that our real job is to design the organization that designs products; to infuse the entire organization with UX.

I think a good way to do this is with design stories that carry little mind bombs and spread good thinking.

Steve 'Doc' Baty said...

Dan: that's why I think you need to be keyed into delivering value right off the bat. What are you going to do on your first day; first week; etc to make the product/service/site/app better?

Deliver first; ask for changes second.

Austin: thanks for both comments.

Changing culture, process, systems etc is much, much harder and often more removed from the UX team. But! given the opportunity - and if you look around you'll see this in the more successful companies - we should be thinking about the whole-of-company mind-set vis a vis user experience.