(Part of a series on Web App Trends. Also see: Users as Developers)

Have you ever noticed that many successful web apps seem to change a lot? The designs are always being retooled, changed, improved, upgraded, tweaked?

This is a trend we’re seeing more and more of. Many teams are changing their development process to speed up iterations. Instead of taking months to roll out a new release, they’re breaking it down into smaller parts and releasing them more often. This helps to reduces risk, the smaller the change the smaller the risk and the easier it is to figure out what is working and what isn’t working. Taken to the extreme it would be science: test one isolated variable at a time and iterate accordingly.

One of our clients recently told us, “the faster we iterate, the faster we learn”. In his view, the quicker they release iterations, the quicker they can improve on them. They call this on-the-job-training, referring to the app as being tested by the actual users while they’re using it, as opposed to traditional pre-release testing.

So how fast can app iterations get? Well, teams are all over the map. Another team we know takes about 4 months to make any change to their web app, even the smallest text tweak. If they want to change a navigation button to read different, it takes 4 months. The levels of corporate hierarchy and business rules simply take that long. Interestingly, the product inventory on their site is updated daily, by a completely different development team! They have fully separated their application framework from the products they’re showing in it.

Most teams are faster, though. Mike Davidson, who founded Newsvine, a social news app, recently wondered if two week iterations were fast or slow. Apparently, for some teams it is dreadfully slow, as they update as fast as they can.

I spoke with a developer of QVC.com at the UI Conference who said they often update their site several times a day. Their promotions practically demand it. One promotion might run out in twelve hours and they have to get it on the site and taking orders as fast as possible. He said they also do extensive A/B testing to see what sorts of promotions work and what ones don’t. But they bypass that slower testing method when they need to get a promotion up quickly.

Iteration for iteration’s sake is probably a bad strategy. But many teams are moving to fast iterations to both learn things faster and sometimes simply because their business rules demand it.

So, how fast are your iterations?

Note: This post grew into an article: The Freedom of Fast Iterations: How Netflix Designs a Winning Web Site

On Friday we released a brand new report in our UIE Fundamentals Series. It’s called The Designer’s Guide to Web Applications, Part I: Structure and Flows.

Download a Free Chapter of The Designer’s Guide to Web Applications here.

We’re really excited about this report. One of our most popular conference speakers, Hagan Rivers (who is giving a full-day tutorial at the Web App Summit in Monterey this January) has distilled some of her vast knowledge of web applications into this easy-to-read report. Some of the topics she covers are:

• How to build your application’s structure diagram. Hagan will explain how to use structure diagrams as shorthand for visualizing your designs. Structure diagrams help you communicate your application’s structure with your team members and to help everyone focus on the key parts of the design.
• How to identify the two basic forms of application structure: Hubs and Interviews. The two most common structures found in web apps, Hubs and Interviews are essential components in your toolkit. You’ll get a comprehensive introduction to these two components, with several examples showing you when to use each type of structure.
• Which design elements to use. Hagan will show you where and when to use tabs, menus, breadcrumbs, links, and titles in your application. She’ll go over the strengths and drawbacks of each element.
• How to build your application’s Command Architecture. When you design the organization of an application, you’re building a command architecture, a hierarchy of hubs and interviews reflecting each command in your application. Hagan will show you how to build your architecture, step-by-step.

If you’re just getting into web apps or are working on improving the design of an existing one, Hagan’s report will prove invaluable. And don’t forget to check out the free chapter

Over the years we’ve heard lots of different ideas about what web applications are and what they do. Here’s a quick summary of the most popular ones…

• You enable two-way communication
  A web application is, above all, enables two-way communication with users. It’s a conversation between a user (or users) and the web app, with the web app presenting a series of interaction possibilities and the user interacting with them. This is in contrast to a one-way, read-only experience where the user sits passively by simply reading information. In web apps, reading is only half the conversation. Listening to, processing, and saving information is the other half.
• You have HTML forms
  Some folks equate an HTML form element with web applications. If users are submitting or changing information with an HTML form, then they’re using a web app. This is similar to a two-way conversation: if you have a form then users can talk back to you. If they’re simply browsing around without submitting anything, it’s probably more of a site than an application.
• You think in screens instead of pages
  Like desktop applications, web applications are built out of screens instead of pages. Screens are different from pages in that they serve to handle some sort of transaction, generally following interaction design principles (e.g. show system status and provide feedback) in addition to graphic design principles. This, of course, didn’t stop people from building apps out of pages, but the swiftness with which we’re moving to AJAXified apps suggests just how inelegant the page model is for interaction.
• You have user accounts
  One of the traits of web applications is that they have user accounts. This is necessary to save personal information such as order history, preferences, and bookmarks as well as provide authentication for accessing personal data. Online banking, blogging tools, and your favorite photo sharing site would be impossible without them.
• Your interface is your product
  Most web sites exist to do one of two things: advertise something or display unique content. In these cases the web site itself is not the product: the product is only revealed in some way through the interface. In web applications, on the other hand, the interface is the product. The interface is the customer-facing artifact through which users get value and communicate with the organization. Some companies, such as Amazon and Netflix, rely solely on the application to deal with customers. Each of these companies wouldn’t exist without their web application doing the work.

