Inspired, in part, by Jared Spool’s recent article regarding  the impact of design changes at Amazon.com and the related talk he gave at the IA Summit, I thought I’d post a few Amazon redesign ideas that have been percolating in my head of late. Of course, these ideas are presented without access to Amazon’s vast research data or internal business knowledge. Who knows, with that knowledge in hand, I may have suggested very different ideas.

A Pixel Saved is a Penny Million Dollars Earned

There are few sites on the web where even an atomic-level change in the user interface can potentially have greater impact on overall product sales than at Amazon.com. For this reason, every character, every pixel needs to be scrutinized and justified in terms of supporting the overall goals of the business. In line with that, these are some ideas for eliminating possibly detrimental pixels in the all-important Add-to-cart area.

Here is a Before/After of the Shopping Cart area on an Amazon detail page:

There are three key changes I made here, which allowed for eliminating quite a few pixels:

• Removed the quantity option: The ability to select a quantity prior to adding an item to one’s cart seems to not only be an edge case, but also something which, if the option were removed, would be unlikely to cause users to not add the item to their cart. After all, once having added it, they can then update the quantity option to their heart’s content. Removing it, in other words, would mean less page noise at virtually no cost to usability.
• Removed an unnecessary technology reference: Below the Add to Shopping Cart button, anonymous users see a link and some copy encouraging them to sign in to be able to make use of 1-Click Ordering.  The problem here is two-fold. First, by linking on the word  “Sign in” this is what is implied as the main goal of the message and also what will draw the eye.  Signing in is of course not the main message here.  Second, even including the detail that accessing the 1-Click-Ordering feature will require signing in really only becomes a distraction, since it really isn’t relevant until a customer actually decides that they want to activate the feature.  The primary message is to encourage users to turn on 1-Click-Ordering, and that seems to therefore be most effectively communicated by replacing the whole ball of wax with a single call to action.
• Combined multiple modules into one and added some hierarchy: Because Amazon provides so many great purchasing options, this tends to lead to a whole gaggle of buttons collecting in this area, some of which are inside a module and some of which are not, making for a slightly harried viewing experience.  Here, I cleaned up the whole thing by placing everything in one module, and then used the dotted horizontal rule as a much more low-key division between groupings.  I also added a bit more hierarchy, such as making the text for the somewhat secondary “Share with Friends” feature smaller.

Much of what is manifested in these changes is the critical value of succinct writing skills. Good user interface design is very much like good writing, i.e. the ability to say what you have to say with the fewest possible words and then saying no more. (As opposed to this completely extraneous sentence.)

Make marketing action-driven

Here is an example of a marketing blurb for the new Kindle 2.

A key issue with this message is that it requires the user to read through a bunch of copy to understand what really is a simple message (see below.)  Already there, you’re going to lose quite a few users, who, after encountering that amount of copy (a lot in this particular context), will be off scanning some other part of the page.

Then, and this is even worse, for those users who take the time to read the message and in fact would now like to take the action that the message is promoting, it is in fact not at all clear how they should do that.  Should I click on the link with the name of book? But that’s the page I’m already on.  Hmmm…

Finally, the message suffers from providing information at a level of detail beyond what the user really needs to know. For all intents and purposes, “in under a minute” is the same as now, which of course is a far more compact and powerful message.  That’s what customers care about. That’s the essential selling point.

Therefore, my recommendation is to replace this text-heavy marketing message with one that strips it down to its absolute essence and doubles as the action that the message is selling.

Here, we are not only communicating that the Kindle allows for reading a book immediately (which is a major selling point that I actually was not aware of until I started reading the Kindle marketing materials more closely), but we are also presenting a clear path for initiating that process.

Less page, more opportunity

Currently, the Amazon page width is set to 100% max-width, meaning that the maximum width of the page will be whatever the width is of the browser window.  Now, for users with smaller monitors, this issue will go unnoticed, but for the growing number of us with wide screen monitors, an Amazon page might look something like this:

With a page this wide, the overall page design quickly starts to break down: the long lines of text become more difficult to read, the search input form becomes so ridiculously long it ceases to look like a text field, and the Add to Cart area loses its association with the content it is referencing and looks more like a third column.

