Tagged: UX

I’ve been noodling on how best to present a coherent vision of user-centric website and web service design and think I came up with at least a basic model that will serve my purposes. It’s made up of identity, friends or contacts, services, activities and notifications.

To get concrete, let’s take The Future of Web Apps (London) site. The site’s pretty hot from a purely aesthetic perspective, but from an interactive or social point of view, it’s lacking. This is something that can be remedied, though, with a revised conceptual model and the adoption of a few forward-facing technologies (not all of which are completely baked just yet) but many of which are already becoming the de-facto foundations for decentralized social applications.

The Problem

The fundamental problem with the FOWA site, like most sites today, is that it is site-centric, rather than user-centric, and this has a profound effect on how the site is designed, the features it offers, and what people’s expectations for the site might be.

On the one hand, the site has an obligation to be informative, providing the basic event details: dates and location, schedule, speakers, how to book tickets, etc. On the other hand, and in support of the organizers’ desire to promote and improve engagement before, during and after the event, the site could do so much more to connect attendees and act as a digital scrapbook of everything that occurred during the event.

So while event sites still need to meet promotional and informational objectives, there’s no reason why they can’t also serve to facilitate socialization and aggregate the social objects and creative output that result from such gatherings.

The Opportunity

Now, don’t get me wrong. The point is not to turn every site into a social network. However, especially in this case, where socializing is a large part of the event’s appeal, there’s no reason why the FOWA site shouldn’t make it a little easier for folks to meet and connect before the event — to see who’s coming, and maybe to dog a couple of their friends into attending as well.

In order for social features to get traction, they’re going to need to provide an obvious upside without being too time-consuming or hard to use. Any friction to enjoying these social features — especially before making the upside obvious or significant — are going to inhibit their use and adoption.

Therefore, the easiest way to minimize barriers is to reuse the social connections and tools that people maintain elsewhere. As long as an external service provides a means for extracting media, data or connections, you can let other someone else focus on storing, editing and adding metadata to content, or simply facilitate adding event metadata to remote social objects. An event site, just like the event it represents, should really be a zeitgeist for a moment in time — an epoch for ideas, connections and learning.

The Building Blocks

The foundational building blocks of such a site begin with:

• identity: who is this person? Do they have an account or profile elsewhere that represents them or that they might rather use for identification?
• contacts or friends: a way of expressing or importing relationships between individuals as well as details like email, name, location or URL, to help find friends who might have already signed up
• services: sources of media like photos, videos or other content that can be imported or republished
• activities: atomic-sized descriptions of what someone’s doing or has done (commonly aggregated into so-called “lifestreams”; popularized by Facebook’s newsfeed)
• notifications: sites typically take email for notification for granted, but folks increasingly prefer to receive updates via other services, like feeds or Twitter. Given people the ability to choose how they want to be contacted will probably improve the likelihood that the recipient will appreciate hearing from you.

Identity

It can almost be taken for granted that just about everyone who comes to your site and wants to interact probably has an account or profile someplace else that they maintain (especially if your site is for an event called “The Future of Web Apps”). Indeed, all sites seem to presume an email address at minimum these days, and increasingly it’s becoming safe to assume presence on at least one of the following: MySpace, Facebook, LinkedIn, Yahoo, Flickr, YouTube, Google or owning a personal blog somewhere. It’s certainly not universal — yet — but for the audience that does maintain a profile elsewhere, it seems a wise idea to start looking at how you can leverage it.

After all, who really needs yet another password? Why not let them sign-in to your site using credentials that they’ve established elsewhere, say at Facebook, WordPress, Blogger or Yahoo? All of these sites act as identity providers, because they support the OpenID protocol. And so when someone signs in to your site, verifying their OpenID to you, it’s no different than you sending them an account confirmation email, except there’s no need to deal with checking email or worrying about the confirmation getting marked as spam. The whole verification process takes place in the browser.

Going one better, why not also import their existing profile? Here you have several options: scraping hCards from sites like YouTube, LinkedIn or Flickr (and many, many more); requesting several basic profile attributes with SREG ; making use of the Attribute Exchange protocol.

