Last week’s Web App Summit, produced by Jared Spool’s User Interface Engineering, had more than the usual quotient of quality talks. The presentations were almost entirely focused on user experience, with technology and business receiving only tangential attention. Even the day titled “Going from concept to code” never really got to code, but there were enough user experience insights to make it a worthwhile couple of days.

As one might expect of talks focused on user experience, most were quite visual and don’t lend themselves to written summaries. What follows is a random sampling of tidbits that made it into my notes in an intelligible form.

Jared Spool, UIE

If you’ve ever seen one of Jared Spool’s numerous conference presentations, you know that he is one of the industry’s more entertaining and insightful speakers. His introduction followed a theme of “web apps: where business rules meet user experience.” The point, essentially, is that business rules sometimes need to be bent in the name of user experience. Jared advocates putting the user experience first, and using that to help define the business rules.

It’s often the little things that get customers excited. Jared calls these “delighters.” As the Kano Model describes, customer needs can be divided into three categories:

• Basic needs are the things that everyone expects. If you don’t meet them, it’s a huge negative factor, but doing more than is expected has no benefit.
• Performance needs are attributes that vary over a wide range, and for which the customer values each improvement.
• Excitement needs are the “wow” features, which can produce lots of user satisfaction for a relatively low investment — if you pick the right thing to implement.

This theme came up repeatedly with other speakers: it’s the little things that go beyond what’s expected that give big boosts in user satisfaction.

Steve Mulder, Molecular

Steve Mulder gave an excellent talk about user experience with rich internet applications. He started with the question “To richify, or not to richify?” His answer is that the designer should ask:

• What are common activities that could be easier?
• Where do users want more flexibility or power?
• Where are brand-immersive experiences valuable and effective?

As an example of an application in which an Ajax interaction significantly improves the user experience, Steve cited a single-screen checkout process. Products remain displayed on the left, while the form area on right is replaced, using Ajax, as the user goes through the checkout process.

Steve recommended that designers “prune with ferocity,” overemphasize the core, underemphasize the cool stuff, and be obsessive about a consistent visual system for interactivity cues.

Another interesting point was the clarification of two similar, but different, issues:

• Findability — finding something you know is there
• Discoverability — finding something you don’t know to look for

Jeremy Keith, Clearleft

Jeremy Keith gave an entertaining and largely visual talk which I’m hard pressed to summarize. But here’s a few tidbits:

• A conceptual metaphor is using one idea to describe another
• The web uses conceptual metaphors all the time — move, navigate, browse, surf
• In this metaphor, the user is a traveler, URLs are places
• Interaction is different conceptual metaphor — staying in one place and interacting with various things
• Ajax enables interaction metaphor on the web — user stays in one place
• Ajax does not mean JavaScript — asynchronous is what makes ajax special
• Best Ajax definintion: communicating with the server without refreshing the whole page
• Use progressive enhancement. First build the site without JavaScript. Then add JavaScript enhancements, but ensure that it continues to work without JavaScript.
• Keep the business logic on the server

Bill Scott, Netflix

Bill Scott, who directs the user experience team at Netflix and previously led the group at Yahoo that, among other things, created the Yahoo UI Pattern Library, gave an excellent talk on antipatterns: patterns to watch out for in your user experiences. His presentation is available online, and while it doesn’t quite stand alone without the narrative, it’s still worth a look.

Here’s a few of the antipatterns:

Meandering way

• Need to move the mouse back and forth to complete a series of actions
• Solution: reveal hidden tools on hover; avoid popup and page jitter; play on spatial memory
• Anytime anything moves, it attracts the eye, so don’t move things you don’t mant to draw attention to
• To analyze, draw arrows for each move required to complete a task

Pogo stick navigation

• Need to move back and forth between pages to accomplish a task
• Solution: encapsulation of click stream into an overlay
• Use in-context tools
• Be careful with overlays to make the back button do the expected thing

Tiny targets

• Making key interaction targets too small
• Apple site: video play button is 8 × 8 pixels, grey on grey, sometimes not near video (if large surround)
• Use “call to action”-style buttons

Hover and cover

• Pop-ups on hover can cover other important info
• Hover is good for invitations but not for actions

Animation gone wild

• You know what this means!
• nasa.gov (animated menus and collapsing sections)
• Carousel effect (amazon, others)
• Tabs that animate change of content like a carousel
• Just because you can, and it looks cool, doesn’t mean that you should

Missed moments

• Not providing feedback throughout an interaction
• Think “interactive directions” — moment-by-moment directions are the key

Bill is working on an interaction design book, which will include a section on antipatterns. It won’t be out for some time, but it promises to be worth watching for.

Sean Kane, GetListed

Sean is currently a principal in the startup GetListed, an “employment marketplace” that he wasn’t ready to talk about. His talk instead focused mostly on observations from Netflix, where he previously led the user experience group, and what start-ups can learn from big-company processes and techniques. (Sean actually spoke on the second day, but I’m including him out of order to keep the Netflix thread going.)

One of Sean’s themes was the value of data. With Netflix’s 7-million-plus user base, it has a great deal of data, and is able to use this data to evaluate alternative designs and features.

One example of a data-driven decision: Netflix recently went from an 800-pixel-wide design to one that is 950 pixels wide, when data showed that only a very small part of the user base was using browser windows less than 1000 pixels across.

Another interesting example was the way Netflix evaluated whether to add a “multiple queues” feature, so a single user could have multiple movie lists. They put a button labeled something like “Add New Queue” on the queue page, and if you clicked on it, the resulting page simply said “Sorry, this feature is still in development.” In the end, few people clicked on the button, and the feature was never developed.