Allowing the page to continue expanding to this width is, in my opinion, not only a degradation of the overall user experience, but also an opportunity lost. In other words, constraining the page width to one that is optimal to the content it contains creates a whole new area available for things like marketing. This is something that others, like the good folks at Pandora, already have figured out.  So, my recommendation here would be to constrain the page width to one optimal for reading, which, for the current design seems to be a 1024 pixel display, and then use the new-found real estate for marketing purposes.  Something like this:

Better legibility, usablity, and new-found marketing opportunities all-in-one.

To be clear, I think Amazon is one of the best designed e-commerce sites on the web, and I’m sure that an incredible amount of thought and effort went into the designs I am critiquing.  But maybe it is that very fact, the knowledge that these pages were designed by some of the most skilled people in the industry, which makes it all the more enticing to find ways to improve upon their ideas.

Here is an interesting little message I was greeted by while doing my usual multi-tab sweep of news/todo/email/twitter/etc this morning.

What I think is so interesting about this seemingly innocuous little message is how much it tells you about those who designed it (or not, as it were.)  Here are a couple nuggets one might glean:

The 15 minute timeout was likely set with no consideration for UX or the business context

This message appeared because my session at this site had been automatically ended, since I had not clicked on anything during the time allowed for inactivity during a session. For those not familiar with this, there are two reasons why one would want to time out a session:

• Conserving server resources: every additional user session takes up some resources on the server, so you’d want to conserve by ending sessions where there is no activity.  However, this has become far less of an issue after storage has become cheaper and processors faster.  And even if this were a factor here, timing out after 15 minutes would almost certainly not be necessary.  More likely, it could be set at 1 hour or the like.
• Security: This is the far more common reason to limit a user session.  If, say, this screen shot were from a banking site or the like, well, I wouldn’t be posting this, because a 15 minute timeout would make sense.  After all, you don’t want to risk someone being able to access your checking account while you had to leave your computer for a couple minutes (maybe having forgotten that the account page was open in a different tab.) But this is no banking site.   There is very little, if any, damage that someone could cause if gaining temporary access to my account here.

In other words, for this business context, a 15 minute timeout makes no sense.  I’m guessing this was set by a developer, possibly without even any discussion with the UX designer, maybe because that person wasn’t even aware of this, on one hand very technical issue, but on the other hand one that can significantly impact user experience. And it is incredibly unlikely that this limitation is due to a need to conserve resources.  A 1 hour timeout would likely  make more sense.

The accusatory tone (“you idled”) reflects inexperience writing for the web

When writing for the web, particularly when writing interface labels and dialog copy, surgical level word choice is critical.  What is so unfortunate is that a lot of interface copy seems to default to accusatory and unnecessarily dramatic (“Warning!”) language.  An experienced author would have been sure to both strike a more empathetical tone, as well as explain why the session had to be ended.  Maybe something like:

You haven’t clicked on anything in the last 30 minutes. To protect the privacy of your personal content, we’ve automatically signed you out.  We apologize for the inconvenience.

Please sign in again

It’s interesting how much a tiny little detail can tell you about the person who designed it.

As someone who has done a lot of interviewing over the years, and as a participant in the IA Institute Mentoring Program, I’ve looked at countless resumes and work samples.  I am currently reviewing another such set of documents, and was about to start writing them an email with my comments, but realized that I’d basically be providing very similar feedback that I’ve provided to many other mentees. (I just can’t get over that word – sounds a bit strange, no?)

So, I thought I’d instead just post my thoughts here so that others may also benefit.  Here, then, is the most common feedback I provide when reviewing someone’s resume and work samples:

The user experience of your documents can be a make-or-break factor

If I were looking at the resume of someone I’d be considering for, say, a carpentry or welding job, I’d be less concerned about a less than stellar resume design.  (No offense to carpenters or welders, btw.)  But when I am considering someone for a position whose very role will be about creating the most seamless connection between user and system, the design and presentation of these documents at the meta-level becomes a key focus.  Why?  Because the care that they took in, say, naming of their resume file is a direct reflection of the attention to detail they will be providing to the design of user experiences in general.

These are some of the most common mistakes I come across and what I would recommend doing instead:

Mistake: Submitting files, especially large files, as attachments

Even in the world of Gmail with limitless  storage, lots of people are still using archaic systems such as Lotus Notes, with limited storage.  By sending a huge file (i.e. maybe containing a prototype), you are essentially clogging their inbox as well as the inbox of the people they forward it to.

Additionally, once you’ve sent a file, you are married to that version of the file. In other words, if you notice a problem with the file (i.e. a typo) after having sent it, there is no way you can fix it.

Recommendation: Send links, not attachments

This is not only a much more elegant way of submitting content, it also allows you to make fixes after the fact.  Just as importantly, it ensures that everyone you send it to is looking at the same version.

To be clear, I’m not talking just about resumes.  Everything you submit should be done with a link, preferably a compressed link (I recommend using the is.gd link compressor), to ensure that the recipients client doesn’t clip the URL.

This, of course, means that you need to have a web space where you can post your files.  In my opinion, a personal website for anyone working in UX is an absolute must, so if this is an issue for you, you should be setting up your own web space forthwith.

Additionally, you should be applying the same UX best practices to this URL as you would in the normal course of your work.  Here is the nomenclature I recommend for resumes:

http://www.yourdomain.com/resume/first_last_resume.pdf

Having “resume” twice may look redundant,  but it’s critical that the name of the resume file itself is user-friendly, which leads me to the next mistake I often come across.

Mistake: Generic, Meaningless, Confusing file names

I don’t know how many times I’ve recieved resume files titled “resume.pdf”  That may seem self-explanatory to the person sending the resume, since they likely only have one of them. But the person on the receiving end usually has piles of these, which renders such a file name virtually meaningless and forces me to rename it.  Not good.

Recommendation: Make your file name portable and autonomous

You should assume that your file may move through many different hands and across many different email applications.  For that reason, you should first name your file conservatively from a portability perspective, meaning that you should always replace spaces with underscores (remember, when sending your file as a link, it will be part of the web address.)

More importantly, your file name needs to autonomous.  In other words, it should be named such that your employer, or some 3rd party that has never met you, should be able to recognize what it is when it’s sitting on their desktop or whatever.  So, if I were submitting a collection of work samples in a PDF file, the nomenclature would be something like this:

anders_ramsay_work_samples.pdf

Mistake: Assuming that people actually will be reading your resume

When you’re working on your resume, it can be easy to forget that, while you’re paying attention to every syllable in the document, which you should definitely keep doing, most people who are looking at your document are likely very busy and likely looking at lots and lots of documents just like yours.

Recommendation: Design for scannability

When Steve Krug talks about users scanning rather than reading web pages, the same holds true for resumes.  When I read resumes, I usually only give it maybe 30 seconds of my time during the first round, scanning for phrases that pop out, looking not only at the specific content but also at how content is organized. In line with that, these are some of my recommendations when it comes to designing (not just writing) resumes that pop.

• Put a summary at the top: This is particularly critical if you’ve got a multi-page resume.  What would you tell your reader if you instead met them in an elevator and had less than a minute to summarize your skills?  This is what needs to go right at the top.
• Make headings meaningful and easy to scan: Try just reading the headings in your resume.  Do they include your job title?  Do they crisply communicate what you’ve been up to for the last several years?
• Keep job description summaries short: Assume that the reader will only look at the first two bullets, maybe only the first bullet.  Never have more than four.
• Make sure your resume breathes: Don’t use type that is too small and don’t be afraid to make good use of white space.

Finally: Think about the story of the documents you are submitting

I don’t know how many times I’ve received a folder containing a bunch of files, such as wireframes or specification samples or whatever, without any kind of instructions or supporting descriptions of what I am looking at and how I should be looking at them. Imagine how an end user would react to being presented with web content in this way.  At the very least, you should always include a document that introduces the artifacts you are submitting.  My recommendation, however, is to go one step further and to actually produce a single document in which you collect the various artifacts you are presenting, and include an overall introduction to the documents (perhaps describing when and how they were created), and then introduce each artifact, preferably with callouts highlighting key elements of interest in the artifact.

There are of course many more recommendations I could make about the UX of resumes and work samples, but hopefully these will be useful to someone who currently is in the process of applying for a job.