(If you’re thinking about attending our Web App Summit in Monterey, California this January, and are having trouble convincing someone that you’re working on a bona-fide web application, this list is for you!)

We’ve set up a Flickr group for those attending UI11 (either in the flesh or vicariously). You can find it here:

http://www.flickr.com/groups/ui11/

Feel free to join the group. The tag we’re using is “UI11″.

Here’s a snapshot we’ve already uploaded to the group. It’s from Jared’s keynote, which we’re listening to now. This is a shot of me and Colin Price, the Manager of Media and Technology at Harvard Health Publications. Colin took this shot with his MacBook Pro’s built-in camera, using one of the image filters in the Photobooth application. I’m jealous…I don’t have a camera on my Mac.

For more pics, check out: UI11 Flickr Group

There’s a saying that “Every kiss is a promise”. Every time you kiss someone, you’re setting some expectation for the future. You’re together…and you’re dating/going out/seeing each other (or whatever they’re calling it nowadays). It’s kind of like a girl wearing a boy’s varsity jacket: everyone knows that those two are an “item”, as my mother would say.

I’m listening to Bryan and Jeffrey Eisenberg right now (in their session: Creating Persuasion Architecture Online), and Bryan is telling us that, like a kiss, every banner ad is a promise. When you view a banner ad, it is setting expectations about what you should find at the other end…when you click it.

But most banner ads fail to deliver on their promise. Or, rather, most landing pages fail to deliver on the promise made by the banner ads. Most are disconnected with the ad that sent people there, often changing the subject, style, or mood of the ad. This change is detrimental to success. Conversion is all about consistency, consistency, consistency in message. The Eisenberg’s preach this message rather…consistently.

The Eisenbergs (who, as brothers, seem connected at the subconcious level…they finish each other’s sentences with amazing clarity) suggest that the failure of many banner ads isn’t caused solely by the difficulty of the medium, but also because they’re created by different teams or people who don’t create a compelling, seamless experience.

Many banner ads, it seems, aren’t very good lovers. Their promises, for the most part, mean very little.

In their UI11 presentation Building and Managing a Successful User Experience Team, Sarah Bloomer and Susan Wolfe are tackling a huge challenge in web design: convincing stakeholders of the value of usability. To help do this, Sarah and Susan employ what they call a usability affinity grid.

The usability affinity grid is comprised of 4 levels. Each level builds on the others, moving from business goals to usability goals. Talking about a project in terms of a usability grid helps large or dispersed teams and their stakeholders get on the same page, agreeing on the value provided by a focus on usability in the organization.

Here are the levels, and how they build on each other.

1. Business Goals
   Business goals are the goals that the business needs to reach in order to be successful. These are often very straight-forward, but difficult to achieve. One big goal of many businesses is repeat revenue, getting revenue from folks on a recurring basis. Magazine subscriptions are a great example of recurring revenue occurring on a yearly basis.
2. Issues
   Issues are the problems that arise during daily operation and directly affect business goals. In a call center, for example, the biggest issue is the hold time for incoming calls. As hold time increases, customer satisfaction goes down, and customers become frustrated and angry, making business goals more difficult to attain. We’ve all had the experience of being on hold and having a pseudo-pleasant voice promising us “Your call is important to us”. Argh!
3. Business Objectives
   Business objectives are objectives that, if reached, will solve the outstanding issues of the organization. In the call center example, the obvious business objective is to reduce customer queues. This objective doesn’t lead to revenue directly, but indirectly.
4. Usability Objectives
   If one of your business objectives is to reduce calling queues, then a usability objective might be to enhance the productivity of the call center operators. Designing to support efficiency of use of the call center operators would directly reduce the time it took to handle each call, which would directly address the issue and thus the business goals in the end.

As Sarah and Susan point out, this grid is simply a tool to help design teams within an organization. Some teams already use this sort of reasoning implicitly, without mapping out these levels explicitly. But for those teams who are still struggling with communicating the value of usability, the usability affinity grid can prove invaluable.

I’m sitting in Gerry McGovern‘s talk right now: How to Design a Task-based Information Architecture. Gerry just made a funny and interesting point about writing for the Web. He said:

‘You don’t always want to write copy that exactly matches the user’s task. It’s a very special skill to write copy that speaks to the user’s task but doesn’t call it out explicitly when you don’t want to. Just imagine those folks who are looking for a hotel room at dirt-cheap prices. You probably wouldn’t write copy that says “Dirt-cheap hotel rooms”, but that might be the idea you want to communicate’.

Gerry’s heavy Irish brogue and great presentation skills makes this much more funny than I can write. But matching the person’s task (and their conception of their task) to the copy on the page is a unique and important skill. Interestingly, as Gerry points out, people do approach tasks in many domains similarly. Many people shop for cars in a similar way, for example. They perform many of the same tasks in the process of purchasing a car, no matter what kind of car they’re looking for or even what country they’re in. Some of these include:

