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.

Accepting too much work leads to shortcuts, which results in shoddy work, Irizarry writes.   However, in some situations, those shortcuts actually provide an opportunity for designers and UI developers to streamline how they build what they’ve designed.

As numerous familiar phrases and cliches remind us, people are resourceful when backed up against a wall of deadlines, expectations, and promises.  The rub, of course, is how to execute that resourcefulness.

Irizarry writes that some shortcuts may involve deceiving the client by delivering a pre-paid template under the guise the work is an original design, tailored to meet the client’s unique needs.   He summarizes that the unscrupulous designer basically assumes the client will be none the wiser and can make a quick, easy buck at the expense of his own integrity (but only if he gets caught, of course).

So why cut corners? Irizarry writes it’s simply designers taking on too many projects, each complex enough to require individual professional attention (i.e. what the client believes he’s paying for).   While the easy solution is to simply say “right on, I’ll accept fewer gigs”, a designer using the right shortcuts can still earn a decent profit working the same number of projects (within reason), but with a more efficient workflow.

Rather than try to sneak a pre-paid template by a client, a custom design with a foundation built on the Yahoo! Grids or Blueprint CSS framework can yield even more success since you’ll have the flexibility to extend the design based on evolving client needs.  In addition, you can base almost all client work on these frameworks, so you’ll have a secure, understood foundation already built regardless of client or audience.

Trying to hack together a interaction based on proprietary, outdated code may seem like a cut-and-paste shortcut until that designer realizes the JavaScript used there doesn’t work elsewhere.  Learning JQuery, Scriptaculous, or other JavaScript libraries (and I use “learn” quite liberally here) assure the transition effect on your “widgets” page will also provide form validation on your contact page, without endless hunt-and-peck Google searches, forum postings, and list-serv pleadings.

Identifying and implementing interaction design patterns is critical to efficient work.  While undertaking numerous projects at once may reveal similar interactions, understanding the task itself reveals similarities regardless of audience, technology, platform, or client.

Understanding that a shopping cart check-out procedure or account-opening path isn’t unique is the first step to recognizing a pattern–the second step is to find other uses that make it a pattern.

Jennifer Tidwell’s text Designing Interfaces , Alan Cooper’s About Face 3: The Essentials of Interaction Design, and the upcoming Bill Scott and Theresa Neil text Designing Web Interfaces: Principles and Patterns for Rich Interactions all address user expectations to complete similar tasks across different web sites.  Not sure if a link should be disabled if it’s content isn’t available?  Look here first before spending time debating whether to use a class or an id to style it (since best practices indicate you either shouldn’t show it or provide an explanation why it’s disabled).

Many resources for design patterns are available as blog posts for even easier browsing, such as PatternTap.com, UI-patterns.com, UIpatternfactory.com, and more.  These online resources outdo the printed texts by often providing live links to the patterns themselves, so designers can immediately see how these patterns are deployed.

There is no excuse for lazy development or design, particularly in an economy where each job and every check keeps you one more step away from disaster.  By knowing how to put frameworks and fundamental patterns to work for you and your clients, you streamline your design and development process without added expense. You also don’t subjugate yourself to a workflow that is doomed to providing if not a mediocre product, then at least an inefficient, mediocre process.

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).”