The Experience is the Brand

You Bought Vanilla Mint Flavored Listerine – Why?

Admittedly I’m a terrible bargain hunter – I check around a few sites for competing prices but will always buy from Amazon in the end; I go to BJ’s with the intent of stocking up on bulk toilet paper and socks, and come home with a 3 gallon jar of pepper shooters; I buy stuff off the clearance shelves at the supermarket, paying little attention to the expiration date (can Calamine Lotion really go bad?)

Last month I came home with one of those huge jugs of mouthwash that’s large enough to require an engine hoist to pour, at what I thought was a great steal. It’s something I buy all the time, and it was on sale for what seemed like 1/2 price.

Had I the presence of mind to look at the label, I might have thought twice about bringing home a barrel of vanilla-mint flavored mouthwash. It seems an odd combination – to be sure, it was taste-tested and focus-grouped – who wants to start or end their day  clean-rinsing their mouth with a sundae?

There are at least two explanations for why I made the mistake that I did: the first is that I suffer from Man’s Disease: a genetically-inherited condition which renders me incapable of distinguishing any readily identifiable object less than 18 inches from my face.

A second explanation lay in the subtle differences between the packaging of what I thought I recognized as a familiar product, and that of a newly-released variant the manufacturer was obviously (and not successfully, judging from its occupation of the Clearance Bin) testing.

The strategy is not a bad one: if what you have to offer is only slightly different or new,  copy something well established and hope no one notices. If it works and your audience stays with you, slowly differentiate the packaging to start drawing more attention to the subtle differences.

It works in a marketing context because we tend to glom onto the familiar, and if you have what already passes for a sense of familiarity with a customer, there’s little point in making the experience a jarring one – why make a customer think harder about a purchase that they already want to make, if you’re only trying to affect a slight change in behavior?

In an experiential context, familiarity is even more useful. In the craft, we call it affordance: the tendency of an object or widget to do what it looks like it should do – buttons push, switches flip, and dials turn.

In developing a digital experience, chances are you are going to have your hands full just making your concept make enough sense at a marketing level (It’s a race car, for hamsters!!!),  you might as well make everyone’s lives easier by not trying to invent a new interface for placing an order, or contacting customer service.

Go with what people already know.

In Praise of Long Copy

It is fashionable, of late, to conclude that brief, punchy copy is best suited towards capturing the attention of people online, because as everyone knows, nobody reads anything online, ever.

This strikes me a conflation of a well observed and well documented browsing habit among most people, who tend to scan rather than read. And particularly in terms of lists of items (products, news headlines, categories, etc.), scanning is even more punctuated, limited to the first two words or so of each item.

Is it a contradiction, then, that some eyetracking studies have shown that the Ogilvy Layout still works? Or would it simply be a mistake to conclude that offline and offline behavior are so different that conclusions drawn from one medium simply couldn’t apply to another?

Now, in magazines, which are mostly read as a diversion, the first thing to get scanned are pictures.  We are visual creatures and pictures typically convey a lot of information (and emotion) fast, so a strong visual is almost always going to be the first thing the eye fixes on when the reader is engaging in general browsing for interest.  Please note, though, that this scanning order changes for task oriented individuals interacting with a website.  People scanning a web page redefine “worthwhile” by relevance to their task, and therefore focus on the headlines first.

- Jeff Sexton, Tests Indicate Ogilvy’s Old School Layout Still a Winner

Behavior changes with context, so it’s perfectly reasonable to assume that the context of an online experience is different enough that the “old school” rules don’t apply – users don’t read, they scan, for instance. How is it that scanning – apparently superficially – conveys enough information that users can choose intelligently among the maelstrom of options available to them? Are they so focused on their task that all distractions are ruthlessly cast aside in single minded pursuit of their goal?

This post started as the result of an item in my Twitter feed, led through three other related, linked articles (all quoted here) and will probably terminate in a half-finished thought. All the while, I should have been assembling an analytics dashboard for a client. Using oneself as a proxy for examining the behaviors of others is never a good idea, but I doubt that my experience in the last 30 minutes is drastically outside the mainstream.

We humans have remarkable brains, capable of processing scads of data coming from multiple inputs. But we are hard-wired to attend to novelty, and generally not quite so good at efficiently filtering out distractions. Why do 30-50% of DVR owners not skip the ads? Is it because so much of the advertising out there is so good, we just can’t bear to miss it? Or is it because the change of scenery is, itself, interesting?