Yet another good case study was the way Netflix evaluated various user interfaces for showing customers a series of trailers that had been chosen for them by the recommendation engine. They implemented several different UIs, ranging from a very simple one that give the user no options but to advance from one trailer to the next, to a more complex UI that showed the user a series of box shots next to the video player, which the could click on to move from trailer to trailer.

In qualitative testing, users liked the more capable UI. In quantitative testing, on the other hand, users of the more capable UI clicked on lots of movie boxes, but in the end they watched fewer trailers and performed fewer “Add to Queue” actions, which is what Netflix wants them to do. So the simpler UI turned out to be better in terms of meeting the business goal, even though it was not the one the designers liked best, the one that was most capable, nor the one that was favored in qualitative assessments.

Sean emphasized the importance of agility. Netflix, even though it now a large company and runs a very high-traffic site, uses a two-week release cycle. This gives it more than 20 times a year to test new features and make incremental changes. Most changes aren’t overtly noticed by users.

(This is in striking contrast to one large photo sharing site with which I had some dealings with in the past, which updates their site quarterly.)

Andrew DeVigal, New York Times

Andrew DeVigal is the multimedia editor at the New York Times. You can see the wonderful presentations his team produces in the multimedia section of the Times site.

Andrew’s team is creating some of the best examples of using Flash to present information in a compelling way. I found it interesting that his team is not divided into journalists, designers, and Flash coders: his team members play all three roles.

Jason Fried, 37 Signals

Jason Fried led off the second day and, thankfully, did not give yet another “getting real” talk but instead talked about the details that make a design great. Unsurprisingly, most of the examples came from 37 Signals products.

It was interesting to see how much thought has gone into some of the hidden details. One of the hallmarks of such details is that when they’re done right, you hardly notice them. But if they hadn’t been done right, they’d be annoyances.

Ironically, as one of the often-cited “Web 2.0” applications, Basecamp and its brethren exhibit almost none of the classic “Web 2.0” visual design traits, such as rounded corners and gradients. 37 Signals has focused on usability, not on visual appeal.

One essential practice, which would seem to be obvious but is somehow overlooked by far too many web applications, is really understanding the user’s workflow and minimizing the number of clicks required to accomplish a task. As an example, Jason showed how few actions are required to create a new to-do list in Basecamp and add items to it.

Some other examples of details that make a difference:

• Take care with copywriting: avoid technical terms, be explicit, write from the user’s perspective. An example: in Highrise, access rights for a contact aren’t labeled “permissions”; the list is headed “Who can access this contact” and has choices like “Only I can”.
• Event timing can be critical. Example: in Basecamp, an edit link appears to the left of a task when you hover over the task. But when you move your cursor to the edit link, it doesn’t disappear immediately if you overshoot; it sticks around for a quarter of a second.
• If you have multiple 37 Signals applications, you can now get a set of drop-down menus at the top of the page that let you move easily among them. Since you have to pass over these menus to get to the browser controls, the designers didn’t want them flashing up. So
  they don’t pull down until you hover for them for 1/4 second.
• Keep the user oriented when changes happen. For example, when completing a task, it appears crossed out briefly, then fades away, then disappears and space is reused.
• Scrolling up the browser when inserting an ajax dialog, so the entire dialog and the submit button is visible.

All this attention to detail is what sets a great design apart for the pack. “The craftsman spends time on details because he doesn’t know any other way” — great designs come from designers who are obsessed with the quality of what they’re producing.

In response to an audience question, Jason admitted that 37 Signals does not do any formal user testing; they just pay attention to feedback from real users. It no doubt helps that they’re designing for users much like themselves.

Hagan Rivers, Two Rivers Consulting

Hagan Rivers gave an excellent talk showing examples of how she takes existing designs and makes them more usable and more attractive. She’s been designing web applications since there was such a thing, and she and her husband run a design shop that specializes in “application design makeovers.”

Hagan put together a great set of visuals for this talk, and I can’t begin to do justice to them in words. Here’s her summary list of makeover tips:

• Remove as much as you can
• Be obsessive
• Improve just one thing
• Create strong groupings
• Let data rise out
• Beware the navigation that eats pixels
• Leverage your templates
• Watch out for technicolor headaches
• A single purpose for each screen
• Prioritize what’s there
• Never rest!

If I had a web app that needed a design makeover, Two Rivers would definitely be on my short list of companies to ask for help.

Derek Featherstone, Further Ahead

Derek addressed the issues of design for accessibility. This is a huge challenge for web application designers, and folks like Derek make a big contribution by evangelizing for better accessibility.

Derek encouraged designers to look at the needs of impaired users holistically, and not to take a compliance-based checklist approach. To create an accessible application requires thinking through a lot of issues that just aren’t on most designers’ minds.

In my own work, I have to admit that I find it overwhelming to consider all the accessibility issues, when we’re still working 110% on getting the core experience down. But as we become more intimate with what accessibility requires, it affects our coding style, and as we get further along in our development, we’ll pay some particular attention to accessibility.

Knowing when you’ve done well isn’t easy, either. Reading web pages with a screen reader is an art unto itself, and not one that a sighted designer or developer is likely to develop. So you really need to have contact with impaired users who can give you feedback on where your design creates problems for them.

If you need help with design for accessibility, check out the consulting services that Further Ahead offers.

In Closing

Jared Spool brings a nice levity to his talks, and even performed magic tricks during some of the breaks. In this spirit, I’ll close with one of his jokes.

Why are New Yorker’s always depressed?

The light at the end of the tunnel is New Jersey