I recently posted about the Netflix recommendation system and their reaching out to make it better. I also mentioned how I think that Netflix is one of the best examples on the internet of a site that is both beautifully designed yet very usable.

User Interface Engineering took a deep look into what makes Netflix such a great site by talking with the Netflix design team.

Here are some insights to their “Release early, release often” mentality…

Benefits of Fast Iterations

• Fail Fast
  A major benefit of fast iteration is you also fail fast. Failing fast means you invest less time in the things that don’t work. If you quickly find out what works and what doesn’t work, then you take action to turn it into something that does work.

  Ironically, teams that fail fast improve as fast, if not faster, than those who try to get it right the first time. The reason is simple: Teams trying to get it right the first time fail as often as everyone else does. However, when they fail, they fail really slowly and struggle to pinpoint problems because they’ve changed so much at once, making it harder to identify solutions

• More Experimentation
  The faster you fail, the more experimentation you can do. You can try out ideas that might not have a lot of support, but could be potential winners. This allows for an innovative environment.

  Perhaps you’ve heard of Google’s 20% time? They expect their engineers to work 20% of their time on a personal project — an experiment they find personally interesting. This program has the effect of bootstrapping experimentation, so it will happen more often.

• Learn Quickly
  We’ve all had the experience of sitting in meetings arguing whether something will work or not. Usually, both sides just don’t have enough data to go on, and they end up going with their gut or with the loudest arguer (for better or worse). Fast iteration helps solve this problem by giving developers a platform on which they can test quickly, helping to collect data about any outstanding questions instead of resorting to opinionated arguments.
• Provide Continuing Interest
  In addition to improving your design, fast iterations may have a psychological effect on users. Those users who use your app with any frequency will notice the changes, and if the good ones stick, they’ll appreciate your ongoing efforts to improve.

  The best teams not only design the changes, but design the process for introducing the change. They experiment with methods to overcome the users’ natural resistance to change, providing migration paths and clear benefits for each improvement.

• Reduced Risk
  Quickly iterating helps reduce risk during design. If teams can make many small changes instead of a few larger ones, they mitigate risk because they know which changes have what effect. If a design team makes many changes at once, they have a harder time knowing which parts work and which parts don’t. When you make only one or two changes at a time, you know immediately what effect it has. Reducing risk is a valuable outcome of moving to fast iteration.

Side Effects

These benefits don’t come easy. There are significant changes design teams have to make to their core process to iterate quickly. It’s not a switch a team can turn on or off.

• Culture Change
  Most designers are accustomed to long release cycles. Fast iteration and fast evolution of design creates a different kind of design environment. Gone are the grand visions of the redesign, where teams spend months retooling vast areas of the site. Replacing it is the idea that the site is a living, breathing design that needs constant care and attention. The team at Netflix calls themselves “compulsive data wonks”. They rarely dream very far in the future. Instead, they’re concerned with what’s happening right now.
• Design Determinism
  When teams make the switch to fast iteration, it changes the site’s testing methodology. Testing becomes ongoing. After a release, you test for a certain period of time to determine what to keep and what to throw away. Then you start the process over again immediately. And repeat.

  To some designers this sounds overly deterministic: Doesn’t this take the fun out of design? If all the decisions are cut-and-dried, what does that say about creativity? What about longer-term effects? Is it possible that some features take longer to catch on than others, and that an early flop might not mean it’s not a valuable feature? With fast iterations, if the feature doesn’t work now, then it’s not right for the site, no matter how creative it is.

• You’re Either With Us…
  Netflix’s Chief Talent Officer, Patty McCord, told us their process of fast iteration causes uncomfortable situations for some designers. Once, a designer had spent time and energy working on a feature that testing showed didn’t work. When it came time for the team to remove the feature from the site, the designer was distraught. He had become too emotionally invested in his design, and it got in the way of his job. He ended up parting ways with the team and moving on. Unfortunately, the process of fast iteration affected more than the product itself.

Adobe announced that they will donate their virtual machine software to Mozilla, to work on as an open source project. Mozilla will use it within Firefox (by the first half of 2008) and Adobe will continue to use it in Flash Player 9. The name of the open source project is Tamarin and it will be governed and managed by developers from Adobe and Mozilla. News.com calls it “the largest code contribution yet to the open source Mozilla Foundation”. As Kevin Lynch, chief software architect at Adobe, told news.com: the move furthers the company’s plan to allow developers to mix and match programming technologies, including AJAX-style Web development and Flash for media and animation.

I foresee this as a bold move to the inevitable…making photoshop, flash, and dreamweaver web applications. Its a ways off, but I think that eventually all applications will be web-based. Heck, computers will likely end up being just an internet host…and all file management will be hosted (and backed up!) online.

