What a difference a small change makes. Gmail launched what has probably been my #1 wanted feature since I’ve started using it: colored labels. Labels were useful already if you wanted to archive content meaningfully, but without a visual cue their impact on the inbox wasn’t really significant.

Colored labels however, make a huge difference. If you’re smart about the way you use labels, you can create a system for your email to prioritize conversations, organize a task list, or go all out and build a proper GTD system out of it - all with the visual cues of colored labels, because they allow you to at a glance understand what email belongs where without reading the subject or even the label text.

What to take away from this

Minor differences like these visual cues are some of the things that define application experiences, and frequently (and unfortunately) are forgotten by developers and people building products. Products that are meant to help people manage assets in their daily life in particular deserve this special caring eye on them.

People building web applications need to ask themselves “How can I provide meaningful cues to help my users?”. These things (like the need for cues) are not found by chance - people do express the need for cues and helping paths all the time, we just need to care enough to listen and make changes.

A couple of hours ago Jeff Barr (senior evangelist over at Amazon) posted about Amazon S3’s new Service Level Agreement - which if you happen to run services on the platform (like we do here at Webreakstuff) is a pretty good piece of news. Ever since Amazon S3 (or Simple Storage Service) officially launched developers have been asking for an SLA in order to formally guarantee the service’s reliability and Amazon’s commitment to keeping it going.

Some of the developers building applications with Amazon S3 have been asking us about an SLA, or Service Level Agreement. An SLA defines the minimum acceptable level of performance from a service along with some sort of penalty for not meeting expectations. A typical SLA actually defines a performance or reliability boundary which is somewhat lower than what the system is actually designed, built, and expected to deliver.

We know that many of our customers, including a multitude of teams within Amazon, are using S3 in mission-critical ways and need a formal commitment from us in order to make commitments to their own users and customers.

And the agreement looks good, too. Amazon will give you 10% service credit if uptime goes below 99.9% and 25% credit if it goes below 99% in a given month. Which tells you a lot about how reliable they believe their platform really is.

The agreement is in effect since October 1st, which means those of you who’ve wondered (for so long now) whether it would be a safe bet to host something on S3 can finally exhale. Now, and although I do trust Amazon’s reliability - I mean, it’s Amazon -, it’d be great to have an SLA for EC2 as well, but I assume that’ll be up when it officially launches.

Remember the old days when we were promised jetpacks, flying skateboards and the mobile web? Well we still haven’t got the Back to the Future gear but some would argue that devices like the iPhone do bring us closer to the internet, anywhere.

The iPhone gives you the best experience browsing the web on a mobile phone although contrarily to what some people seem to believe, that’s because it doesn’t need iPhone-specific pages to feel right. Apple did a terrific job at crafting a device that gives you the web (as it is today) in your hands. And that takes me to my main point: which is that designing pages exclusively for the iPhone is a dumb idea.

Dumb? But it’s the iPhone!

Here’s a hypothesis: Google launches their own mobile device, say, tomorrow - and it’s so beautiful you need to have it. In fact, it’s so amazing you’ll be throwing that iPhone out the window. Suddenly you get it, all those iPhone-crafted pages are suddenly useless, because they are built specifically with one device in mind.

The mobile web never really took up because designers tend to design for what’s closest to their hearts - and right now that’s the glassy phone with the Apple logo. As most people will tell you, being “closed” is a lousy way to get wide adoption - and this is just about as closed as you can get. Think about it, you’re designing pages specifically for a $599 device and expect huge visits? Oh, come on.

Design for the experience, not the device

A better idea is to design for an experience, not a specific device like the iPhone. Just like you design for desktop browsers by assessing constraints (like window size) and building an experience based on those constraints, why not do it for mobile devices in general? Truth is carefully crafted pages can actually display perfectly both on the desktop and the mobile web (iPhone or not).

The iPhone actually goes a very long way in making sure pages today work great. Instead of building a page specifically for the phone, why not one that gracefully scales to fit the device’s screen? It guarantees you’re not spending resources building for a specific device and effectively means you can focus on building one experience that’s maintained across all platforms. Give it a try.

PS: Have you also noticed how most of these iPhone-specific pages are trying hard to mimic Apple’s design too? Sacrificing resources and a brand just to make something blend in on one device is a lot worse than spending those resources on maintaining quality across the board.

Back in June I wrote an article on designing web applications through ethnography - by seeing real people in the real world, engaged in actual activities and solving real problems. That post got quite a lot feedback both in comments as well as emails, so I thought an update was due with examples of how other companies use ethnography in their experience designs.

Lets recap what ethnography means and what it allows first - and then look at examples of how it is being used by large organizations like Nokia, Intel and IBM.

From the June article: Ethnography - a method to look at user needs through observing people in their naturally setting rather than through research or, like we usually see in this space, guessing work. Ethnography allows you to design (in the broad sense of the word) products that are more in touch with your audience - to solve real problems, and not those you think people have.

Ethnography at Nokia

Business Week has the inside view on how Nokia uses ethnography to deliver richer products that solve real needs. Here’s what Nokia’s Design Director Antti Kujala has to say about their method:

Our process starts with a team of anthropologists and psychologists working in our design group. They spend time with specific types of people around the world to understand how they behave and communicate. This helps us to understand better and to spot early signals of new patterns of behavior that could be harnessed into mobile communication. Our designers often go out into the field to understand the world they are designing for. All of these observations are brought into the design process to inspire and inform our ideas.

We have an advanced design team that is looking 5 to 15 years out, working on spotting and predicting megatrends in society and coming up with thought-provoking ideas on what mobile design could do to influence and react to these.

Ethnography at Intel and IBM

Hemispheres Magazine (from United Airlines) has also a very good article on how corporations like Intel and IBM use ethnography to look ahead and enter (or create) markets ahead of competition. Make sure you read this article as well.

In addition to helping with the development of products, ethnography also can be used to direct corporate strategy, says Ken Anderson of the people and practices research group at Intel Corporation. Anderson oversees the innovation team within the digital health group at Intel. “It’s not about developing a particular product, but opening a space that had been untapped,” he says.

Inspired? Act on it.

Ethnography isn’t just for huge market cap corporations - it can and should be used in any product-oriented or service-oriented business. Chances are if you are reading this blog, you are either an entrepreneur or someone who’s passionate about the web and design. You should be acting upon these examples.

How can observation help you launch a successful product or service? What would do you differently if you looked at your target audience more deeply? Quite a lot, most likely. Here’s how you get started if you don’t have the budget or a product: carry a notebook, note down problems you have in your daily life, or problems you see other people have. You’ll likely come across solutions to these problems, and you know what that means.

Like our project management product (Goplan) came out of our necessities and problems dealing with the people we do consulting for - and by looking at how people manage their projects poorly -, you’ll likely succeed in solving real problems if you just sit down, observe and listen.