By supporting the concept of remote identities on your site, you’re implicitly recognizing that your site is not the only one that people use — and that you want to make it as easy as possible for people to interact. Your first priority — and your customer’s — should not be to create another account and another password, but instead to consider what you’re offering, and whether it might provide them any value. Getting the account creation step out of the way means this process can happen faster and more immediately.

Contacts, Friends and Relationships

Now that you’ve discovered who someone is, wouldn’t it be useful to help someone find the people who they might already know on your site? You might be tempted to take the discredited approach of just asking for someone’s username and password for their email address book, but why take on the liability of someone else’s email password when you can now skip this uncomfortable and unpopular password anti-pattern?

Again, you have several options: scrape friends lists marked up in XFN from blogrolls, Twitter or other microformatted services; use the new Portable Contacts API with OAuth to do friend-importing; use a proprietary delegated authorization protocol to access some of the more popular address books. For an example of this done right, see the New York Times’ TimesPeople social network:

Now, it’s important to keep in mind that the purpose of importing friends should be to provide real value: to aid in sharing and connecting. A simple but very valuable way to leverage such “portable contact lists” is to show someone a list of their friends who are already planning to attend the event. Better yet is to keep a record of someone’s friends and if any of them end up registering, let both parties know of each other’s plans. This can be done by storing hashes of identifiers (i.e. do not store the actual email address itself unless the email owner has provided it to you) and matching those hashes whenever someone new signs up.

And of course, if you allow people to connect through your site, always make sure that they can take that connection offsite by supporting the Portable Contacts API (i.e. allow for export of the speakers’ public contact information)

Services

Just as more and more people maintain accounts elsewhere, more and more people use several web services to store their photos, videos, links, blog posts, tweets, wishlists and the like. Similar to how it’s convenient reuse existing user accounts, it’s equally easy and useful to import their existing content from somewhere else.

Of course you can always just specify a universal tag (say, “fowaexpo08″) and subscribe to correctly marked-up media . Even better is to facilitate the contribution of specific pieces of content — from services that might already be indicated in what’s called someone’s “discovery profile”: an XML document marked up in the XRDS-Simple format. The beauty of this format is that it is designed to be attached to someone’s OpenID URL. So at the time of OpenID account verification, you can grab someone’s public discovery profile to learn about the different services that they use. The format also specifies how to identify “authorization endpoints”, which essentially are the gatekeepers to accessing private data stored on these remote services.

By combining OpenID, XRDS-Simple, Portable Contacts and OAuth, you can enable someone to reuse an existing account, discover their list of friends, request authorization to access this list, and then, if granted, suggest people already on the site with whom they can connect or invite to participate. What used to be a cumbersome and dangerous process is now smooth, straight-forward and secure, and applies to more than just accessing your friends.

Activities

Now that we have identity and friends accounted for, and know what services someone uses, it becomes fairly easy to start to expose, on your site, the activities that someone performs related to the event. In its simplest form, when someone registers to attend the event, you can create an activity for them, both in their personal stream but also as a feed that they can bring elsewhere; when someone connects to a friend, just like on Facebook, you can expose that; when someone imports a photo or video, you can offer a thumbnail; when someone tweets about the event (say, using the hashtag), you can quote them… and so on.

The point of activities is not to show off everything that someone does, but to highlight relevant activities as a means of social discovery.

There is much work still to be done on the basic format for activity streams, but the most basic activity takes the form of actor verb social object. If you publish activity streams on your site, it is suggested that you consider using the hAtom microformat to start, and then mark up the various components using the respective classes: actor, verb, object. At least until something better comes along.

In the meantime, for an event site, activities could be useful for exposing interest in sessions, or helping attendees to let speakers know that they’re looking forward to hearing them or even for spreading new information about the event in bite-sized chunks (i.e. new speakers, etc).

Notifications

The last thing to consider is how to handle notifications. While email still reigns supreme, syndicated content and services like Twitter have become alternative viable means for staying in touch.

There are lots of options here, from instant messaging over XMPP to SMS to Twitter to posting activities of your own. The important thing is to recognize that email isn’t the only means to stay in touch any more — and for some, might not even be the most preferable method of contact. The interest to drive people back to your site must be balanced against the obligation to provide useful communication.

Web services are increasing the types of notifications they offer, and provide fairly granular control over how they contact their members. Mixin is one example to consider:

Another is Brightkite:

Thinking about your opt-in notifications strategy ahead of time — by coordinating efforts among your team to reduce duplication and increase value — will likely improve your read and conversion rates, and keep your attendees satisfied and informed.

Conclusion

Putting this all together, we start to see that a more formal conception of the components of user-centric web services is becoming clear. A user-centered web service prioritizes the situation of the individual and his or her use of the service, rather than the objectives of the service. This means: making logins easier and passwords fewer, the ability to interact with known friends without having to add them all over again, surfacing activities as a mechanism of discovery, and using several means of notification based on convenience. Indeed, this approach is necessary for continuing to innovate, create and offer new web services. Luckily, as this article demonstrates, a number of open and non-proprietary technologies like OpenID, OAuth, XRDS-Simple, Portable Contacts, and microformats exist that will make this approach not only feasible but simple and less costly to implement.

The conference or event site example used here is just the obvious case of a user-centered web service that would benefit from recognizing the broader context in which their users exist on the web. Hopefully through greater promotion and adoption of the technologies and concepts outlined above, we will start to see a new wave of highly valuable, useful and low-effort user-centric event sites blossom that provide high value through low-cost interactions for users and developers alike.

The phrase “user experience” is quite a mouthful. Even the acronym is kinda scary: UX, UXP, or sometimes UXD (D for “design”). It pretty much looks and sounds like the noise you make when you puke. Paradoxically, this means that “user experience” actually has a negative user experience — because, you see, the very premise behind the discipline is to make people’s lives better, happier, and easier, and thinking about puking generally does none of these things (UXP! Hello again, dinner!). The idea goes, if you make your users’ lives better, they’ll make your life better in return. Sometimes even with money! Even aside from the acronym/upchuck problem, UX(P/D) is indeed a discipline with a bit of an identity crisis. Is it design? Is it marketing? Is it user interface? Is it business analysis? Is it sitting around a campfire, holding hands and singing kumbaya?

The short answer is: Yes.

The long answer is a bit more complicated, and reads much like the ultimate chapter of Ulysses.

But I assume you’re not on Vitamin because you’re in the mood for Joyce, so this is a practical article, with a real, honest-to-god purpose. Real world applicability, even! And also commas.

In the next 20 or so minutes, you’re going to jog, climb, and tire-hop through a UX boot-camp that will leave you with some practical new knowledge that you can immediately put to use. (And hopefully not thinking about puking, even a little bit.) Even better, you’ll be learning through the time-honored tradition of ripping apart other people’s work as an object lesson.

Programmers, marketers and biz folk: pause before you run away. You may find that these ideas are useful to you, too.

First Experiences Last a Lifetime

Your mother always told you first impressions count, and the same is true of web sites. You don’t get a lot of time to sell yourself to a potential customer who loads your page; most people are lazy, and more importantly, impatient. You have to go the extra mile, because they won’t (and that is the natural and proper order of things). All the research seems to indicate that you have mere seconds to convince a shopper that he or she just has to have what you’re selling (or offering for download), to hook ’em and leave ’em wanting more, but not too much more.

Thanks to their huge relative importance, first-load experiences are so easy to get wrong. On the other hand, they’re easy to improve, too. You can extract a lot of value from just a few simple changes. And that’s what we’ll be focusing on today.

User Experience Basics

We’ll get to the practicum in just a moment but first, let’s talk — very briefly — about some super basic UX tenets:

• Be nice to your users and customers (and potential customers).
• Design as if your main goal is to inform and educate.
• Be honest and forthcoming, while you’re at it.
• Help your users and customers to do what they want, not what you want them to do.
• Be consistent with your message and quality of service (and I’m including software design here, folks).
• Scientific, measurable “usability” doesn’t necessarily make for a good experience.
• Good design makes people feel good.

Keep these ideas in mind as we move through the rest of the article (in other words, now’s the time for the obstacle course: look alive!).

Time to get our hands dirty.

Practicing Unlicensed Telepathy

If you come from a design background, you probably don’t go to Photoshop or HTML/CSS first thing. In fact, the actual designery stuff — colors, type, layout, image selection, etc. — probably comes last in your process. So much of a designer’s role is not to dictate visual choices, but to ensure that the thing is functional, after all.