I’m inclined to think – though I can’t yet prove it – that the tendency towards brevity, pithiness and punchy copy has not been successful in the aggregate. There may be specific advertisers who’ve benefited, but if the whole of the marketing universe has simply been sub-divided into smaller pieces and split between more voices, the overall quantity of message hasn’t improved (and I’m of the belief that more voices in a conversation tend to degrade its overall quality.)

Can a truly persuasive, high-quality argument (in the sense of a position one wishes to communicate and convince others of) be encapsulated in a 10-word snippet? In 155 characters? Can a customer be won for a lifetime of loyalty with a one-liner? A statement so inexplicably powerful that resistance is futile? (Wouldn’t that be quite an effective weapon?)

What does it mean to test early, and test often, really?

Working, as I do, in a software consultancy, I spend some fair amount of time providing estimates on how much time it’s going to take to "do UX" on a project. I think there are as many ways to estimate effort on an activity like this as there are people who "do UX". Some of the most popular methods I find in use around here begin with a question. A question like:

• "How much time do we have?"
• "How much money does the client have?"
• "How much did it cost last time?"

I’m going to start referring to these methods as the Holy Trinity of estimation techniques: The Deadline, The Budget, and The Past Experience. All three are simply accepted by the faithful as truthful, honest, and reliable. But timelines can change, budgets can shift, and previous experience is most useful only when you’re building the same damn thing over and over. The foundations of this faith are shaky at best, and reliance on them is merely a matter of convenience. It’s just easier to pretend that you can fit a project into a given timeline, or a given budget, or some ill-concieved notion that it’s "just like that thing we did last year." And a faith of convenience is an empty faith indeed.

Given that, how to go about providing an estimate of the work to be completed in a field where the work is highly creative, wildly varying, and always "just like that other thing, only different?" It’s useful in these circumstances to look at the milestones in a project, and ask some fundamental questions about them. For this, we need an Imaginary Example.

How to estimate this project? Is the answer:

• A. $2 million and six months.
• B. $100 for a copy of FreeCommerceOutOfTheBox storefront software, plus about 4 weeks to "tweak it" until it looks right.
• C. 3453.75 programmer hours @ $150/hour
• D. Ant farmers?

The key things to consider here are that Foo-EI has planned to spend a lot of money, and that they’re only able to describe the desired end goal in broad terms. They have budget, and they have a vision. So let’s get started!

Whoa there, cowboy.

The temptation to dive right in is almmost irresistable, and that enthusiasm is hard to contain. "We’re agile, and we can get something up and running in 3 or 4 weeks – it’ll be better than wasting months trying to gather requirements – who even does that anymore?" Lately, there’s more and more talk about Getting Real, as if things like strategy, planning, a customer-focus were some how superfluous, or fake.

As software gets easier to write, and easier to deploy and distribute – what happens to quality? Not just in terms of the number of bugs – software can be bug-free, and very low quality – but in terms of the thoughfulness behind software.

What we seem to be facing is a divergence in the way software is developed, and the way interfaces and experiences are designed. (I’ll come back to that topic later.) Software development environments and practices have made huge strides in recent years abstracting the process of coding software from the nitty-gritty of moving bits around inside a computer. This isn’t always a Good Thing (as Joel Spolsky points out), because sometimes it’s important to know the nitty gritty about the insides of the machine when you’re telling it to redraw that spinning logo 30, oh what the hell, let’s say 300, times a second.

Interface design, and even more so interaction design, hasn’t come quite so far. Why is this? Well, I have my theories – it has something to do with the more artistic temperment, to be polite about such things, of your average designer. There is a level of resistance to interaction design patterns which you just don’t find with programmers and developers. If you say to a programmer, "Look, here’s this piece of code that handles password validation – just use it all the time, and don’t worry about ever having to validate a password again, OK?". Do you know what their response would be? &quo;Oh for crying out loud, why didn’t you write this a week ago!"

But try saying this to a typical Interaction Designer or User Experience Architect: "Here’s this pattern for asking a user to log into a website. Use these two fields with the labels placed thusly and the submit button labeled ‘Login’, OK?"

Good freakin’ luck. Once the eyerolling stops, get ready to answer questions like, "What if the user’s already logged in and failed?" and "What if I need to use a different font style for the field labels, or provide the login in 17 different languages?" Bear in mind, the average UXA doesn’t want you to answer these questions. They want to convince you that they’re the only ones who can get to the right answers, and design the login widget in just the right way, for this particular audience.

So what does this have to do with estimating work, anyway? And what the heck does it have to do with testing?