• Choosing a model
• Research financing options
• Research safety/consumer reports ratings
• Exploring pricing options/packages

Though there are many other steps involved, these are big ones that many people buying cars go through. When creating an information architecture, you can be sure that these tasks are going to be important. When matching these tasks to the type of business you have, the actual words in your information architecture needs to reflect the values and ideas of the users you’re writing for, without resorting to saying something like “You’ll be cool with the in-dash iPod player”. Gerry calls this “framing” the web site from a small, core set of tasks, or what he calls the “Long Neck“.

Well, it’s that time of year again: UI11 is Here! Over the next week we’re holding our Big Event: The User Interface Conference. We’ll be blogging the event, giving periodic updates of the goings-on…Here’s a quick update on the AJAX/RIA seminar I’m attending this morning.

I’m sitting in the Designing Powerful Web Applications with AJAX and Other RIAs session given by David Malouf and Bill Scott. Right now they’re discussing AJAX-friendly application frameworks like DOJO, Ruby on Rails, and Yahoo’s User Interface Library. These guys really know their stuff…I’m finding out how little I know about the latest application technologies.

David is now talking about the importance of talking to developers, really pushing the needs of users and the importance of advocating for users during the design process. He suggests that interface designers, even if they aren’t writing code, could use a high-level overview of the important details of the frameworks their developers are using. This isn’t so that interface designers can give pointers to the developers, this is so that the team can better understand each other’s needs, which leads to better team chemistry and communication. David’s point echoes very closely something that we’ve found at UIE: the design teams that focus on users best are those that communicate most…they’re always talking with each other and learning about each other’s needs.

In general, there’s a tremendous amount of conversation here…I just hope I can remember and share 5% of it!

Netflix, the easy-to-use mail-in DVD service, is offering a 1 million dollar prize to anyone who can create a better movie recommendation system than their current one. According to the NYTimes, Netflix will offer the prize to anyone who can cull through their gigantic data set and come up with a system that improves the current version by at least 10%.

That’s a tough job, given that the Netflix web site is nearly a pure-play recommendation system, meaning that without the recommendations feature the site is only a shell of its former self. The recommendations system is what drives Netflix. Roughly 2/3 of all rented movies there come from recommendations.

As far as building a better system, Reed Hastings, Netflix’s CEO, admits that they’ve hit a wall: “If we knew how to do it, we’d have already done it…And we’re pretty darn good at it right now. We’ve been doing it a long time.”

To bootstrap the contest Netflix is making a huge part of its ratings database public so contestants can deal with real data and results can be judged objectively. Though they’ve taken major precautions with their data, this is a daring move after the recent AOL debacle, wherein AOL made part of their search queries database public and even casual browsers could easily figure out who the queries belonged to. That shouldn’t happen in this case, though, and even if it did the data should not be as sensitive as AOL’s.

I think this is a really good move by Netflix. They’ll get a little press out of it as well as a better recommendation system and a better service, benefitting them two-fold. I wonder what other, similar ways companies could do something like this, open-sourcing innovation?

This could have broad effects over many industries. For many of us, recommendations are how we find out about and decide to try something new (not just movies, music, and books). We might get a restaurant recommendation from a friend, or a digital camera recommendation from a geeky cousin. We do this to save ourselves time…it would be impossible to do good research on all the items we’re interested in. Recommendations are a shortcut to good information, and most of the time are well-considered. I’m really interested in them not just because I’m speaking about them at UI11, but because I think we’ll start to see a much broader adoption throughout all sorts of web applications.

However, I do wonder how one might go about improving on Netflix’s system. One way would be to have better social data. For example, right now I only have a couple Netflix “friends” in the system, simply because I haven’t bothered to ask the people I know who use it to link up. If those people are who I listen to when it comes to recommendations, then their presence as a friend in the system should definitely improve my recommendations because it better models my current habits. However, this data cannot be part of the database offered by Netflix because it would instantly identify who it belongs to. That’s a paradox of social web sites: there’s an inverse relationship between their ability to recommend things to you and the amount of information you provide. As quality recommendations go up, privacy goes down.

At any rate, Netflix is running the contest for one year. Starting today.

I recently sat down (virtually) for a conversation about design with Luke Wroblewski, who is speaking at UI11 on communicating successfully with visual design.

We talked about the design life cycle, what stage certain products and web sites are in, and the similarities between writing and designing. It was really fun for me, as I always learn alot from Luke’s writing.

Here’s a snippet from Part 1 (on Luke’s blog: Functioning Form).

‘In the first stage of the lifecycle the role of visual design is to convey usefulness. I quote you here: “visual design bears the responsibility of communicating the possibilities, limitations, and state of interactions. It tells users what they are seeing, how it works, and why they should care.”

In later stages, the role shifts to usability and then to style. However, there are actually very few product types out there that are only differentiated by style. As you mention, gaming machines by Alienware and Dell may be one type. When new chips come out, both brands’ machines simply get a little bit faster. But Alienware looks sooo cool, that they get the nod when all other things are equal. Clothing is another area where style is a huge differentiator…but there are also attempts at providing better functionality, too. Like Gore-tex.’