Joel Spolsky of Fog Creek Software recently claimed on his blog that “when people are successful at controlling their environment they become happier, and when they can’t control their environment, they get grumpy”.  This can certainly be true. But does this mean we, as experience designers, have to concede control to the user to provide a favorable experience?

Let’s take a look away from the glow of the laptops and monitors and go outside for an appropriate, though perhaps seemlingly reaching, example.  As an avid golfer, I’ve played a number of courses where the layout of the course is prohibitive to walking.  As a result, I’m required to use a golf cart, many of which are equipped with global positioning system software.

The GPS system often features scrolling sports scores, the club house’s menu with one-touch ordering, the ability to summon the on-course beverage cart, and of course the layout of the particular hole we’re playing, complete with multiple views of the fairway, green, and so on (the blog post discussing these GPS golf interfaces is for another day).

While these features are a great amenity to the experience, it also allows the pro shop to monitor exactly where I am on the course and to confirm I’m keeping up with the pace of play.  The software also regulates where I can drive on the course, either to protect its property (by forbidding the cart to drive onto greens or into bunkers) or to protect me (by limiting the speed of the cart, particularly on steep slopes).

In short, though I feel like I can drive the cart anywhere and as fast as I want, the software system is actually well in control of the environment but offers me an implied perception of control.

Such a paradigm of perceived control works well in the software space as well.

When designing software, the ideal experience does not provide total control by the user, but a perception of control by offering relevant, context-aware tasks and content to the user.

For instance, many online shopping cart and registration process flows remove the site-wide navigation to limit distraction and to focus the user’s attention on the imperative task.

From the business’s perspective, regulating what users can and cannot do can protect users from themselves and prioritize important actions or content.

See the screenshot from the familiar Amazon.com checkout experience as an example of limited navigation.  The user cannot begin browsing for another book here and risk abandoning the cart. Likewise, the user cannot undo any information that’s previously been submitted which could confuse and aggravate the user.

In other cases, an adaptive interface may be instrumental in providing users a feeling of control.  After all, if a fledgling investor just opened an account with $1,000 in a money market fund and identified himself as a novice investor (required during brokerage registration), there may not be a strong need to offer foreign currency exchange research as a primary option.  Of course, such links to currency exchanges are available, but not as prominent as more common tasks based on the persona model of a novice investor.

And while much of Spolsky’s article really cites the benefits of system feedback and not user control, there are a few strong examples that outline how we can design software that provides this perceived control.

For example, Spolsky discusses how implementing AJAX allows his software’s users to manipulate table columns and employ keyboard shortcuts.  Indeed, the ability to drag or hide table columns or send keyboard commands to the system can certainly instill a feeling of control in a user.  If these features were designed to be available after the user was familiar with the system then that sense of control should be heightened, as the user will have developed his confidence in his skills and mastery of the system.  Immediately providing these features risk burdening the user with distracting glitz.

So while it’s certainly true users may say that want full control of their software, the systems that offer a perception of control while monitoring how its users interact with it will have a sturdier foundation with which design a better experience.

Paul Sherman‘s recent article Usability Testing ≠ A Good User Experience attempts to establish that usability testing doesn’t guarantee good user experience.  Claiming that the only reliable method to developing a good user experience is “strategic design”, the author asserts that focusing on “tactical usability” is a myopic exercise.

I certainly agree that rigid, task-focused usability testing is unlikely to glean new insight into a product or service’s user experience.  And a usability test can often hinge on the quality of the script and system and the personalities of the moderator and participant. But does user testing only elucidate whether people can successfully complete a given task? I have my doubts.

Dr. Sherman’s argument that usability testing doesn’t quantify user enjoyment is not new. Long before User Centered Design principles were accepted in development teams, software interface designers and developers still needed to assess the usability of the systems they unleashed to their clients.

In an effort to de-humanize usability testing and provide quantitative results, engineers often relied on GOMS (Goal, Operators, Method, Selection) and Keystroke Level Models to assess the usability of existing systems.