Now in its second year, we celebrate world usability day today. This day is meant to bring more awareness to our professions, and to making things, well, more usable.

I encounter websites, applications, and material things on a daily basis that aggravate me how difficult they are to use…which in turn inspires me and gives me hope for the future of usability. Theres a lot of work to be done!

With that, on pretty much the worst day for this website to go down, the world usability day website displays a bunch of code. I’m guessing this is not the intended display. Woops!

————

UPDATE: The World Usability Day website is now back up and working beautisly.

UXmatters performed an eye tracking study on forms and label placement. The results conclude that non-bold text above the field and left aligned pose the least amount of eye work, hence a faster and easier user experience. Drop-downs should only be used when necessary and placed below the more important fields. Placing the label as the default option in the drop-down performed better than a label above the drop-down menu.

Here are the conclusion bullet points from the study:

• Label position—Placing a label above an input field works better in most cases, because users aren’t forced to look separately at the label and the input field. Be careful to visually separate the label for the next input field from the previous input field.
• Alignment of labels—In most cases, when placing labels to the left of input fields, using left-aligned labels imposes a heavy cognitive workload on users. Placing labels above input fields is preferable, but if you choose to place them to the left of input fields, at least make them right aligned.
• Bold labels—Reading bold labels is a little bit more difficult for users, so it’s preferable to use plain text labels. However, when using bold labels, you might want to style the input fields not to have heavy borders.
• Drop-down list boxes—Use them with care, because they’re so eye-catching. Either use them for important data or, when using them for less important data, place them well below more important input fields.
• Label placement for drop-down list boxes—To ensure users are immediately aware of what you’re asking for, instead of using a separate label, make the default value for a drop-down list box the label. This will work for very long lists of items, because a user already has the purpose of the input field in mind before the default value disappears.

Communicating design ideas is one of the most important skills that a designer or information architect can have. Lets face it, to be a good designer, you also have to be a good seller. You could have the best concept in the world, but unless you can clearly articulate why its the best concept in the world to your stakeholders, it will never see the light of day.

For most of us, these skills don’t come naturally…they are developed from experience and discipline. Here are a few tips that can help you develop these skills (with a few excerpts taken from the Cooper newsletter)

Have a good story to tell

Human beings think in stories, and contextualizing the proposed design solution with a story helps your collaborators imagine what the eventual user experience will be like.

Only put as much detail into the design as the idea or concept allows.

It is harder for people to evaluate high-level concepts when their eyes and attention are drawn to the multitude of details. It helps to use Lorem Ipsum for your text, a low fidelity sketch via Visio or PowerPoint, and fake data. This helps people only focus on what’s important to you. Make sure to constantly stress that its a “high-level concept” to keep people thinking the same way about it as you did when you created it.

Get all the decision-makers together in the same room

I cant stress how important this one is. Walking a design around to different stakeholders individually will get you completely different results than if everyone is in the same room together…normally causing endless tweaks to your design. Unless everyone can be there, I would highly recommend you re-schedule for a time that works for everyone. Though it may delay approval a bit, it will save you time and decrease iterations.

Carve out time in the schedule for design communication

Communicating design does take time, no doubt about it. But it will save a lot more time by reducing the thrash that occurs when developers don’t have a clear understanding about what it is they are supposed to build. Get developers involved early in the design process…their input is invaluable.

Here in Denver, the voting process was quite a mess. New digital voting machines were in place, and in many locations it took 2 hours of waiting in line to cast your vote. Lots of people did not get to vote because they were pressed for time and couldn’t wait that long.

I voted early and did not feel the effects of this problem. I felt that the voting system was efficient, and the voting machine was extremely easy to use (granted that i am a tech savvy geek).

The voting process as I experienced it:

Check-in: 5 Minutes

There were 2 booths. At the first booth I signed my registration card in front of an election official. I then brought the card to another booth where someone scanned my card and typed some stuff into a computer. She then handed my card to a person next to her that typed some more stuff into another computer and then printed my voter access code for me to use at the booth.

Voting Machine Training: 5 Minutes

The assistant educated me on every detail of how to use the voting machine and what i will expect for the review and submission process.

Voting: 5 Minutes

I then went about casting my votes. Once i was done, i hit a big red button to submit my votes. I then came to a review page, where i could go back and make changes. Once I reviewed and approved the review pages, my selections printed out on a device next to the machine, and the machine asked me to verify each page of the print outs. I could also go back and make changes there. I then came to a screen that was the final, final, final page and said clearly that once i hit that red button again, that was it. I hit it and walked out.

Factors that are more likely to have caused the long voting lines:

• This time there were only 50 or so voting places in CO, last time there were well over 100.
• The ballot was the 2nd largest in history
• Many voters are not computer savvy, so the learning curve was likely more steep for them