Let’s imagine for a moment that you’re some seniorish UX design person and I’m your client and I ask you to design for me a truly durable and useful todo list.

I can imagine a variety of reactions to this request. One might be “Why in the world do you need me to design a todo list when there are like a gazillion todo lists already out there?” Another might be a shrugging of the shoulders, thinking I’m giving you a chance to make some easy money to design yet another todo list. But if you’ve really been around the design block a few times, you’d know better than to assume that a seemingly simple request coming from a client really is that simple. (In my experience, that is rarely, if ever, the case.)

So, you dutifully inquire further as to what my specific needs are relating to a todo list, i.e. when and where I’d be using it, what type of todo items I’d be entering, how I’m currently managing my todo items and so forth. Here is one of my responses:

I’ve used all kinds of todo list software, from the new Gmail Tasks, to 37 Signal’s Tada Lists, to just typing stuff into notepad or Google docs. Many of these pieces of software are very simple and elegant and user-friendly, but, even so, what always happens is that I use it for a while, eagerly typing in everything I need to do, but then I stop using it after maybe a week or two, sometimes less, usually because it’s just too much of a hassle to have to type stuff into these lists. So I end up with todo items scattered all over the place.

Whoa, wait a second here. Maybe this todo list thing isn’t that simple after all. Taking an Alan Cooperish what-if-software-was-magical approach, you ask me what my ideal dream todo list might look like, setting aside any technical or logistical constraints.

For me, the issue is primarily with the hassle of having to enter items, of having to get in front of a keyboard and fire up some application when I think of something important, especially when I simply can’t or don’t have the time, maybe I’m riding my bike, in the shower, in the midst of a conversation with someone, don’t have internet access, whatever. So I end up not entering it, which of course negates the whole point of a todo list. So, in terms of my dream todo list, and this will sound a bit weird, I think it would have to be one which it basically reads my mind or something and when I think of something I need to do, it would add it to my todo list in the cloud, as in some kind of universally accessible list of stuff to do.

The other big issue is having to deal with categorizing and prioritizing todo items. While I’d like for them to be organized nicely, I don’t want to deal with having to come up with categories not to speak of having to do the categorizing. So it would need to be able to somehow figure out how to group my todo items in a sensible way, such as work-related and personal todo items. And as far as priorities go, I’d obviously want higher priority items to be more prominent, but the problem is that the priority of a todo list item changes for me depending on context and other factors. For example, if I am at the office, even though I absolutely have to remember to pick up a bottle of wine on my way to the dinner party this evening, I don’t want that todo item cluttering my list of office todo items. But if I maybe head out for lunch, then I’d want to see it, since my priorities and my context then has changed. Yeah, that would pretty much be the ideal dream todo list.

Ok, so on one hand this is a dream todo list app, but let’s look at what this imaginary software tells us about current todo lists and design in general.

The more contexts your design needs to support, the more complex it will be to design
A todo list is reflective of how the software we design is increasingly intertwined with people’s lives. As such, a todo list that a real person really can use in their day-to-day activity needs to work in all kinds of contexts. Compare this to a todo list that strictly is for work-related items: in that case, I can maybe assume that the user will always be in front of computer and as such as traditional todo list might work. But even that falls apart, since I may also be on the road, in a meeting with a client at a coffee shop, in front of a whiteboard.

Categorization is a Catch-22 Conundrum
On the one hand, users like for stuff to be organized in a way that makes sense to them. At the same time, they are unlikely to want to have to deal with coming up with categories or with the hassle of categorizing. While creating some generic todo list categories (e.g. work, personal, buy, etc.) is probably doable, user would still have to actually place stuff in those categories, which adds yet another obstacle, another micro-activity that will make the act of entering a todo list item less palatable.

Priorities are contextual
There are lots of things we think of as important, but only some of things are important in a given context. This means that we can either have multiple todo lists for different contexts, which means a lot of busy work, which means we are likely to stop using the todo list. Alternately, we could use category-specific indicators, such as high priority work, or high priority personal, but again, we are then back to the problem of too much hassle to deal with when enter a todo list item.