Good estimates take into account what is known – and explicitly define those things which are unknown. In our fictional example, we could easily have gone with an estimate that would keep us quite busy until something was developed and launched, and/or the money ran out. But it’s quite a different thing – and in my opinion, the only honest thing – to say, "Look, this is for ant farmer’s, right? What do you know about ant farmers? Is there even any such thing? Are any of them online? Do they have credit cards?"

These are questions – and until we’ve done some digging, the potential answers are hypotheses. And it’s vital to test those hypotheses before anyone starts banging out any code.

And as for that testing… well, that was a tease. You’ll have to wait until next time.

Collaboration requires… collaborators

User Experience Architects tend to spend a lot of time puttering about doing some pretty mundane things – wireframes and behavioral specifications aren’t terribly glamorous. Architects do a lot of drafting, online or off.

But time doesn’t always allow for endless revisions, and launch dates rarely – if ever – have any relationship to the amount of work which needs to be done. Between developing a strategy for a site – what it should offer and who to target it towards – and designing the information architecture and content plan, there often isn’t much time left for architecture. Wireframes need to get drafted, sitemaps outlined, revisions made, approvals received… and then the whole kit and kaboodle needs to be handed over to the developers. (Whole books have been, or should be, written on how differently UXAs and developers think.) There’s a lot of communication, translation, reviewing, double-checking, and testing, among these groups.

And then there’s the pesky problem of getting the darn thing built.

Now, there are schools of thought which say that the way around this problem is to spend less time planning, architecting, documeting – and more time building. And there’s some sense to that, in certain circumstances. When all you’ve got is a couple of months, a pair of programmers and a mandate to get something – anything – online and working, digging in and throwing some code up against the wall is more likely to work than trying to plan out each. and. every. last. detail.

Bear in mind that this kind of situation works better when those programmers are already on your staff, and you’re choosing whether to pay them to write code or write specs. In my work life, the situation is a bit different – we get hired to build software (be it an application, or a website) that meets a need. And the goal isn’t a certain amount of finished code, or a certain number of hours billed. The end point is a working piece of software that solves a problem. If the problem isn’t solved, we don’t get paid. (OK, we do, but only for the work we’ve done, and the client isn’t happy, and they don’t ask us to do any more work for them. That’s bad.)

Another, similar, approach is to pair a UXA with a developer, and have them work hand in hand to create a rough, black-and-white, wireframe-like prototype. Elements of interaction design would be implemented, rather than documented and annotated. The developer can collaborate with the UXA on feasibility right when the interaction design ideas first take root – instead of weeks or months later after reading a behavioral spec and guessing what they mean.

A lot of UXAs will recoil from this concept. “But I need time to flesh my ideas out on paper, and test them with users.” Sure you do. But you’re not going to get to do that most of the time, and more often than not the developers are just going to get started building the application off an incomplete spec anyway. “We’ll fix it in QA,” they say. (The smarter ones don’t even say it, they just think it.)

Today, a developer came over and said, “I’m working on this prototype, can you help me something.” Yes! A chance to collaborate!

He continued, at his desk: “I’ve got this page, and it’s really long, and so I want to break it up into multiple pages. But the descriptions for each page are too long. Can you think of some shorter labels?”

Bonus points for anyone who knows what’s wrong with this question.

Let’s look at why the page is so long: Aha! He’s put four textarea entry fields for each section. There are twelve sections so, yeah, this page is going to be kinda long.

“You know,” I offered, “this page would be a lot shorter if you just used one textarea, plus a submit button, and then just added whatever text the user types into the textarea to the page body on submit.”

“Oh, sure, but that’s just client-side trickery. We’ll do that when we get to the build. Right now I just want to get the general concept done in code.”

That’s. Just. Client. Side. Trickery. His exact words.

No. It. Isn’t. It’s interaction design, and the point of a prototype is to demonstrate the functionality of the client-side interface. Otherwise I could just writeup a wireframe, and document what it’s supposed to do.

What happened here? Well, what happened is that we took a too-typical working relationship – UXA and developer speaking different languages, working with different expectations – and we bolted on a new and different deliverable. Big whoop. What does this do? Cost more money and take more time. But at least everyone is keeping busy.

Collaboration has two immutable requirements: physical proximity, and a shared working language. Teams which lack the former are reliant on written artifacts to communicate their ideas. Artifacts are always going to be lower fidelity that face-to-face communication (wth the exception of Tufte-ian visuals, which take an exceedingly long time and a great deal of talent to execute well.) Teams which lack the latter – well, they can be sitting on top of each other and still manage not to communicate.