The voting machine interface:

The voting machine interface consisted of a numerical pad (to input your 4-digit voter access code), a knob-wheel (to scroll though the ballet and highlight a candidate or Yes/No answer), a select button (to select/deselect your choice), and a “cast your vote” red button for the final submit. I was given 3 chances to review my selections and edit to ensure accuracy. The digital screen was very large and extremely easy to read.

I am curious to hear from some of the volunteers that dealt with all of the voters to see how people struggled with these machines…thats where I would start to troubleshoot the problem. The mayer has vowed to ensure the problem never happens again.

UIE has released a new e-book, “The Designer’s Guide to Web Applications“, and as a promotion for the new book, they have released the first chapter (10 pages), “Structure & Flows” for free as a pdf.

The free chapter explains how to use Hubs to help architect an application structure.

Table of contents (the italics section is free):
1 Skeletons …………………………………………….1
1.1 The Hub ……………………………………………2
1.2 A Hub With No Data ……………………………5
1.3 The Interview …………………………………….7

2 A Real Application: SupportSuite …………..9
2.1 A simple hub and spoke—or is it? ………..10
2.2 An interview appears! ……………………….12
2.3 Hubba hubba …………………………………..13
2.4 A hub for hubs …………………………………16
2.5 Finishing touches………………………………17
3 Revealing Structure in the Design ……….19
3.1 Tabs ………………………………………………21
3.2 Menus ……………………………………………23
3.3 Tab Menus ………………………………………26
3.4 Breadcrumbs ……………………………………29
3.5 Links ………………………………………………32
3.6 Titles ……………………………………………..36
3.7 Progress Indicators ……………………………37
3.8 Knowing which element to use …………….39
4 Designing the structure ………………………40
4.1 Command Architecture ………………………40
4.2 Seeding the structure …………………………41
4.3 Enter the users …………………………………42
4.4 As we learn more, more changes ………….44
4.5 There are many possible structures ……….48
5 Creating a Winning Design ………………….49

Resources:

• Free First Chapter Download
  
• Book Page

37 signals has released their book, “Getting Real” for free. The pdf still costs $19, but you can read it online for free. I would highly recommend this read to just about anyone that works on web apps, it may change the way you think about the web application development processes.

Heres an excerpt about the book from the 37 Signals website:

Want to build a successful web app? Then it’s time to Get Real. Getting Real is a smaller, faster, better way to build software.

• Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.
• Getting real is less. Less mass, less software, less features, less paperwork, less of everything that’s not essential (and most of what you think is essential actually isn’t).
• Getting Real is staying small and being agile.
• Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.
• Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software.
• Getting Real delivers just what customers need and eliminates anything they don’t.

Resources:

• Read the book

Music Rainbow is a simple user interface to discover artists. The user controls the interface with a knob which can be turned (to select an artist) and pushed (to listen to music from the selected artist).

The demonstration is based on a collection containing 558 artists. The artists are projected onto a circle. Artists whose music is similar are placed close to each other. The similarity is computed by analyzing the audio contents of their songs. A “traveling salesman” algorithm is used to map the artists on the circle.

Colors encode different styles of music. Words describe different regions of the rainbow. These words are automatically extracted from web pages mentioning the artists.

The right side shows a magnification. The selected artist is highlighted in white. The box in the lower right summarizes the selected artist with words and colors.

MusicRainbow was developed at the National Institute of Advanced Industrial Science and Technology (AIST) as part of the CrestMuse project. The user interface was built with processing by Elias Pampalk. The knob used in the demonstration is a Griffin PowerMate.

Resources:

• Demo Video
• Website

I have been using Netflix for several years now, and while I believe it to be one of the most usable and cleanly designed websites on the interent, its algorithm to recommend movies to me has fallen way short of my expectations. I have rated roughly 600 movies on Netflix, which is more than enough to give them a good idea of what I’m in to…yet nearly all the movies that they recommend to me I dislike.

The ratings they display to you are based on how you rate other movies…which means that “The Divinci Code” could be rated as 5 stars to me, yet 3 stars to you based on how you (and others with similar ratings as you) rate other movies. This seems like a really smart way to build a rating system, but it sure doesn’t work for me. Personally I would rather view overall ratings of movies rather than an algorithmic one…that way I know I’m looking at real ratings vs. ratings a computer generated for me.

Netflix must be aware of this flaw, because, according to the New York Times, they’ve started a contest offering a million dollar prize to anyone who can improve their rating system by at least 10% (hopefully they’ll use a better system to measure improvement than they use for ratings).

The winning solution (if there is one) will not only be useful to Netflix, but useful for all recommendation algorithms out there…and just may result in pushing the internet to the next level.