Often these findings would be presented in numerical reports claiming that Feature A was 1.4% more usable than Feature B under strict, predictable circumstances.  Such tests proved effective enough for years of practical use, though today they almost seem quaint when compared to the user-driven research practices of the present.

Today, most software developers and their management teams need and want usability tests to reveal how people feel about their application, while also confirming their audience can successfully complete step 2 before attempting step 3.

Usability scripts can elicit how people feel about a system, and a moderator tasked with observing participants’ interactions and emotions can also glean valuable insight, at times even tabling task-based questions to prompt a particularly effusive participant to expand on how she feels about the system.  Granted, you can’t “tactically” assess those emotional reactions, but it’s also safe to say it’s difficult to fundamentally quantify any user experience as well.

Dr. Sherman continues that usability testing cannot “craft a unified user experience, plan for tomorrow’s user experience, [and] create delight, loyalty, and stickiness”.  Well, that’s certainly true.  But a usability test or other user research can identify if the user accepts and welcomes the unified experience from screen to screen and through the system’s interactions.

And a usability test can also provide insight into how to build future releases of software or web sites as well, or what may not be important at all.

Perhaps most importantly, I could argue it’s the usability test that will prove whether the designer is creating a system that is capable of instilling delight and loyalty.  I’d much rather stand behind a system that’s been put in front of my target audience and generated feedback than trust the words of my designer that he sprinkled some “strategic design” into his workflow.

Back in 2007,  UX Matters published Connecting Cultures, Changing Organizations: The User Experience Practitioner As Change Agent wherein Dr. Sherman wrote

Above all, our goal is to bring the users’ wants, needs, abilities, and limitations into the organization, and ensure that the organization doesn’t forget the user during any of the design and development stages

In my experience, usability testing is a prime opportunity to confirm your system is built with an understanding of those wants, needs, abilities and limitations.

Over 45 minutes, we discussed an introduction to human factors, cognitive psychology, and interface design heuristics. And since Mr. Brown’s class is in the beginning stages of a web design project for a local business, we also used the time to focus on identifying audiences, task modeling and other discovery-themed processes.

Mr. Brown has done an exemplary job at recruiting phenomenal speakers to talk with his students–to the point that many of his speakers contact him requesting to speak (I fall into this camp).

His students certainly appear to enjoy a dialogue with practitioners who have real-world experience that they can immediately apply to their own schoolwork, and hopefully put to use for years to come.

Hopefully more high schools, community colleges, and universities will begin or continue to interact with the technology community to benefit their students.

But us practitioners cannot wait to be contacted.

Instead, we should introduce ourselves to those who could benefit from our experiences.  Yes, it’s personally rewarding. But more importantly, those experiences can shape the thought and actions of our future interns, colleagues, and partners.

In the context of  user interface design, even the term personality itself can be confusing.  Luke Wroblewski’s Design Philosophy summarizes that

The combination of a site’s organization, interaction, and visual presentation creates and supports the personality of a Web site…

and that

an appropriate and evocative personality not only tells the right story to your audience, but it also provides distinction, appeal, and wholeness to your site.

In short, tailoring navigation, layout, color, and messaging to your audience shapes not only how they’ll use your web site, but also how they’ll feel about the experience as well.

Audience Considerations

However, some people may argue that many web sites or applications are simply utilitarian: the user should be able accomplish his or her task without inconvenience.

Others may claim that spartan software with more functionality will be more appealing than software with fewer features but more personality.

But before we make sweeping generalizations that these people will always like that software and those people will always approve of this software, we must remind ourselves that the personality of web site must be tailored to its users.

Do EKG monitors need personality? Or do heads-up-display interfaces in jet aircraft cockpits require a fun interface? Of course not.  The priority shifts from providing the user that aforementioned “appeal and “wholeness” of the experience to relaying critical information free of distraction or clutter.

In other words, systems need to balance useful functionality with a well-planned strategic personality.  Unfortunately this is easier said than done.

Case Study