(I’m willing to accept the possibility that physical proximity can be simulated, albeit very rarely and expensively these days.)

Collaboration has to come first, and it has to be fine tuned before you can expect to reap the benefits of a multidisciplinary team.

If all you have is a screwdriver…

So, I was building some personas this morning. And by “building”, I mean “pulling out of my ass” – I had some other UXA’s notes from a total of three user interviews and some more notes from a project manager who’d interviewed a bunch of other project managers at the client’s company… and from this I’m expected to craft a persona or two who supposedly represents the audience of a whiz-bang new intranet.

(For anyone who’s not aware, a persona is an archetype, based on observations or interviews of real people who you expect will use your website or product. By watching them go about their day, or asking them about their goals, you can begin to craft a single, target uber-customer. The theory is, that it’s easier to design and build a website for one person than an audience of thousands or millions. And in practice it works – if you actually get to talk to some of those prospective customers.)

At one point, I got tired of staring at these notes (not because they weren’t interesting, but because there were so few of them), so my attention started to drift. Behind me lay a set of self-assembled bookshelves that had been sitting, unassembled, on the floor for about 6 weeks. So I went to the IT department to borrow a screwdriver (that in itself says something – that our IT department is responsible for holding onto all of our tools.) In about 10 minutes, I had most of it assembled, except for this card board panel that was supposed to be nailed onto the back of the shelving frame.

I hadn’t thought to borrow a hammer, and the nails were pretty small, so I proceeded to nail rear panel to the shelves with the handle of the screwdriver, wielding the screwdriver more like a rock than any kind of real “tool.” Ironic, I suppose, that given the choice between getting the right tool, and using the one I had handy, I choose the latter, less elegant and technically “worse” solution.

Actually, it worked pretty well.

So anyway, I’m writing up this persona, and it’s becoming obvious to me that the single defining aspect of the target audience is that they do not want to use this new intranet. They don’t want it, period.

Now partly, this is because the resources they have now are a scattershot collection of internal websites that GlobalMeganonCorp B’s many internal factions have put up on their own. This is not all that uncommon for large, multi-national corporations. Each department wants to “educate” their internal customer base about the great ideas/products/stuff they have to offer, and everyone does it differently. Sure, there are intranet standards and style guidelines to follow – but everyone uses them differently.

Should we be surprised about this? Nah. If you had a 100 people who were each building a new house in a neighborhood, and you wanted them to do sensible things like build their curbs all to the same height, make sure they used the same diameter pipes for their sewer lines, and didn’t plant trees in the middle of the road, would you:

a. Publish a Building in Your Neighborhood document and hope that they followed it?
b. Make approval of their zoning contingent upon following those guidelines?

I’ll be the first to say that “standards and guidelines” can be the death-knell of any creative endeavor. But guess what? Organizing an intranet isn’t a creative endeavor. Writing content for it is creative, but determining the organization of that content, and the navigation that takes people to it, isn’t.

Style Guides (the kind that Big Organizations and the Technology Consultants love to write) can be really useful when they’re done well, and followed. The problem is, most of the time when I get brought in to “overhaul” a failing intranet, I find that the failure springs either from a poorly written Style Guide, or a really good Style Guide that no one has to follow.

So, for the record, here’s what I think a minimally useful style guide *must* contain:

• Personas

  Who is the intranet for? What do they do with their lives? What are they trying to accomplish?

  If you can convincingly define in unambiguous terms who the intranet is supposed to help, everyone who’s in charge of managing one part or another of that site will design it for themselves – thus ensuring that overall, the intranet is designed for no one.

• Target browser and platform requirements

  Has the IT department determined that everyone in the organization will have 1.5 GHz Dell with a 17-inch monitor set to 1024×768? Say so. Will some people have a MacBook or a 21 inch monitor – good for them. But if the organization has a standard, use it.

  Defining browser and platform standards up front will save everyone involved about 1000 hours of mind-numbing conversation with corporate vice presidents and IT help desk staff.

• Navigational conventions
  Where does the main navigation go? How should navigational labels be written? Is there secondary navigation? How are people supposed to get back to the homepage?

  One navigation scheme, even if it’s poorly defined, will be better than 5 or 6 poorly-designed navigation schemes. When in doubt, slap that navigation down the left hand side – it’s called the 90% solution (because 90% of sites do it that way.)

• A standard color palette for all text, headers, backgrounds and navigation.

  Everyone has different preferences when it comes to color. Which is why we have Casual Fridays. Eye-piercingly cacophonous fuscia and yellow plaid should be reserved for Doris-from-Accounting’s dress, not for some HR department homepage. Give everyone a limited set of colors and strict guidelines for where and when to use them.