Sometimes there really is no great solution within the digital domain
With today’s mainstream technology, it is not possible to design a durable and truly useful todo list. Please prove me wrong on this.

Instead, this is the todo list solution that I always find myself returning to:

Yup, the back of an old envelope. Why is this tattered looking thing better than any of the todo list software out there?

It’s highly portable
For the very reason that it’s just an old used envelope, I can crumple it up and stick it in my pocket. If I spill coffee on it or it gets a little torn or whatever, who cares?

It’s always immediately accessible
No booting up an iphone app or, yikes, a laptop, just to enter a lousy todo item. No battery life or connectivity issues to think about.

It constrains me to a reasonable amount of todo items
One of the biggest problems with most current todo lists is that they, in a knee-jerk nod to the idea that infinite scalability is a good thing, don’t impose a limit on how many todo items I have on my plate at any one time. But a list of hundreds of todo items, I think, is pretty useless, as I am only going to be able to do a few of the items within the near term. So, the size of the envelope constrains me to a reasonable amount that usually matches what I can complete in a day.

It allows for ad-hoc prioritization and categorization
Since I can write anywhere on the envelope, I can add little stars or underlines or write in all caps or whatever to show that something is important.

But, of course, using the back of an envelope for a todo list has all kinds of drawbacks, which leads to another UX lesson:

Design is not about finding the ideal solution; it’s about finding the ideal compromise
Obviously, using the back of an envelope or a piece of paper has all kinds of drawbacks, from that you have to manually transfer todo items that weren’t completed to a new piece of paper, or that you could easily misplace it, or that all your scribblings could quickly turn into a big jumbled mess. But weighing all those drawbacks against the strengths of the solution, I still kep find myself returning to this method after temporarily trying some new software-based todo list.

Is it just me or are others having similar experiences, finding digital todo lists just not workable in the long term?

When you first encounter something that has been designed just right – the iPhone, Gmail, the Swedish cheese knife and now Google Chrome, you always find yourself wondering what you were thinking using all those other crappy products (I can’t imagine, for example, going back to a regular cell phone, or using an old-skool email client.) And now, after having only played around with Google’s new and long-awaited browser, I knew immediately that it was a keeper. And it’s not just because of all the widely discussed features like separate processes for each tab, and an overall much more modern system architecture. Maybe what I love most is what is not there, which is very much in line with that greatest of design maxims:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint Exupéry

Chrome certainly makes that idea manifest. And sure, maybe somethings were taken away that I’d want, like the ability to have a color theme different from the a-bit-too-dark Bloogle blue, or access to all my favorite FireFox add-ons. Oh, and somewhat ironically, I do miss my Google toolbar, particularly the autofill feature. But I expect that will all come in time.

On the lighter side, I just love how Microsoft came out with a statement today saying they weren’t worried about Chrome competing with IE8 – the only thing preventing that from happening is the default install base on Windows PCs – if IE weren’t installed by default on so many machines, their market share would fade away so fast – IE feels like an old jalopy compared to FireFox, and I hate to say this, but FireFox, while still an amazing browser, just feels slow and tired compared to Chrome (though maybe I should give it some time and open up a gazillion tabs and get umpteen applications running and see if Chrome’s garbage collection really is as great as they sat it is) – and one reason it hurts to say that is because so much of what makes Chrome great is thanks to the sweat and hard work and dedication of the people over at Mozilla – Google even made of point saying so in their super cool comic strip about the new browser. I love how they call it a ‘book’ – hey Googlers, did you know that there also are these books out there with, like, text and stuff :)

I’m currently using Firefox 3 RC2 FireFox 3 and absolutely loving it – I love the new tags feature, the overall faster browsing experience, everything…

Well, almost. One thing that I find quite strange is the location of the control for jumping back several pages:

I remember the first time I needed to go back several pages and saw this and sort of looked at it like “hmm, seems like you can jump ahead several pages, but how do I jump back several pages?” But after clicking on the little control, it turns out that to go back several pages at once, you click on the control next to the forward link:

Unintuitive indeed. Would it not make sense to have this control be next to the back button, maybe something like this?

Here, the location of the control maps to our mental model of where we want to go, as in backwards.

Over the weekend, I think, Google updated their favicon (or shortcut icon) …