I recently purchased a Garmin Forerunner 305 to track my training as I prepare for four triathlons, a few ten mile races, and a half-marathon this year.  It’s a GPS-enabled personal training device that can monitor my heart rate, distance, time,  an estimate of calories burned, and a few other assorted data from each running or cycling workout.

While the device’s screen provides summaries of each workout, the device sends the GPS information and each workout’s data to my computer where I can view the relationships of each workout or a number of workouts over time.

Garmin provides its own software for analyzing my workouts, but the data can be imported by a number of other applications that aren’t developed by Garmin or its partners.

We’ll examine Garmin’s own Garmin Training Center, Berbie Software’s Trail Runner, and SportTracks by Five Zone Software, plus the less-robust Nike + system to determine if these user interfaces’ personalities enhance the user experience.

Welcome/Home Screens

The Garmin Training Center and Nike + display a home screen, whereas Trail Runner and SportTracks show the latest workout.

Garmin Training Center

Unfortunately, the Garmin Training Center default screen is devoid of any personality or utility. It simply reminds me I was born 31 years ago and my weight from when I entered it in January, and my name.   In addition, there are also numerous codes and zones, though they’re not tailored to my performance.

Nike +

The Nike + home screen takes a different approach.  Instead, the welcome screen displays the latest workout, complete with a Flash-based animated jogger showing bouts of extended speed and exertion.

Here we can see the stark differences in an application’s personality by comparing the Nike + screen and that of the Garmin Training Center.  It should be said that Nike’s intentions are likely different than those of Garmin’s, after all, as this web site is clearly a vehicle to drive their following to purchase new products.

It may also seem unfair to compare a Nike product, which no doubt has been combed over many times by their marketing and interactive agencies, to Garmin’s software that some may view almost as an afterthought to the device itself.

But simply seeing these screens together shows just how little attention or thought was given to the Garmin interface, even down to the decision to show the user’s birthday, weight, and name as primary information, leaving the workouts on the left as secondary.

Individual Workouts

Each of the GPS-enabled applications incorporate some map visualization into the interface, though some implementations are more crude than others.  For example, the Trail Runner system uses Google Maps, but the Garmin system appears to be a custom-built mapping engine, and looks like it belongs back in 1985.

Trail Runner:

The Trail Runner interface uses the Aqua interface components to deliver a consistent experience with the Mac user’s other applications.

This interface helps define the distinction between a good personality and a usable product.   It certainly looks the best, using the aforementioned Google Maps API, icons instead of burying everything in pulldown controls, and using color to connote similarities and differences between data.  Unfortunately, there are numerous usability problems at the task and process level, and not necessarily as a result of poor interface design.

That being said, an adaptable interface would be a huge blessing to the overall experience.  Though I will likely never go back to using the Nike + system, or use my iPhone instead of my Forerunner, these icons will stay cluttered at the top of the primary navigation as long as I use the software.  More advanced, or niche features, such as saving routes, managing my exercise plans and more may be better served for someone who uses the application for more than tracking runs, calories, and how frequently I exercise.

Perhaps crystallizing the argument that a good user experience can almost trump a less useful application, the personality of the Trail Runner application keeps me wanting to return to it, even though the system’s shortcomings continue to frustrate me.

Garmin Training Center

These screenshots from both Vista and Mac OS show that the bare, utilititarian application addresses the simplest use case: it displays how far I ran, where I went, and it shows my heart rate throughout the activity.

Vista top |  Mac OS below

Where is its personality? Good question.  The system buttons, controls, and components don’t tell any more of a story than a balance sheet. But the interface stays out of my way, unlike the more attractive Trail Runner.  In fact, if I didn’t know that this interface represented a person’s run, I’d probably assume it was graphing some complex engineering system.

Nike +

The Nike interface simply shows what data it has to work with: time and distance, and the speed over which that distance was traveled.

The bumps in the line indicate when the runner’s speed increases, and does not represent moving uphill or downhill as could be inferred by the running animation.