That’s it. Want to throw guidelines for “appropriate imagery?” Fine. But not until you’ve nailed those first four things down pat.

Now, supposing you’ve done all this, and you have your Shiny New Style Guide? If you’re like most corporations, you’ll distribute copies to the senior management, and store it in a shared folder where it will go unread, unused, and grow increasingly irrelevant.

If you want to avoid wasting that time, and you actually want to experience the joyful productivity gains spurred by a standards-driven intranet, you need to make sure that someone is in charge of enforcing those standards. Ideally, this person will have:

• Leadership skills
• Budget authority over intranet development
• An absolute fanatical devotion to making the intranet a valuable and customer-centered resource

All three are important. Anyone who’s missing one of the above will be a tyrannical Intranet Overlord, subjecting many worthwhile contributors to torturous “standards reviews” and “user acceptance testing,” while totally missing the point of having a set of standards in the first place. Which is…

…wait for it…

To make easier the lives of people who have to use the intranet to get their jobs done, or to do their jobs better. Because let’s not forget, it’s all about the users.

Intranets often go unused and neglected, or grow increasingly complex and impossible to use, because no one takes the time to think through the Big Picture. Style Guides and Standards are just tools for doing that, and imperfect ones at best. They can be used well, they can be used poorly, and they can be left unused altogether. But if the standard are designed with just a a few and essential details included, even the inelegant use of them can produce a well-designed, user-centered intranet that withstands the test of time.

[placeholder for winning team] Wins!

Amazon just sent me this email:

I am such a huge fan of [placeholder for winning team]. I’ve been rooting for them to go all the way, and seeing [placeholder for winning team] beat [placeholder for losing team]’s sorry ass was the highlight of my life. And as Amber will tell you, I’m always buying stuff with [placeholder for winning team]’s logo on it. I have a [placeholder for winning team] coffee mug, a [placeholder for winning team] sports jacket, and a [placeholder for winning team] license plate for my [placeholder for vehicle type]. [PLACEHOLDER FOR WINNING TEAM] RULES!

OK, seriously. I’m all for getting your act together in advance of a time-sensitive launch date – it’s important to be prepared. But I’ll bet you dollars to donuts that Amazon’s email marketing platform made it a little to easy for someone to accidentally send this off to 5 million or so sports fans.

(As an aside – how do I know that Amazon uses some special software to send email marketing campaigns, and not just Microsoft Outlook? Because I’m assuming they aren’t idiots. Any half-decent mail order company is going to use extensive email tracking techniques, including unique URLS for each recipient to aid in tracking pass-along emails, multiple messages per campaign, etc.)

Which brings us to the topic for the day: Dealing with Ooops.

All software, no matter how well defined, no matter how finely tuned, will eventually be used by someone who is careless, dangerous, ignorant, or all three. Whenever software is placed in a business-sensitive environment (that is, anywhere that its use or misuse will cost someone money), it is incumbent upon the designers of that software to anticipate and deal with mis-use.

There are a few ways most software companies deal with this fact:

1. Write an impossibly dense User Manual, which specifies in stupifying detail exactly how each feature should and shouldn’t be used. For extra points, some custom software houses also document the business procedures (guilty!)
2. Interject an "Are You Sure" confirmation dialog each time the user attempts to do anything permanent.
3. Add magical workflow powder, provding the same obnoxious results as the previous option, but providing the added benefit of annoying at least two people.

The first two options are just laziness; rather than make the software work well, we just tell everyone how it’s supposed to be used correctly. The last option is just bad business, and it borders on extortion – complex workflow apps are usually an excuse to bill more for software development or customization, and anyone whose worked on enough of these projects knows that most workflow rules are outdated by the time they get written down, much less built.

Most software just assumes that if someone goes to the trouble of clicking that button, then they must have meant to delete all of their customers’ orders. After all, the confirmation message was perfectly clear.

The better solution is to make software which lets someone know exactly how many people are going to read that malformed email when they send it a day too early. Really, it’s not as hard as it sounds. There are some simple steps:

• Watch how people use similar software, because that’s how they’re going to use yours. It doesn’t matter how new or groundbreaking your software is. Once someone sits down in front of it and starts using it, they’re going to try and relate it to something they already know.
• Whatch them use yours – you won’t believe what they do with it. Once, I was testing a airline flight tracking website with someone who, though they claimed not to be very computer savvy, figured out how to access the raw data feed through the website and browse that for the flight information they wanted. It was actually awe-inspiring, but it also let us know that a “view all flights” feature would be helpful.
• Don’t ask anyone what they want the software to do. Ask them what they want to do, and watch how they use the software to do it.