Me, I always start by trying to read minds.

Whenever I’m going to design the user interface for something — it really doesn’t matter how simple — I do a few little exercises to get inside the user’s head. One of these actually involves flowcharts. I try to figure out what the user is thinking as she attempts to complete some kind of task, rather than what she’s clicking or doing or where she’s going. I try to go for the internal state rather than the external one.

Here’s an example. Let’s take a simple case: shopping for a new web browser. Web browsers are something that most people understand already, or at least most people who are shopping for them do (and the rest insist on calling their web browser Microsoft or Earthlink and thus are easily identified). So, according to my best guess, a user’s thought and decision-making process might look something like this:

If it helps, you can imagine somebody (somebody who’s less savvy about the topic than you) sitting next to you, pointing at the screen and asking you questions. (Be sure to also imagine yourself equipped with a Buddha-like patience.) Or call your Mom. Many of us designer folks tend to find the “Mom test” to be quite effective. (Your mileage may vary — it depends on the make and model year of your unit, of course.)

And then, once you have your rough thought process sketched out, you can just turn it around when you get to the design process itself. Our visitor wants to know if it costs, and if so, how much. Our visitor wants to know if it’s safe. He wants to know if he can even run the thing before he bothers to expend any more mental effort. He wants shiny, pretty things.

That’s almost like a spec!

Browser Sites Deconstructed, or, An Object Lesson

Let’s take this to its logical conclusion and dissect some browser maker’s web sites. I just so happen to be in possession of some year-old screenshots taken of the landing pages for two popular web browsers, Firefox and Opera. I used them quite successfully for UX talk I gave at OSCON 2006. I started by talking about the flowchart above, and then the browser sites and the things they did right and the things they got very, very wrong. The audience really got into it. We actually had a discussion. It was great.

Since that was such a success I figured I’d try for a two-fer.

So here, for your viewing pleasure, are screenshots of Firefox and Opera’s sites circa OSCON 2006:

Superficially, they look fairly similar. They’ve both got big, bold sections up top. They both have green download buttons. They both have links for more information about the browser. They both have a logo in the top left and some navigation buttons up there as well, for good measure.

But in terms of user experience, they really couldn’t be more different. I was delighted to find such perfectly polarized examples so easily when I was working on my talk. (And in case you’re wondering why I’m using such stale screenshots, there’s a reason. We’ll look at the modern versions, too.)

Firefox 2006: Deconstructed

So how does Firefox’s old site design stack up to our list of tenets?

Check out the green to red ratio (click for a larger version):

The good:

• the branding is clear
• you can’t possibly wonder which version is currently on offer, or which browser
• the navigation at the top is there, but fades into the background until the user wants it (thanks to its light, neutral color scheme)
• the page is segmented into two main portions, and the one with the most visual weight is also the most relevant one
• it passes the “squint test” (described later)
• the big, fat download button can’t be missed
• there’s a screenshot, which is always a good idea (many people will completely ignore a product without screenshots)
• the screenshot includes the Info window for the app itself, for an added tasty nugget of context
• the screenshot and download button are contextualized for the user’s platform — in my case, OS X
• once the download button captures the user’s attention, there are further links below it to information they might need before clicking the big, tempting button itself
• there’s plenty more info below the blue banner for users who are more inquisitive than us hair-trigger downloader types
• and they didn’t slap those award icons all over the top part of the page, which would muddy the waters (or possibly the screenshot)

The page works, pretty much. And it exudes trustworthiness and respectability (and rightfully so).

The bad:

• you can’t tell from my screenshot of the product site, but the screenshot of Firefox can’t be clicked — and that’s a bad idea because users love to click pictures
• the product description text above the big fat button is, as my scratchings indicate, mostly marketing drivel
• the big green button wasn’t a button: you couldn’t click anywhere on it (at least you couldn’t at the time in Safari) and it didn’t change on mouse-over
• they could have exploited browser detection to suggest why I might want to switch (as I was using Safari), or to tell current Firefox users if their current browser is the most current
• there’s no search box handy
• they could have also pushed the community more

All in all, though, my feedback for this landing page is almost overwhelmingly positive.