But even with the broken mental model of running uphill as an increase in speed, the interface still features more polish than the more advanced Garmin Training Center, and summarizes the information more prominently than the Trail Runner.

The soft shadows, gradients, and reflections all suggest a refined, sophisticated experience.  It’s also similar to many of Apple’s design assets, which strengthens the holistic bond between the shoe, pedometer, and iPod. And even though some of us in the design community may be tired of this look, it’s likely still perceived by their wider users as professional and accessible.

SportTracks

The SportTracks workout interface provides a unique approach compared to the earlier interfaces discussed here.

The personality is certainly down to business moreso than the Nike + system; the rows of data from prior workouts in the Daily Activity panel provide more context to the most recent workout (found in the Summary panel).  Some could argue that the interface doesn’t prioritize data effectively: quickly scanning the screen may not indicate where I should focus or what’s most important.   But perhaps that lack of heirarchy is part of the application’s personality: it’s designed to be put to work but flexible in how you use its features.

Workout Summary Screens

The summary screens don’t deviate from the personalities established by the screens discussed earlier.

The Garmin Training Center elects to display only numeric totals of distance and elapsed time in the top of table columns, whereas the Nike + system provides no numeric value of how far the user has run.

It’s unfortunate the Garmin Training Center doesn’t borrow from the SportTracks system and display a chart of my long runs compared to my tempo runs or cycling workouts; instead I get a crude map of Central America, central Africa and southern India.

The SportTracks (below)  summary interface maintains it’s rather bland personality while still keeping its data front and center.   I’m curious if additional data such as heart rate could have been represented using color in each bar representation of a workout.

Conclusion

These applications are proof that an interface’s personality can enhance the user experience. However, relying on such personality to compensate for usability shortcomings or limited features is difficult at best.

Determining what tasks users will want and use and the various mental models of how those users will engage with the system’s features are far more critical than applying gradients to backgrounds.  But when those backgrounds, in addition to layout, color, and language, cohesively align with how the user expects the web site or application to behave, a personality can develop that the satisfied user will turn to time and again.

However, some designers and developers are creating new usability issues as they strive to make their sites as usable as possible.  In other words, while trying to make their site user-friendly, designers have ultimately undermined the usefulness of their web site or application.

These 5 mistakes all have the best of intentions, though when experienced first-hand they can be maddening.

1. gratuitous keyboard shortcuts

Smashing Magazine is correct when the blog includes keyboard shortcuts and hotkeys as one of 12 Useful Techniques for Good User Interface Design.  It doesn’t take a human factors expert to understand any time a user removes her hand from the keyboard to reach for the mouse and point to a target that she loses time and efficiency.

But keyboard shortcuts, while efficient, should only be considered for repeated actions by expert users, and not as a novel way to click a link to read a blog post or to add a product to a shopping cart.

While some uses are generally well received, particularly on Boston.com to move sequentially from one photo to another, gratuitious keyboard shortcuts can be confusing at best, and destructive at worst.

In addition, implementing haphazard shortcuts may also override system-based keyboard shortcuts that users with unique needs rely on to browse accessible web sites.

In most cases, consider using keyboard shortcuts only when developing an application for a specific audience or task, rather than a site designed for the general public.  It’s critical to weigh the value of offering a complex interaction that may appeal to only a few if it risks confusing many.

2. aggravating displays of ancillary information

Supplemental information can provide a web user with integral knowledge he needs to act.

It’s good practice to provide a definition of a term that may not be clear to everyone, or to offer supporting product information such clothing size and fitting guides. But providing such information on its own page, or worse, on a glossary-like page using anchor links, creates a back and forth pogo stick-like behavior that can disorient, disrupt or simply frustrate users.

Instead, consider implementing a pop-up box or overlay.   When using small pop-up boxes, it’s important to also build a one to two second delay from the time a user mouses over a link to the time the pop-up box appears, otherwise you risk an even more egregious error by littering the user’s screen with appearing and disappearing pop-ups windows.  Overlays should be easy to close.

3. drag and drop without clear targets