Where will the web be in 2-5 years

A collegue emailed me today to ask this question:

“Where do you envision the web going in the next 2-5 years?”

It’s not a new question, but for some reason I felt particulary in the mood to try and address it, and whipped up the following. I don’t pretend to assert that any of these ideas are uniquely my own; perhaps I will come back later and link each topic to an appropriate source.

For now, I’ve split my response into two segments: Where I see the web going as a medium, and where I see it going from a discipline (user experience architecture) perspective.

Where do you envision the web going in the next 2-5 years?

From a medium-perspective

Away.

In 2-5 years, the “web” as a medium for publishing, distributing, interacting and transacting will be nearly extinct – at least as any kind of seperate entity that we can refer to. Saying, “we do business on the web” will sound as antiquated and quaint as saying, “we power our business with e- LEC-tricity!” Frankly, it already does. “Visit our website” will be like saying, “send away for our color brochure!” It will seem ridiculous.

The web will be ubiquitous to the point of non-existence. It will be pervasive and persistent – every can of food, every paper bag, every slip of paper will be tagged and trackable/identifiable. Though my personal hope is that this traceability will be at the discretion of the posessors of these objects, there is certainly no assurance of that fact in the technology itself .

It will be immediately accessible anywhere, anytime, by anyone. (Considering that Philadelphia is perhaps less than 12 months away from cheap city-wide wireless access for $10-$20/month for everyone, this isn’t a terribly prescient prediction.) Wi-Max or some similar technology will make access far-cheaper, at far higher speeds than any mobile highspeed access available anywhere now. With broadband (2Mbps+) access available on any mobile device, the possibilities for content and services change dramatically. Right now (though it isn’t terribly easy), I can download a map with directions from/to my mobile phone from Google Local. Slap in Google Earth, broadband speed, and 30 frame-per-second video on my mobile phone, and I can now receive a guided tour from street level between any two locations on earth.

Speaking of Google, I feel pretty secure in saying it will either be monsterously huge, or extinct. My impression is that they are at the beginning of a Microsoft- or WalMart like 20+ year ascent, but I suppose it’s possible that their increasing encroachment onto so many other business’s turf gets them smacked down or bought up harshly in the next couple of years to come.

From a discipline specific perspective

Harder to use, impossible to avoid.

The last 10 years of web development have not produced much gains in terms of usability – if you look at the “average” usability of all of the web sites out there. The explosion of products and services available online has produced an environment where people face an array of mostly difficult-to-use (and failed) websites, and a small selection of incredibly easy to use (and incredibly successful) ones. Web services will most assuredly make this situation worse – the fact that any developer can marry GoogleMaps with Flicker does not mean that there is a compelling reason to do so, nor that they will do it well.

As with any new technology, the average degree of usability will decrease in direct proportion to the ease with which the technology can be deployed. It’s (yet another) “long tail” scenario – a few web services will dominate the majority of people’s attention not because their services or offerings are unique, but because they are uniquely simply to use.

Gristle and Fat

Usability testing is the gristle and fat of software development. The steak – juicy, sizzling, meaty – comes from the interface design, the programming and development, and the build. But when those things are finished and the project seems done, it really ain’t done.

If you’re into itterative user-centered design, agile development, or any other process that shortens the distance between the those who build software, and those for whom software is built, you’re intimately familiar with this problem: formal requirements documentation processes are generally eschewed, and in their purest form agile development methodologies skip over the “design” portion of the software development process. There is problem – there is solution. It isn’t always a one-to-one relationship, though. Sometimes there are many possible solutions to the same problem. And so, when the development team wants to “get agile”, their process involves picking a solution – whichever one seems right and feasible – and building it. No user testing, no contextual inquiry, no design. Just build the thing, and see if it solves the problem.

How then to determine if the problem is, indeed solved? Emprically, I’ve always felt that the answer is to test the solution with actual end-users. But typically, in agile development, a representative of the customer is asked to review the solution, and approve it. In the development environment in which I work, however, this doesn’t seem to be quite the right answer. Clients hire me to figure out what works and to get it built. They don’t hire me to ask them to decide whether or not the solution fits.

And really, why ask someone to sit in and pretend that they are the end user, when the real deal is so easy to find? (Don’t know where to look? Look at your customers. Look at your employees. If you don’t have any of those, chances are good that the usability of your website is only part of the problem.)

