Continuing what I did in the “Interface Surgery” sections in the book, I’ve decided to start a series of blog posts called “Design Stories”, about the thought process that goes into the design of interactions. I’ll post these whenever I work on something I think would make a good case study.

First up: the 5-star rating interface. This design pattern can be seen everywhere from Amazon to Yahoo! to Yelp, but the individual implementations are often done very differently.

For example, rating widgets are often split into two parts, shown in two different areas of a page. One part is the display version of the 5 stars, the one that tells users the current rating. The other part is the interactive piece, where users choose how they want to rate something, such as a book, CD, or the helpfulness of an article.

The interactive piece can be done very differently from one site to another. Some use text as the rollover for each star, to make it clear what each star means as a rating. Some require that you click a star and hit Save. Some only ask that you click a star. When all you do is click a star, however, there is no feedback, except that the star is now yellow (or some color other than the non-selected white).

So these are the issues that I had to consider as I designed the interaction.

Also in this case, I needed to combine the two elements into one. I needed a way to show the current rating and enable users to select a rating of their own.

To do this, I split the display piece and the interactive piece into two states. I started with a simple display of the 5 stars, coupled with a link to begin the rating interaction.

I thought that when the user clicked the link, the set of stars should go into an editable state. This is indicated by a change in color from yellow to white. Of course, the user also needs a way to save the rating and return to the view-state, so I changed the “Rate this widget” link to Save and Cancel links, which also helps indicate to the user that the widget is now editable.

To start the interaction, the user simply clicks the link, then clicks the star she’d like to use to rate the widget.

At this point, the user can click Save, Cancel, or another star. Let’s assume she chooses to save the rating.

Upon saving the selection, the current rating for the widget is updated and the new rating appears, again in a display-only state. This indicates to the user that the interaction is complete and her rating has been saved.

Later on, we decided to put a little text next to the “Rate this widget” link that showed how many users have rated the widget - something like “(Rated 7 times)”. This not only tells existing users how much stock they can put into the rating (a single rating isn’t a clear sign that something is good or bad), but also tells the user that her rating has been added.

Finally, we added some business logic to the interaction that prevents a single user from rating the same widget multiple times. As in, if she chooses a different rating on a future visit, the average is updated, but the number of reviewers does not change.

The result? A single design element that both displays the current rating and offers a way to save a new rating.

Yahoo! has had a User Interface blog going for a while, and their latest post raises a few interesting items. From the post:

“This was later generalized into what’s commonly referred to as the Pareto principle (also known as the 80-20 rule), which states for any phenomenon, 80% of the consequences come from 20% of the causes. We see this phenomenon in software engineering where 80% of the time is spent in only 20% of the code. When we optimize our applications, we know to focus on that 20% of the code.”

In other words, 80% of the code can be produced in 20% of the allotted time. The remaining 20% of the code - the part that takes the longest to hash out - is where the real work is. That’s where features are smoothed out, and existing code is polished and refined, and page load times are reduced, and pixels are perfectly-aligned, and things are made consistent from page to page, and designs are tweaked to make them better support a user’s work flow, and so on. That’s where things get good.

It’s wonderful that 80% of an application can be created in 20% of the time, because it means we can spend the other 80% of our time making it shine, so that it makes a great first, and lasting, impression.

Basement.org’s “Technical Ignorance Is Bliss” is a great reminder that people outside our industry don’t think like we do. They don’t work like we do. And they don’t understand computers like we do.

I tell stories like the ones in the post pretty often, but I’ve never bothered to write them down. I get a lot of great ones from my wife, who teaches computer classes at her library, and I’ve seen quite a few myself. Some highlights:

1) A man who entered his username into his browser’s Address bar wanted to know why he couldn’t access his home computer.  He was at the library.

2)  A woman held a printed piece of paper up to her monitor and wondered why she couldn’t scan the document.

3) Extremely common: A user enters his email address into the Address bar and wonders why his email won’t open.

4) Also extremely common: A user enters the domain associated with her email address into an Email Address field in a form. Instead of entering an email address, she enters “Yahoo.com”.

These people are not stupid. A lot of the people commonly viewed as idiotic users have Masters degrees, run their own businesses, write books, and so on. They’re all experts in something. They just don’t need to know how computers work they way that we do, so they don’t bother.

And really, why should they?

Keep these people in mind the next time you design … well, anything.

It’s a rare moment that my dog decides to be cute when there’s a camera around. Tonight was one such occasion, however, and I managed to snap this one before she caught on to my deviant plan to exploit her on the internet.

For those of you that missed my Designing the Obvious web presentation the other night, the recorded version is available here.

The audio is pretty quiet, so crank up those speakers. And since it was the day before Thanksgiving here in the USA, not many people were able to attend. Hopefully I’ll be able to speak for the group again sometime soon.

Thanks to John and the rest of the Flash and Multimedia Users Group of Arizona for having me.

My apologies to the boys at 37signals, by the way. I suggested during the presentation that they should stick the screencasts they link to from empty Basecamp pages into the pages instead of just linking to them, but it turns out I was using an old screenshot. 37signals has, in fact, updated their blank slates in Basecamp to include the screencasts. Nice work, guys!