While drag and drop interactions can be engaging and in some cases more efficient than clicking a link (though this remains to be proven), drag and drop is rife with possible gaffes that undermine the usefulness of the interaction.

For instance, when a user clicks on a target to be dragged, not only should there be visual feedback that the item is to be dragged (don’t rely on color alone–consider enlarging the dragged item and changing the cursor), but the drop area should also be highlighted to remind the user where to drop the dragged item.

In the example above, from Blockbuster.com’s queue management screen, we see only a thin black line indicating where the dropped movie (“Raising Arizona”) will go, and the cursor remains a pointer, rather than a closed-hand cursor.  Furthermore, each non-dragged movie also shows the standard roll-over state (in this case “Searching for the Wrong-Eyed Jesus”), also potentially confusing the user by sending mixed signals of use.

So yes, the drag and drop is a bit easier to order a queue, but usability concerns arise when addressing how to prioritize the movies you want to watch.

4. only using either Tab or Enter in Auto-complete

Auto-complete is an effective, easy to understand convention that provides users an efficient method of selecting an option in a drop-down list.  However, some developers are only programming one method of selecting an item in the list, while other sites provide two ways of committing to a selection.

For instance, Kayak.com allows its users to select an airport from it’s drop-down list using either the Tab key or Enter key.  If only one method of selecting an auto-complete option is programmed, a user may inadvertently use the one not accounted for and suffer the consequences.

If a user were to use Enter, for example, and the Enter key does not trigger the selection, the user may submit the form and likely generate an error.

5. failing to create useful filters

As AJAX has become more commonplace among web sites targeted to less-technical audiences, the ability to effortlessly filter information has greatly proliferated throughout shopping web sites, be it for clothing, flights, or hotels.  Unfortunately, not every filter is particularly valuable in separating noise from useful information.

The Gap’s family of web sites, including Banana Republic, provide a means to show only the clothing sizes you elect to complete–you’re not forced to only view jeans or shirts if you’re just browsing to see what’s available.

Nike, however, takes the opposite approach and only allows users to specifically identify one and only one category of clothing.  Users cannot choose to see shorts and t-shirts in the category running; they must choose between one or the other.

When considering implementing filters, make sure to evaluate as many use cases as possible–though one group of people may want to go shopping for t-shirts, there could be a larger, more willing group of people who are looking to update their running wardrobe for spring.

“Doing user experience”, or designing wireframes, prototypes and a sitemap (sans user research) will leave some people thinking they’ve completed what they see as the UX family of deliverables.  Some assume with a heuristic analysis in hand, they can finally check off UX from their punch list and move on.

Whitney Hess‘s recent article 10 Most Common Misconceptions About User Experience Design addresses how UI design is often thought to be interchangeable with user experience design.  Her summary rightly states that the interface design is but one piece of a puzzle that has many different corners, edges, and pieces.

If experience design was in fact user interface design, then it would be perfectly logical to assume that if a company’s web presence featured a bad user interface, or poorly designed interaction patterns, then likewise the user experience would also be poor.  Likewise, any company with a good user interface would therefore have a good user experience. Right?

Wrong.

Since a user or customer experience is a holistic engagement between a person and the company offering a product or service, and not simply tied exclusively to the interface that acts as a medium or messenger, we cannot assume that if one element fails that the entire experience is a failure.

Forrester’s 2008 Customer Experience rankings reveal enlightening affirmations that a good or bad web site interface is no guarantee of a happy customer.

Southwest Airlines, the list’s highest rated airline,  has surprisingly basic user interface troubles in trying to pay for a flight, yet their customers overlook such design flaws either by repetition or because they and their bags arrive where and when they want to for a fair, clear price.   In such a case, the ultimate goal of the site, and the company, trumps a faulty design pattern.

Conversely, Comcast’s cable and internet customer experience ratings are at the bottom of the list, despite a fleet of knowledgeable, competent user experience staff and industry experts who have worked with a number of their divisions.   But even though Comcast’s various web presences are easy to use and generally a success, a good web site is useless if your cable modem isn’t working and the Comcast repair technician is catching a few winks on your couch.

