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.

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.

As LinkedIn provides new reasons to draw its audiences back to its site, with such features as the Blog Link, the ReadingList by Amazon and others, it seems a few of these new features have been brought to market without fully considering how a typical visitor may actually use some of these features.

Specifically, I continue to shake my head with frustration almost every time I consider reading a discussion found in one of my  Group Updates (screenshot below, names blurred by me).

Screenshot displays poor choice of clickable links

A quick glance at the screenshot reveals that the names of people commenting in each discussion, and the person who initiated the conversation, are bold and blue and when clicked, display the person’s public profile.  Also clickable, though deprecated, are the number of comments found in the conversation.

The issue, of course, is that the conversation title is left unclickable.  My only access to the conversation is via the comments link, which displays the last comment.  In  a conversation with multiple comments, the original question is off the screen, forcing the reader to scroll up to the top.

And while there is value in learning more about the people in shared group, that connection is likely ancillary to actually reading or joining the discussion.  There’s a greater likelihood of someone wanting to read the profile of a person after he or she has already read that person’s response rather than blindly clicking the person’s name with little or no context.

While I admit there’s a possibility I expect a system with over 3 million users to accommodate me, I really don’t think that’s the case.

I’d love to hear a justification against an example as simple as this:

Discussion topic is first priority

Here I still have access to the profiles of people participating in the discussion, but I’m drawn to the conversation topic, now in blue and in bold.

When users scan the page, they are drawn to the bold names in the Connection Updates, and the conversations in the Group Updates–a contrast that can retain the user’s attention, not divert it.

Seems reasonable to me.