The negatives only stand out because they’re surrounded by so much awesome.

Opera 2006: Deconstructed

Now that we’ve checked out the model child, it’s time to move on to the one with the messy room, angry music and seditious haircut:

Oh, Opera from the past … where can I even start? You could go so far if only you’d focus and apply yourself.

You probably noticed that the green to red ink ratio is quite different for the Opera site. Somebody made a lot of elementary mistakes when they put this page together. The good news is, such mistakes are also easy to avoid and you can usually fix them without too much trouble, too.

The good:

• big green target button means the page half-passes the squint test
• the button informs you which platform’s version you’ll be getting if you click it
• links are provided for potential customers to find out more about the product before downloading, and they’re not buried
• there’s a search box readily available
• overall, the impression is fairly attractive

The bad:

• the banner heading with all the people, names, and the need to “choose” a person to find out more about the browser is not only distracting but also confusing
• it’s also mushed together out of disparate bits of stock art (and it’s obvious that this is the case)
• the whole “choose your style” thing with a bunch of painfully young/painfully hip people just screams we’re trying really hard to be relevant! look at us, we get it!
• and people are becoming savvy about the whole “add faces! that’ll give you instant interest and impact!” marketing maneuvers
• the overly boxy/clever design elements draw the eye away from the main area of the page
• the download button says “Free Download” but, in fact, Opera is not free (but hey! the download itself doesn’t cost!) — people don’t appreciate this kind of sneakiness (Update: Please see the addendum at the end of the article. Thanks.)
• there’s no written product information about their main product — the web browser for computers (as opposed to portable devices) — anywhere on this page
• right below the big banner area, there’s a big distracting “Free!” picture which will draw a lot of people’s clicks, but if you read the small text you’ll see that this is actually for an entirely different product (Opera Mini)
• the icons for the links to the right of the download button are visually redundant and half of them don’t really make sense for the link
• there’s no link to download versions for other operating systems than the one it identified you as having
• the top nav bar/logo area is too large and has too many tabs (but this is a lesser sin)

There’s a lot of red ink there, but almost all of the individual mistakes fall under one single root problem: lack of focus.

Failing to define and then rigorously defend a single focal point is the easiest — and worst — thing you can do when designing a landing page for a product or company. You can try to be all things to all people but what you’ll end up with is not a delicious goulash but a nasty concoction you really, really won’t want to put in your mouth. Or near your mouth. Or in the vicinity of your body—say, a 100 mile radius.

Fast Forward to 2007

Time for a little time travel. Here are Firefox’s and Opera’s respective sites circa right now:

As you can see, Firefox’s effective page has remained much the same. I personally would advise the designer to resist the urge to replace the screenshot with the trendy, swoopy image of people using computers, but that’s a minor issue for sure. (Although I will say, it should still be clickable! And it’s not.)

And somebody has given Opera’s site an amazing, almost Apple-esque facelift. I don’t know who you are, Ms. or Mr. Makeover Artist, but allow me to be the first to congratulate you creepily in a Vitamin article: you done good.

Opera’s designer has trimmed down the competing influences, reduced the noise, and given the page a coherence that it completely lacked before. The Lifestyle and Creativity stuff is still kinda weird but at least it’s not really distracting and the Nintendo block isn’t going to accidentally steal clicks from the star of the show because it’s clear, now, what it is. (No deceptive “FREE!” burst here.)

Both pages now pass the squint test rather handily. Speaking of which …

The Squint Test

I always use the Squint Test to evaluate landing pages. It’s as easy as saying “if the wind changes, it’ll stick that way”:

Close one eye and make the other go all fuzzy. Can you still identify the key parts of the design? Give special consideration to important areas of focus and the download/call to action button.

The Case is Rested

It’s much less fun to try to rip apart things which largely work, so this seems like a good a place as any to wrap up this article. If I can leave you with a parting suggestion, it’s to become an anthropologist of web experiences. When you find them in the wild, study them. Approach them with fresh eyes and take notes. What works for you? What doesn’t? That’s one of the very best ways to learn.

Update

As the many comments will point out, Opera is now free. When I last actually tried to download it, it tried to sell me a version for $29. But apparently that was optional — which I never found out because the moment I saw dollar signs, I quit the process.