First off, I was pretty confused when I saw this, since seeing that g out of context doesn’t remind me at all of the Google brand. The old favicon was much better:

While that lowercase g could be pretty much anything, it’s hard to confuse this with anything other than Google. But worse, and this was the case with their previous favicons as well, they have the same favicon for several different services, such as search, maps, and news.  So why is this a big deal (or a small-big deal)?  Well, I use favicons as buttons in my bookmarks toolbar…

This is a great way to conserve space.  The only requirement is that the people who are designing the website are thinking about how favicons might be used.  (Ok, in addition to the requirement of having a favicon in the first place.) Maybe what I’m doing is a bit unusual – basically turning favicons into buttons by removing the text description, but it seems to make sense, no?  So, if you happen to be someone who designs favicons or has any say about it, if you’re working on a suite of services, don’t use the same favicon for all of them.  Even if users aren’t being nerdy like me, it still makes it easier to target the right app if it has distinct visual mark or brand.

Just got an email from Wimbledon Live containing the following

Dear Anders,

As a previous Wimbledon LIVE customer we are contacting you about your preferences. If you would like to be notified about the 2008 Wimbledon LIVE service, please take the following steps to update your preferences:

1) Go to www.wimbledon.org/LIVE.
2) Click “My Account/Login” on the left navigation bar.
3) Login with your email address and password.
4) Click “Change preferences”.
5) Check the box to sign up for the “MediaZone mailing list”.
6) Click “Save changes”.

We thank you for your continued interest in Wimbledon LIVE.

Sincerely,
MediaZone

I’m not sure whether to laugh or cry. I feel so sorry for the people who run the Wimbledon Live site, who are stuck with this horribly inept solution to something that should be very simple, such as

As a previous Wimbledon LIVE customer we are contacting you about your preferences. Please click on the link below if you would like to be notified about the 2008 Wimbledon LIVE service.

[here, there would be a link the user can click on which takes them to a web page where they can click on a button to confirm their preference - in other words, take the user directly to the last step above]

So what is the cost of those 5 extra unnecessary steps? Probably that a lot of people, such as myself, couldn’t be bothered to deal with them, which in turn means that less people will be notified about the 2008 service, which in turn means lost business.

This is just such a great example of designing without thinking holistically. In other words, just looking at the design of the individual web page or whatever as if it were its own little island, when the reality is that its part of a larger flow, a larger context.

On the brighter side, really looking forward to Wimbledon as always – though I don’t think he’ll do it, would be incredible if Federer pulled of six in a row.

I’ve done a lot of usability testing in my day, but today I participated in one that was different from anything I’ve done before. Rather than testing the usability of a website, we were testing the usability of a book. This, by the way, was a test conducted by Liz Danzico, the editor of Rosenfeld Media, and it all came about because of her post about the test on her blog.

What was most interesting about participating in this was that I found myself looking at something—a book—that I’ve used for pretty much long as I’ve been around (after all, before I even knew what the word ‘Book’ meant or what a book was, my mother was probably, surely, reading bedtime stories to me – Mom? You are of course reading my blog, yes? Could you maybe post a comment to confirm?), and yet here I was looking at it as if I’d never seen it before, as if this were a completely new website somebody placed before me on a monitor and asked ‘so, what do you think?’ I handled the ‘prototype book’ that Liz carefully presented to me, leafing through it a bit, looking at the table of contents, the index, the back cover.

In a nutshell, I found myself feeling very strongly that contemporary book designers can learn a thing or two from information architects, the people who organize information on websites. Seems weird doesn’t it? After all, book designers have been designing books for hundreds and hundreds of years, so you’d think they’ve pretty much got it all down pat. Not so, at least in my opinion. Similarly to how the web is transforming the music industry, it appears that books are equally susceptible to the impact of the web. No, no, I’m not talking about the paperless office or some futuristic hoopla about how the web spells the end of the book. I’m talking about how the way that we use the web, the way that we move from one page to another, the way that we have come to expect information to be organized on a web page, or in a website as whole, consciously or otherwise, is affecting how we think about and read books.