None of us who try to define and design a user experience should simply assume that if the user interface is good enough that business will come and customers will be happy.   But the UX practitioner who fails to review all customer touchpoints–mailings, newsletters, call center activity, event the front desk–and solely focuses on what color gradients to apply on the web site does so at his or her own folly.

Spool then is interested to see if his readers have any better ideas that could make the screen communicate more information easily and concisely.  As someone who regularly (maybe obsessively) tracks packages, I was eager to spend a few minutes using simple design patterns and prioritizing user-centric  information and seeing how a new layout could benefit UPS customers.

My attempt:

Though this particular screen shot is for a package already in route (I already have a few things on their way so I just used live info), it should be easy to see how a package that has been requested to be picked up but has yet to be shipped could be communicated.

I also attempt to emphasize the delivery date, which, curiously, is often unfindable on a tracking screen.

And while I’m fascinated to learn my new t-shirt has made a pitstop in Kansas, I’m usually more interested in when it will arrive at my door.

But what happens when you find yourself on a project or worse, a full-time job restricting how you can provide an ideal user experience for your business’s users and clients?

While every job, gig, project, or contract is unique, there are some shared opportunities that lie in even the most muddled of projects.

Below are a few methods to provide the best user experience possible that could go undetected by unaware bosses, managers, and others.  All of these cases assume the UX practitioner has pleaded for user testing to sort out these issues but such requests have been denied or ignored.

Problem:
Client has already determined the information architecture, navigation, and labels of the site and won’t listen to dissenting opinion.

Solution:
Even if your client demands links in the primary navigation to include  “Misc.”, “Hit Us Up”,  and three red circles to indicate three unique categories only revealed on mouse-over, you can still find some opportunity to make such dreadful navigation more useful than if you quickly nodded your head in surrender and began debating whether to jump off the building head-first or tucked in a cannonball.

If the client has decided what the navigation will be,  hopefully you can determine how it will be built:

1. Rely on semantic code to at least provide some meaning by using an unordered list to arrange the links rather than a table with columns and spacer gifs.
2. If the client requires images in the navigation (assuming you’ve provided the boilerplate warnings against doing so), use the images as background images of the list-item tag so you still have legitimate markup in the tag itself, and use CSS to only show the background image.
3. Use alt and title attributes as appropriate. If the boss really wants “Hit Us Up”, you may be able to get away with “Contact Us” as the link title.
4. Make the entire list-item clickable, not just the text itself.  Increase the size of the hit-state for easier clickability.
5. In addition to color, use font weights or other styles to distinguish links from one another.  Color is unreliable to connote meaning as it’s susceptible to cultural interpretation, it varies across displays, and some users could be colorblind.  If you’re using text links, consider displaying primary links in bold, and secondary links in normal font weight.

Problem:
The boss hand-picks terribly cliched stock photography for the home page, and even cornier text to overlay on the image.

Solution:
It’s safe to say laughable stock photography and feature text will burn you right in your craw every time you look at the site whether it’s the first time or 500th time. But regardless, here are a few ideas that could be worth explaining in an interview when the creative director asks how you’ve handled adversity.

1. If the featured text isn’t grammatically correct, take a chance and lay it out with corrected language.  Granted, you may get your hand smacked for changing exactly what was submitted, but you could also be the last line of defense before later embarassment that will look like you failed to catch.
2. Attempt to add additional creative changes to the photo so it looks less like everything else.  As long as you don’t follow other cliches or trends, such as ink blotches, swirls, stickers, or slanted lines, altering the hue, color, or sharpness of the image may breathe some originality into the image.
3. Holistically lay out the image with the rest of the site.  Even if the image is unoriginal and the text is terrible, it will stand out even more if it’s wider than its host column or shorter than a complimentary shape or image.
4. Even if the text’s meaning is awful, you still risk looking like an amateur if you don’t lay it out well.   Yes, even “Think outside the box” can look acceptable with the right font in the right place.