The difficulty I’ve faced is getting usability testing, with real end-users, integrated into an agile development environment. It’s a reasonable problem to have: the timelines are short, the cycles are fast, and in our agency model there aren’t an unlimited number of cycles in which to deal with the usability testing results. But I’ve found a more pertinent and disturbing trend: developers/programmers who don’t want to test because the sense – fear, perhaps – that the results will undo their hard work. Agile development is supposed to be big on “tearing down” past work if it turns out to solve the problem. But when budgets are constrained, people tend to look for the easiest validation they can get that the problem is solved – that the feature is done, built, finished.

But if the testing ain’t done, it ain’t done.

Usability testing validates whether or not the feature built addresses the problem it’s meant to address. Structured as a “fit criteria” (which, in requirements development, defines the criteria by which a piece of software will be judged in determining whether or not it fits the requirements), usability testing provides the best kind of validation: Does it work, in the environment in which it’s intended to work, being used by the people who will have to use it?

Absent usability testing, I think any product delivered to its audience is being delivered poorly, lacking in empathy for the user’s needs and respect for their rights. So much software is so oppressive in it’s lumbering, clumsy implementation. Software that technically works, in that it is possible – however difficult – to achieve what it’s meant to achieve. The question is whether or not it works well.

When it’s done right, everyone is happier: clients are delighted, developers are proud of their work, the UX guys feel good about the process, and the final product actually helps people in their daily lives.

And only then is it done.

404 Not Found – Found!

Things (and examples) to include on a customized 404 error page

First, word about the meaning of the “404 Not Found” error page. If you’re a web developer, know this: the vast majority of people online do not know why it’s called “404 Not Found”, and none of them care. 99% of the people who see this page are unhappy about it, and are convinced that what they’re looking for really is there, and that the site is deliberately hiding it from them.

So let’s turn their frowns upside down, and make the 404 Not Found page a beacon of hope.

First, a few assumptions on which these guidelines are based:

1. The user is at the correct site. If they got the root part of the URL wrong (they meant perhaps to go to www.notsoswoft.com, and not www.notsoswift.com, then they’re outta luck. Unless you have a URL which is similar (to the point of possibly being copywrite infringing) to another popular URL, you’re under no obligation to redirect people elsewhere.
2. You have more than one page on your site.
3. You have been careful about redirecting inbound links to pages you no longer want or have on your site.
4. You care whether or not people coming to your site find what they’re looking for.

OK, with those items in mind, here are a few guidelines which I’ve collected from experience, and from other sources I think are either credible, or at least funny:

Tip 1: Treat a poorly-typed URL like a mis-typed search term, and respond accordingly. First, repeat for the user what they appeared to have been looking for.

Tip 2: While you can include a message indicating that the user might want to try retyping the link, the better alternative is to try suggesting alternative links that have very similar spelling or, more vitally, meaning. Some examples:

• Typing "http://www.microsoft.com/wurd"

into your location bar will prompt Microsoft.com into suggesting that you may be better off looking for:

• Microsoft Word Home Page
• Teachers: See How Word Can Help Improve the Writing Process

Tip 3: A list of the no more than 10 of the most popular pages on the site. It’s best if this is dynamically driven based on actual usage, and includes deep links to hard-to-find pages. Extra-credit goes to Amazon, which makes this list user-profile driven.

Tip 4: The ability (and encouragement) to use a search function, the site has a good search interface/backend. Most users search once, and then leave – so if you can’t guarantee good search results, then often it’s better not to offer a search function at all.

Tip 5: Include a link that allows people to contact you directly, if you feel confident that you can respond within 24 hours to any inquiry, no matter how inane. This tip is really only recommended for sites where customer acquisition is a key goal, individual customers have high value (for example, you offer a service or product which is very expensive), and customer support is available 24 hours a day.

The better method here is to offer live help of one sort or another, so that you can respond to inquiries immediately.

Tip 6: A link to the home page (though generally that’s captured if you’re using the site’s standard page template, which includes logo, navigation, etc.) can be helpful for vistors who arrive through old broken links or through URLs that were misspelled in the first instance. Note that it is not acceptable to automatically reroute visitors to your homepage, the way Lands End does.

Tip 7: I also like to add something humorous that shows people that there is a real voice behind the site. Something to break up the frustration that people feel when they can’t find what they’re looking for.

While I haven’t implemented all of these features for notsoswift’s 404 error page, I have implemented some of them. Feel free to take a look (and while doing so, note that I have made use of some rather basic Apache error handlers to customize the error code for the user.):

Hop on over to a notsoswift.com page that clearly doesn’t exist.

A Glimpse

Once or twice a year, I have the pleasure of reading something which seems to so effortlessly describe a vision of the near future that is neither fantastical nor mundane, but intuitively right. I happened across two such items in the past few days, though only taken together do they seem to draw back the curtain on some forbidden room that is not quite ready to be revealed. (It reminds me of a scene in Fun with a Stranger, from a collection of Richard Yates’ stories that I’m reading, where a class of third grade children are waiting out in the hallway while their teacher prepares the classroom for a party, the day before Chirstmas break is to begin. They are filled with “a special tension,” and when one of them cathces a peak inside, the excitement spreads.)

The first of these was a site by Vodafone passed along to me by a designer collegue of mine. And the second was an essay by Adam Greenfield which I happened upon by chance. It appears this month on boxes and arrows, which I frequent occassionally (a great source for templates for developing personas, among other things.)

Vodafone clearly has a stake in ubiquitous computing (I’m somewhat loath to accept the abbreviated “ubicomp” – it sounds too much like something out of a William Gibson novel.) Their vision of the future presents some very compelling aspects – most notably the use of materials and devices which have been developed already and which may only be a year or two away from production. There future is worn on your wrist, and acts as a sort of central interaction hub through which you might might control various other devices in the vicinity. There are other interaction points as well – a dynamic, flexible, paper-like electronic display which interrupts your reading of the day’s news with an incoming video mail message; an exercise bike that tracks your performance and allows you to anonymously “compete” with other people of similar athletic abilities around the world; a wall-sized, painted-on display that provides you with a panoramic display of a football game or a mountain stream, whichever suits your mood.

But I can think of at least two reasons why Vodafone’s future world will be a collossal failure, if it materializes at all. The first is the lack of a business model sufficiently in keeping with the advanced technological vision presented. While ubiquitous devices seamlessly integrate with one another, they do so as channels through which “digital services” are “delivered” to you wherever you are, provided you select from one of the three available options. I’ll be gracious enough to go along with the fantasy and not refer to Vodafone as a telephone company, even though their thinking is clearly reflective of that ancient breed. More charitably they might be called a communications company, but still they seem to think in terms of “mobile infotainment services”, personalized content, and per-usage charges. Their vision glosses over the interface into these services when it talks about them at all – the nuts and bolts which bring together disparate data from one point on the network to another. Vodafone, like its breatheren, see itself as the delivery mechanism – i.e., the gatekeeper – and assumes that with control of the pipe through which the data must travel comes control of the delivery mechanism. The Baby Bells thought this too, and could see only dollar signs in providing high speed internet access through their copper lines. Now VOIP is entering the mainstream, and rapidly canabilizing the pay-per-use business model which supports the maintenance of those thin copper wires.

But more importantly, Vodafone and companies like it will fail because they are ignoring the importance of a compassionate interface, and more importantly the behavioral model which governs its use. And here is where the second piece comes in: All watched over by machines of loving grace. Providing first the context in which unquitous computing might wreak havoc, and then presenting design guidelines through which it might be prevented from doing so, Adam Greenfield lays out five rules of design which draw unappologetically from Issac Asimov’s three rules of robotics, and which offer at least the hope of a future where machines everywhere are assistive and supportive, and not the “neverending hell of a voicemail menu the follows you wherever you go.”

It is only in the context of these two opposing views: one of what will be – come hell or high water – and one of what could be, that I realized that the companies which “envision the future” are also the ones who seem so ill-equipped to deliver it with any sanity. One gets the feeling that Vodafone’s Future will not so much be delivered as inflicted. Nit-picking though it may be, their site doesn’t permit such usability niceties as deep-linking and user control. While they are far from universally-accepted, user interaction guidelines for the web are astonishingly well defined compared to the guidelines for ubiquitous computing. What possible hope is there that Vodafone, no spring chicken to the Internet, will do any better adhering to principles of compassionate design when it comes to ubiquitous interfaces than they are on the web?

Finally, there is a difference between user-centered design, and user-focused design. Information architects love to argue about semantics, but the real difference I’m trying to feel my way through is the one that juxtaposes a future where the user remains in control by default, and the one in which the user is but a target for an increasingly ubiquitous array of “on-demand” services and features. On whose demand are they available? Greenfield seems to hope, or plead, that in the absence of an explicit preference, the default state should be to “do no harm, let no harm come.”

That one edict can provide a startling degree of clarity when it comes to making design decisions.