As a case in point, I mentioned to Liz that I would expect something akin to a ‘Getting Started’ section in the book, and the reason I wanted that, of course, is because it’s something I’ve come to expect in online help documentation (as well as in product-specific websites.) This, of course, would be for how-to books, and not for a more theoretical text.

Additionally, I’d expect a very tight integration between the book (keeping in mind that this is a book for computer professionals) and a companion website for the book. I would assume that I could go to the companion site and find additional content, similarly to what one might find on a DVD in addition to the movie, and of course things like errata (which already is quite common.)

Taking this a bit further, I would like to see a discussion forum, where the book essentially is the hub of a community that can congregate online to share their thoughts. And what would really bring the book-web connection home would be the presence of a wiki, where maybe the author sort of continues writing their book, possibly in response to comments made on the discussion board, or maybe uses the wiki as a live beta of a forthcoming future edition of the book. I guess the overall idea is that the web would function as an organic, living extension of the original work.

At a very fundamental level, user experience is about communication—between the user and the system, between content and objective. And with new sites constantly popping out of the woodwork, user experience is more and more becoming a one-shot deal. You either communicate and deliver what the user was looking for the first time around or they’re off to the next site (which they almost inevitably came across via Google or maybe Yahoo!, which means they were taken directly to the page related to this search and not to the site’s homepage, which maybe provides a nice overview of the site—if your design doesn’t assume that users will jump directly to lower level pages without ever seeing your homepage, you are not designing for The Web That Google Made…) You’ve probably got something like 30 seconds to make your content/objective connection. That means your message needs to be crystal clear to the lowest common denominator user. Of course, it won’t be for every user, but the hope is that it will be for a sufficiently high percentage of users. Now, let’s imagine that you had to get your message through to all your users every time, and that not getting that message through could mean life or death. Ok, I plead guilty to suddenly switching gears to talking about a mission-critical system, but I’ve always found that UX design for the web has so much that it can learn from systems in which there is no room for mistakes. For all the praise given to people like Don Norman and Jakob Nielsen, it’s easy to forget that just because the term ‘usability’ only has been around for, what, a couple decades, user-friendly design has been around for about as long as there has been a need for stuff to be user-friendly, which brings us to emperor and part-time usability pioneer Napoleon Bonaparte.

The emperor needed to get his war strategy missives out to his troops not only fast but reliably, meaning that he needed to ensure that the message he sent—as he understood it—was also the message that was received. Not an easy task back in the day before instant messaging and email, when delivering a message might take days or weeks. If the message was not fully understood by it’s recipient, well, there just wouldn’t be any time to send back a follow-up question. You’ve got your orders and you better know what they mean. So Napoleon came up with a nothing-less-than-brilliant solution to his mission-critical message problem. Knowing the officers receiving his missives might be farm boys brought up quickly through the ranks and of, well, let’s say, questionable intellect (at least when it comes to war strategy.) Regardless, he simply had no idea who the recipient of his message might be (not much unlike sending messages through the Web) and therefore had to assume the worst. So, what better solution than do a bit of message prototyping before sending out it out, yes? Armed with his usability instincts, Napoleon went out among his troops and grabbed the most dense farm boy soldier he could find, promoted him to Lieutenant on the spot and made him part of his personal guard. Then, whenever he needed to send a message to his troops, the emperor would have it written up, presented to his Lieutenant, whom he would then ask to explain the message back to him in his own words. If Lieutenant Knucklehead could understand and explain it back to him, he figured that even the most dense of his officers out in the field would be able to get it. Last time I checked (except for that whole Russian winter thing), Napoleon’s usability testing model worked out pretty well. Aside from the obviously elitist aspects of this approach, there is still much to be learned from the Napoleon School of Usability Testing. His was the ultra-efficient shotgun model of usability testing, in which you test and iterate with one edge case user. It’s simple and it’s fast. On a certain level, it’s not so much about ensuring the user-friendliness of your content, but rather just getting a perspective that is as diametrically opposed to your own as possible, to react to something that may make complete sense to you. And that is really at the core of what we’re doing when presenting concepts to users—using them as a vehicle for stepping outside our own thinking, and into the messily subjective realm of usability testing, helping us to see flaws in our design that we maybe simply were not capable of seeing.