Problem:
A task or process is complicated, unconventional, and confusing, and you cannot alter the sequence of steps due to technical limitation.

Solution:
Hearing that step 5 always has to come before step 3 because a programmer from 6 years ago built it that way is always frustrating, particularly when competitor sites execute similar tasks flawlessly.   But a few helpful tips can make confusing steps a bit more predictable.

1. Provide an overview of the steps necessary to complete the task at hand.  Inform your user what lies ahead so you limit surprises.
2. Continue showing those steps during completion, including steps yet to come, and steps that have been successfully completed.
3. If technology allows, provide the user the ability to revisit earlier steps to confirm his or her input.
4. Pick the low hanging fruit.
   Provide inline form validation, usable calendar date pickers, and let the system format data as necessary, instead of the user.
5. Provide helpful definitions…
   Use pop-up tips or definitions immediately following the unclear concept, not off in another column across the page that may go unnoticed.
6. But don’t overwhelm the user with “helpful advice”
   If you inundate the user with the aforementioned tips (i.e. the label First Name includes a tip reading “Enter Your First Name”), you’ll dilute the quality of the tips that are necessary to leading the user to success.  Using only a few tips will let the tips you need stand out.

We don’t always have the luxury of working with perfect clients or sublime art directors. But there are opportunities to enhance the user experience even when crippled by draconian design guidelines.

Recently much has been written in academic and practitioner circles regarding how user-centered design should play a fundamental role in the development of software, web sites, and web applications.

However, UCD principles have yet to reach many development methodologies of today, such as agile programming, leaving the user experience of many task-based web sites under-acknowledged.

This paper provides a case study examining how user-centered design methods identify, design, and deliver the optimal user experience from the start to finish of a goal in an agile development
environment, and why these practices are imperative as we see a paradigm shift from
static information-based web sites to engaging task-based web systems.

Download the full document.

But first, Owens summarizes that the current web design, programming, and strategy workforce

…is very well-intentioned, and either doesn’t know the difference between what they do and real User Experience work or are just as eager to learn as anyone else. Yet they know that talking about User Experience sells projects and so continue to talk it up.

He continues that he has been

seeing too many people buy into User Experience methodologies that are half-baked, if baked at all. User Experience, for most people, boils down to making pretty interfaces. Good color palettes, Flash for everything, and anything that sort of looks like a Mac interface are often presented as the whole of good User Experience.

Where I begin to lose Owen here is if he’s purporting that clients only expect good color palettes and are ready to release their new work unto the world since a UX expert blessed the color scheme, or, if the color scheme, Flash, and Mac-like UI are the only deliverables a so-called UX expert provides his clients.

That brings us to another of Owen’s points about what characterizes a UX expert: They do user research, which he clarifies more by stating “they have a healthy respect for how much they don’t know, and they absolutely insist on observing real users at work before they ever start a wireframe”.

Now, during my graduate studies at UMBC I was constantly reviewing research studies that examined how people interact with computer systems, usability, and interaction trends to know enough about how research is conducted (in addition to actually doing it professionally as well).  As a result,  I argue simply saying “they do user research” is really inadequate; rather, a UX expert needs to know how much and what kind of research is necessary to fully design a user experience.

Often times companies will pat themselves on the back after conducting one or two usability sessions with about 5 to 10 participants each, for a site that may be viewed thousands of times a day, or even per hour.  Is that sample sufficient?  If it must be, (which in some instances is the case), then that client better have a UX expert who can also provide heuristic evaluations based on years of experience evaluating systems and conducting user tests to glean how people generally interact with similar interfaces–Mac-like UI or otherwise.

It almost seems the novice UX practitioner could unwisely advocate for either the wrong type of testing (surveys instead of contextual observation, A/B testing rather than  interviews, etc.), lobby for not enough testing, or simply fail to understand how to interpret the data aquired through testing.

In short, it’s simply not enough to say, “well, I test, therefore I am (a user experience expert).”