Journal tags: user

10

sparkline

The state of UX

There is much introspection and navel-gazing in the world of user experience design. More than usual, I mean.

Jesse James Garrett recently said:

I don’t think I know anyone that’s been in UX more than a decade who’s happy with how it’s going.

In a recent issue of the dConstruct newsletter—which you really should subscribe to—I pointed to three bowls of porridge left out by three different ursine experience designers.

Mark Hurst wrote Why I’m losing faith in UX. Too hot!

Scott Berkun wrote How To Put Faith in Design. Too cold!

Peter Merholz wrote Waking up from the dream of UX. Just right!

As an aside, does it bother anyone else that the Goldilocks story violates the laws of thermodynamics?

Anyway, this hand-wringing around the role of UX today seemed like a suitably hot topic for one of our regular roundtable chats at Clearleft. We invited Peter along too and he was kind enough to give us his time.

It was a fun discussion. Peter pointed out that whenever he hears an older designer bemoaning the current state of design, he has to wonder what’s happened in their lives to make them feel that way (it’s like when people complain about the music of today and how it’s not as good as the music of whatever time period I was a teenager). And let’s face it, the good ol’ days weren’t so good for everyone. It was overwhelmingly dominated by privileged white dudes. The more that changes, the better …and it needs to change far, far more.

There was a general agreement that the current gnashing of teeth isn’t unique to UX. It’s something that just about any discipline will inevitably go through. Peter’s epiphany was to compare it with the hand-wringing around Agile:

The frustration exhibited with the “dream of UX” is (I think) identical to the frustration the original Agile community sees with how it has been industrialized (koff-SAFe-koff).

Perhaps the industrialisation of what once a cottage industry is the price of success. But that’s not necessarily bad, as long as you industrialise the right things. If UX has become the churning out of wireframes at scale, then something has gone very wrong. If UX has become the implementation of dark patterns at scale, then something has gone very wrong.

In some organisations, perhaps that’s exactly what’s happened. In which case, I can totally understand the disillusionment. But in other places, I see the opposite happening. I see UX designers bringing questions of ethics to the forefront. I see UX designers—dare I say it?—having their proverbial seat at the table.

Chris went so far as to claim that we are in fact in a golden age of user experience design. Controversial! But think about it, he said. Over the next few days, pay attention to interactions you have with technology, and consider the thought and skill that has gone into them.

I had Chris’s provocation in mind when I wrote about booking my vaccination appointment:

I just need to get in, accomplish my task, and get out again. This is where the World Wide Web shines.

Maybe Chris is right. Maybe the golden age of UX is here. It’s just not evenly distributed. Yet.

It’s an interesting time for the discipline of user experience design. I’ve always maintained that the best way to get a temperature check for your chosen field is to go to a really good conference. If you’re a UX designer and you want to understand the state of the UX nation, you should get a ticket for the online UX Fest in June. See you there!

Get safe

The verbs of the web are GET and POST. In theory there’s also PUT, DELETE, and PATCH but in practice POST often does those jobs.

I’m always surprised when front-end developers don’t think about these verbs (or request methods, to use the technical term). Knowing when to use GET and when to use POST is crucial to having a solid foundation for whatever you’re building on the web.

Luckily it’s not hard to know when to use each one. If the user is requesting something, use GET. If the user is changing something, use POST.

That’s why links are GET requests by default. A link “gets” a resource and delivers it to the user.

<a href="/items/id">

Most forms use the POST method becuase they’re changing something—creating, editing, deleting, updating.

<form method="post" action="/items/id/edit">

But not all forms should use POST. A search form should use GET.

<form method="get" action="/search">
<input type="search" name="term">

When a user performs a search, they’re still requesting a resource (a page of search results). It’s just that they need to provide some specific details for the GET request. Those details get translated into a query string appended to the URL specified in the action attribute.

/search?term=value

I sometimes see the GET method used incorrectly:

  • “Log out” links that should be forms with a “log out” button—you can always style it to look like a link if you want.
  • “Unsubscribe” links in emails that immediately trigger the action of unsubscribing instead of going to a form where the POST method does the unsubscribing. I realise that this turns unsubscribing into a two-step process, which is a bit annoying from a usability point of view, but a destructive action should never be baked into a GET request.

When the it was first created, the World Wide Web was stateless by design. If you requested one web page, and then subsequently requested another web page, the server had no way of knowing that the same user was making both requests. After serving up a page in response to a GET request, the server promptly forgot all about it.

That’s how web browsing should still work. In fact, it’s one of the Web Platform Design Principles: It should be safe to visit a web page:

The Web is named for its hyperlinked structure. In order for the web to remain vibrant, users need to be able to expect that merely visiting any given link won’t have implications for the security of their computer, or for any essential aspects of their privacy.

The expectation of safe stateless browsing has been eroded over time. Every time you click on a search result in Google, or you tap on a recommended video in YouTube, or—heaven help us—you actually click on an advertisement, you just know that you’re adding to a dossier of your online profile. That’s not how the web is supposed to work.

Don’t get me wrong: building a profile of someone based on their actions isn’t inherently wrong. If a user taps on “like” or “favourite” or “bookmark”, they are actively telling the server to perform an update (and so those actions should be POST requests). But do you see the difference in where the power lies? With POST actions—fave, rate, save—the user is in charge. With GET requests, no one is supposed to be in charge—it’s meant to be a neutral transaction. Alas, the reality of today’s web is that many GET requests give more power to the dossier-building servers at the expense of the user’s agency.

The very first of the Web Platform Design Principles is Put user needs first :

If a trade-off needs to be made, always put user needs above all.

The current abuse of GET requests is damage that the web needs to route around.

Browsers are helping to a certain extent. Most browsers have the concept of private browsing, allowing you some level of statelessness, or at least time-limited statefulness. But it’s kind of messed up that private browsing is the exception, while surveillance is the default. It should be the other way around.

Firefox and Safari are taking steps to reduce tracking and fingerprinting. Rejecting third-party coookies by default is a good move. I’d love it if third-party JavaScript were also rejected by default:

In retrospect, it seems unbelievable that third-party JavaScript is even possible. I mean, putting arbitrary code—that can then inject even more arbitrary code—onto your website? That seems like a security nightmare!

I imagine if JavaScript were being specced today, it would almost certainly be restricted to the same origin by default.

Chrome has different priorities, which is understandable given that it comes from a company with a business model that is currently tied to tracking and surveillance (though it needn’t remain that way). With anti-trust proceedings rumbling in the background, there’s talk of breaking up Google to avoid monopolistic abuses of power. I honestly think it would be the best thing that could happen to Chrome if it were an independent browser that could fully focus on user needs without having to consider the surveillance needs of an advertising broker.

But we needn’t wait for the browsers to make the web a safer place for users.

Developers write the code that updates those dossiers. Developers add those oh-so-harmless-looking third-party scripts to page templates.

What if we refused?

Front-end developers in particular should be the last line of defence for users. The entire field of front-end devlopment is supposed to be predicated on the prioritisation of user needs.

And if the moral argument isn’t enough, perhaps the technical argument can get through. Tracking users based on their GET requests violates the very bedrock of the web’s architecture. Stop doing that.

Influence

Hidde gave a great talk recently called On the origin of cascades (by means of natural selectors):

It’s been 25 years since the first people proposed a language to style the web. Since the late nineties, CSS lived through years of platform evolution.

It’s a lovely history lesson that reminded me of that great post by Zach Bloom a while back called The Languages Which Almost Became CSS.

The TL;DR timeline of CSS goes something like this:

Håkon and Bert joined forces and that’s what led to the Cascading Style Sheet language we use today.

Hidde looks at how the concept of the cascade evolved from those early days. But there’s another idea in Håkon’s proposal that fascinates me:

While the author (or publisher) often wants to give the documents a distinct look and feel, the user will set preferences to make all documents appear more similar. Designing a style sheet notation that fill both groups’ needs is a challenge.

The proposed solution is referred to as “influence”.

The user supplies the initial sheet which may request total control of the presentation, but — more likely — hands most of the influence over to the style sheets referenced in the incoming document.

So an author could try demanding that their lovely styles are to be implemented without question by specifying an influence of 100%. The proposed syntax looked like this:

h1.font.size = 24pt 100%

More reasonably, the author could specify, say, 40% influence:

h2.font.size = 20pt 40%

Here, the requested influence is reduced to 40%. If a style sheet later in the cascade also requests influence over h2.font.size, up to 60% can be granted. When the document is rendered, a weighted average of the two requests is calculated, and the final font size is determined.

Okay, that sounds pretty convoluted but then again, so is specificity.

This idea of influence in CSS reminds me of Cap’s post about The Sliding Scale of Giving a Fuck:

Hold on a second. I’m like a two-out-of-ten on this. How strongly do you feel?

I’m probably a six-out-of-ten, I replied after a couple moments of consideration.

Cool, then let’s do it your way.

In the end, the concept of influence in CSS died out, but user style sheets survived …for a while. Now they too are as dead as a dodo. Most people today aren’t aware that browsers used to provide a mechanism for applying your own visual preferences for browsing the web (kind of like Neopets or MySpace but for literally every single web page …just think of how empowering that was!).

Even if you don’t mourn the death of user style sheets—you can dismiss them as a power-user feature—I think it’s such a shame that the concept of shared influence has fallen by the wayside. Web design today is dictatorial. Designers and developers issue their ultimata in the form of CSS, even though technically every line of CSS you write is a suggestion to a web browser—not a demand.

I wish that web design were more of a two-way street, more of a conversation between designer and end user.

There are occassional glimpses of this mindset. Like I said when I added a dark mode to my website:

Y’know, when I first heard about Apple adding dark mode to their OS—and also to CSS—I thought, “Oh, great, Apple are making shit up again!” But then I realised that, like user style sheets, this is one more reminder to designers and developers that they don’t get the last word—users do.

User agents

I was on the podcast A Question Of Code recently. It was fun! The podcast is aimed at people who are making a career change into web development, so it’s right up my alley.

I sometimes get asked about what a new starter should learn. On the podcast, I mentioned a post I wrote a while back with links to some great resources and tutorials. As I said then:

For web development, start with HTML, then CSS, then JavaScript (and don’t move on to JavaScript too quickly—really get to grips with HTML and CSS first).

That’s assuming you want to be a good well-rounded web developer. But it might be that you need to get a job as quickly as possible. In that case, my advice would be very different. I would advise you to learn React.

Believe me, I take no pleasure in giving that advice. But given the reality of what recruiters are looking for, knowing React is going to increase your chances of getting a job (something that’s reflected in the curricula of coding schools). And it’s always possible to work backwards from React to the more fundamental web technologies of HTML, CSS, and JavaScript. I hope.

Regardless of your initial route, what’s the next step? How do you go from starting out in web development to being a top-notch web developer?

I don’t consider myself to be a top-notch web developer (far from it), but I am very fortunate in that I’ve had the opportunity to work alongside some tippety-top-notch developers at ClearleftTrys, Cassie, Danielle, Mark, Graham, Charlotte, Andy, and Natalie.

They—and other top-notch developers I’m fortunate to know—have something in common. They prioritise users. Sure, they’ll all have their favourite technologies and specialised areas, but they don’t lose sight of who they’re building for.

When you think about it, there’s quite a power imbalance between users and developers on the web. Users can—ideally—choose which web browser to use, and maybe make some preference changes if they know where to look, but that’s about it. Developers dictate everything else—the technology that a website will use, the sheer amount of code shipped over the network to the user, whether the site will be built in a fragile or a resilient way. Users are dependent on developers, but developers don’t always act in the best interests of users. It’s a classic example of the principal-agent problem:

The principal–agent problem, in political science and economics (also known as agency dilemma or the agency problem) occurs when one person or entity (the “agent”), is able to make decisions and/or take actions on behalf of, or that impact, another person or entity: the “principal”. This dilemma exists in circumstances where agents are motivated to act in their own best interests, which are contrary to those of their principals, and is an example of moral hazard.

A top-notch developer never forgets that they are an agent, and that the user is the principal.

But is it realistic to expect web developers to be so focused on user needs? After all, there’s a whole separate field of user experience design that specialises in this focus. It hardly seems practical to suggest that a top-notch developer needs to first become a good UX designer. There’s already plenty to focus on when it comes to just the technology side of front-end development.

So maybe this is too simplistic a way of defining the principle-agent relationship between users and developers:

user :: developer

There’s something that sits in between, mediating that relationship. It’s a piece of software that in the world of web standards is even referred to as a “user agent”: the web browser.

user :: web browser :: developer

So if making the leap to understanding users seems too much of a stretch, there’s an intermediate step. Get to know how web browsers work. As a web developer, if you know what web browsers “like” and “dislike”, you’re well on the way to making great user experiences. If you understand the pain points for browser when they’re parsing and rendering your code, you’ve got a pretty good proxy for understanding the pain points that your users are experiencing.

Priorities

I recently wrote about a web-specific example of a general principle for choosing the right tool for the job:

JavaScript should only do what only JavaScript can do.

I was—yet again—talking about appropriateness. Use the right technology for the task at hand. Here’s the example I gave:

It feels “wrong” when a powerful client-side JavaScript framework is applied to something that could be accomplished using HTML. Making a blog that’s a single page app is over-engineering.

Surprisingly, I got some pushback on this. Šime Vidas wrote:

Based on my experience, this is not necessarily the case.

Going from server-side rendering and progressive enhancement via JS to a single-page app powered by a JS framework was a enormous reduction in complexity for me (so the opposite of over-engineering).

(Emphasis mine.) He goes on to say:

My main concerns are ease of use & maintainability. If you get those things right, you’re good and it’s not over-engineering.

There’s no doubt that maintainability is a desirable goal. And ease of use for the developer is also important …but I think they pale in comparison to ease of use for the end user.

To be fair, the specific use-case I mentioned was making a blog. And a blog is a personal thing. You can do whatever the heck you like on your own website and don’t let anyone tell you otherwise.

So I probably chose a poor example to illustrate my point. I was thinking more about when you’re making websites for a living. You’re being paid money to make something available on the web. In that situation, I strongly believe that user needs should win out over developer convenience.

I wrote about this recently:

As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time.

That’s why I responded to Šime, saying:

Your main concern should be user needs—not your own.

When I talk about over-engineering, I’m speaking from the perspective of end users, not developers.

Before considering your ease of use, and maintainability, consider users first.

In fairness to Šime, he’s being very open and honest about his priorities. I admire that. I’ve seen too many developers try to provide user experience justifications for decisions made for developer convenience. Once again I recommend Alex’s excellent article, The “Developer Experience” Bait-and-Switch:

The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.

Now I worry I wasn’t specific enough when I talked about choosing appropriate technology:

Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand.

I should have made it clear that I was talking about what is appropriate or inapropriate for users. I think I made the mistake of assuming that this was obvious, and didn’t need saying. I’ll try not to make that mistake again.

There’s a whole group of tools where this point isn’t even relevant—build tools, task runners, version control …anything that never directly touches the end user; use whatever works for you. But if you’re making decisions around HTML, ARIA, CSS, or JavaScript, then appropriateness for the end user should take precedence.

If you’re in that situation—you are being paid money to make websites, and you are making technology decisions—I urge you to remember Charlie’s words: it isn’t about you.

Handing back control

An Event Apart Seattle was most excellent. This year, the AEA team are trying something different and making each event three days long. That’s a lot of mindblowing content!

What always fascinates me at events like these is the way that some themes seem to emerge, without any prior collusion between the speakers. This time, I felt that there was a strong thread of giving control directly to users:

Sarah and Margot both touched on this when talking about authenticity in brand messaging.

Margot described this in terms of vulnerability for the brand, but the kind of vulnerability that leads to trust.

Sarah talked about it in terms of respect—respecting the privacy of users, and respecting the way that they want to use your services. Call it compassion, call it empathy, or call it just good business sense, but providing these kind of controls in an interface is an excellent long-term strategy.

In Val’s animation talk, she did a deep dive into prefers-reduced-motion, a media query that deliberately hands control back to the user.

Even in a CSS-heavy talk like Jen’s, she took the time to explain why starting with meaningful markup is so important—it’s because you can’t control how the user will access your content. They may use tools like reader modes, or Pocket, or have web pages read aloud to them. The user has the final say, and rightly so.

In his CSS talk, Eric reminded us that a style sheet is a list of strong suggestions, not instructions.

Beth’s talk was probably the most explicit on the theme of returning control to users. She drew on examples from beyond the world of the web—from architecture, urban planning, and more—to show that the most successful systems are not imposed from the top down, but involve everyone, especially those most marginalised.

And even in my own talk on service workers, I raved about the design pattern of allowing users to save pages offline to read later. Instead of trying to guess what the user wants, give them the means to take control.

I was really encouraged to see this theme emerge. Mind you, when I look at the reality of most web products, it’s easy to get discouraged. Far from providing their users with controls over their own content, Instagram won’t even let their customers have a chronological feed. And Matt recently wrote about how both Twitter and Quora are heading further and further away from giving control to their users in his piece called Optimizing for outrage.

Still, I came away from An Event Apart Seattle with a renewed determination to do my part in giving people more control over the products and services we design and develop.

I spent the first two days of the conference trying to liveblog as much as I could. I find it really focuses my attention, although it’s also quite knackering. I didn’t do too badly; I managed to write cover eleven of the talks (out of the conference’s total of seventeen):

  1. Slow Design for an Anxious World by Jeffrey Zeldman
  2. Designing for Trust in an Uncertain World by Margot Bloomstein
  3. Designing for Personalities by Sarah Parmenter
  4. Generation Style by Eric Meyer
  5. Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew
  6. Designing Intrinsic Layouts by Jen Simmons
  7. How to Think Like a Front-End Developer by Chris Coyier
  8. From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
  9. Move Fast and Don’t Break Things by Scott Jehl
  10. Mobile Planet by Luke Wroblewski
  11. Unsolved Problems by Beth Dean

Needs must

I got a follow-up comment to my follow-up post about the follow-up comment I got on my original post about Google Analytics. Keep up.

I made the point that, from a front-end performance perspective, server logs have no impact whereas a JavaScript-based analytics solution must have some impact on the end user. Paul Anthony says:

Google won the analytics war because dropping one line of JS in the footer and handing a tried and tested interface to customers is an obvious no brainer in comparison to setting up an open source option that needs a cron job to parse the files, a database to store the results and doesn’t provide mobile interface.

Good point. Dropping one snippet of JavaScript into your front-end codebase is certainly an easier solution …easier for you, that is. The cost is passed on to your users. This is a classic example of where user needs and developer needs are in opposition. I’ve said it before and I’ll say it again:

Given the choice between making something my problem, and making something the user’s problem, I’ll choose to make it my problem every time.

It’s true that this often means doing more work. That’s why it’s called work. This is literally what our jobs are supposed to entail: we put in the work to make life easier for users. We’re supposed to be saving them time, not passing it along.

The example of Google Analytics is pretty extreme, I’ll grant you. The cost to the user of adding that snippet of JavaScript—if you’ve configured things reasonably well—is pretty small (again, just from a performance perspective; there’s still the cost of allowing Google to track them across domains), and the cost to you of setting up a comparable analytics system based on server logs can indeed be disproportionately high. But this tension between user needs and developer needs is something I see play out again and again.

I’ve often thought the HTML design principle called the priority of constituencies could be adopted by web developers:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors.

In Resilient Web Design, I documented the three-step approach I take when I’m building anything on the web:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

Now I’m wondering if I should’ve clarified that second step further. When I talk about choosing “the simplest possible technology”, what I mean is “the simplest possible technology for the user”, not “the simplest possible technology for the developer.”

For example, suppose I were going to build a news website. The core functionality is fairly easy to identify: providing the news. Next comes the step where I choose the simplest possible technology. Now, if I were a developer who had plenty of experience building JavaScript-driven single page apps, I might conclude that the simplest route for me would be to render the news via JavaScript. But that would be a fragile starting point if I’m trying to reach as many people as possible (I might well end up building a swishy JavaScript-driven single page app in step three, but step two should almost certainly be good ol’ HTML).

Time and time again, I see decisions that favour developer convenience over user needs. Don’t get me wrong—as a developer, I absolutely want developer convenience …but not at the expense of user needs.

I know that “empathy” is an over-used word in the world of user experience and design, but with good reason. I think we should try to remind ourselves of why we make our architectural decisions by invoking who those decisions benefit. For example, “This tech stack is best option for our team”, or “This solution is the best for the widest range of users.” Then, given the choice, favour user needs in the decision-making process.

There will always be situations where, given time and budget constraints, we end up choosing solutions that are easier for us, but not the best for our users. And that’s okay, as long as we acknowledge that compromise and strive to do better next time.

But when the best solutions for us as developers become enshrined as the best possible solutions, then we are failing the people we serve.

That doesn’t mean we must become hairshirt-wearing martyrs; developer convenience is important …but not as important as user needs. Start with user needs.

100 words 057

It’s UX London week. That’s always a crazy busy time at Clearleft. But it’s also an opportunity. We have this sneaky tactic of kidnapping a speaker from UX London and making them give a workshop just for us. We did it a few years ago with Dave Grey and we got a fantastic few days of sketching out of it.

This time we grabbed Jeff Patton. He spent this afternoon locked in the auditorium at 68 Middle Street teaching us all about user story mapping. ‘Twas most enlightening and really helped validate some of the stuff we’ve been doing lately.

The User Experience Curve

My cohort from Clearleft, Andy Budd is up now. Let’s see how he does.

Without any faffing about, he kicks off with a story about checking into a hotel. This is better than bullet points any day. He maps this experience onto a graph. This is his user experience curve.

The start and the end of the experience are the most important so you should focus on those parts but the whole experience is important. Andy shows a different graph which maps the user experience curve of checking into a different hotel. This curve looks different because the experience was sub-par.

We need to look at examples from beyond the Web. Andy will go through seven touchpoints of user experience.

First Experience Counts

This sets the tone for the whole day. He quotes some dodgy statistics about how quick women make up their minds about blokes on that first meeting. Then there’s the doorman at a hotel. He’s your first experience of that hotel. Ostensibly he’s there to carry your bags but really he’s there to make sure you’re experience begins will. This doesn’t work in retail when those creepy people greet you as you enter a store.

People do judge books by their cover. Take those lovely Dorset Cereal boxes for example. The design helps sell the product. Apple have mastered the art of the first impression. Unboxing an iPod is like undressing your girlfriend for the first time —Andy’s words, not mine.

The games industry also craft the initial experience well. The first level of Call of Duty is a basic training level. This is a better experience than reading a manual. He shows some game footage, demonstrating how the game dripfeeds you instructions as you go along. Crucially, this happens in-game, not in some separate place.

Then of course, there’s the Web. People really do make snap decisions. 37 Signals do a really good job of introducing new features. Yahoo have also tried “in-game” walkthroughs with on-screen overlays.

Time for an example from Clearleft: Edenbee. On the “newbee” page, there are a bunch of overlays. Sidenote: they were a bitch to mark up and style, just so you know.

Attentive Service

An attentive waiter or waitress refill your glass without you noticing. That’s a nice experience. Then there’s the experience of queueing, not normally a nice experience. Whole Foods have been spending a lot of time studying this.

Again, Apple are a good example. Their retail stores are well-researched. They built an initial prototype based on the company’s business needs and when that clearly didn’t work, they redesigned it around the customer’s needs. Then they launched. Per square foot, Apple Stores are four times more profitable than Best Buy.

Personalisation and Customisation

Andy thinks that the key ingredient to the Wii’s success is not the wiimote but the wiimiis. In Starbucks, they ask for your name when they make your drink. The interaction is customised for you. And of course there’s the drinks customisation: mod your drinks.

The gaming world is also big into customisation. Take Josh’s WOW character that he’s invested a lot of time into. This customised avatar is also a status symbol.

On the Web we can do small things, like calling people by their name, that people really like. Then there’s customisation like on MySpace and to a lesser extent Twitter, that allows people to invest more into their pages (and they are therefore less likely to abandon that service).

Attention to Detail

Engineering problems are solvable. It’s the little design things that are hard.

In a hotel, putting a little chocalate on your pillow used to be a delighter. Now it’s passé. They have to do more now. One hotel puts a hand-written card in your room with the weather forecast for the next day. That has an emotional effect.

Car manufacturers spend a lot of time getting the sound of the car door slamming just right. A satisfying thunk is indicitive of the whole user experience.

Disney are the masters of this. Nothing in Disneyland or Disneyworld should break the Disney spell. So they have their own crafted bins. That’s consistency.

Here’s a fantastic little delighter from an Innocent Smoothie carton: the underside reads Stop looking at my bottom. That made Andy smile all day long. Bless.

Threadess are good at that. Moo, of course, are experts at this with the personalities of Little Moo and Big Moo. Denise is in the audience somewhere—she must be happy.

The parallax effect on the Silverback holding page is a also a delighter. Only a small percentage of people will see it but those people will be very pleased with that Easter egg.

Feedback

The gaming industry is all about feedback. Andy channels Dan Saffer as he talks about the feedback you get from a slot machine in Las Vegas.

Feedback prevents you wasting time. That little flag on American mailboxes is a handy feedback mechanism.

Feedback helps manage expectations. When you’re on hold with BT, they don’t tell you how long you’ll have to wait. The systems that tell you you are fifth in the queue are more useful and help you manage expectations.

Ultimately, feedback helps people solve their problems. Apple asked people where they had their best experiences. People said it was concierges in hotels. That’s where the idea of the Genius Bar came from: a concierge for your Mac.

On the Web, Linked In provide feedback on how much of your profile you have filled out so far. If you know you’ve only got 10% to go, you’re more likely to see it through.

Ajax is handy in adding meaningful feedback to forms. Kayak is a good example of constantly updated feedback.

Google Maps is all about feedback. You can drag, drop buttons, play around. Whatever you do, you get a reaction. Google Maps is fun.

When things go wrong, that’s an opportunity to interact with your customers. Error points are the areas where you can excell. Andy sent a snotty email to Tripit—within half an hour he got an apologetic email that turned him around from angry to happy. Error pages, of course, are the perfect place for good feedback.

Make It Fun

People like games. People like collecting. Collecting social objects brings a payoff with it. But whenever there’s a payoff in a system, that system is open to gaming. Points are useful for letting you know where you stand in a system but they also lend themselves to leaderboards. That can discourage the newbies at the bottom of the leaderboard.

Flickr is like a game based around collecting social objects—in this case, photos (thankfully Andy is using the term social object correctly here).

Digg used to display the top 100 diggers but that led to the rich getting richer and the poor getting poorer as the system was gamed. Digg removed the feature.

Moo is a game that sucks you in. Andy initially went along to check out the site and ended up getting drawn in. Before he knew it, he had bought a pack of business cards.

Create a Perfect Environment

Andy syas we need to look beyound the Web to places like a Starbucks, the Virigin Atlantic lounge and Las Vegas to see what constitutes a great user experience. Dear God! I hope we don’t recreate Vegas on the Web. It’s bad enough in real life.

Aaaaand… he’s spent. The boy done good.

User Experience vs. Brand Experience

I’m at the Future of Web Design in London and figured I’d pass the time with some live blogging.

Right now there’s a session somewhat in the same vein as last year’s Flash vs. CSS face-off. This time it’s brand experience vs. user experience. And just as with last year’s supposed battle, the truth comes out pretty early on that actually they should work in perfect harmony.

Steve Pearce is on first, fumbling with his Mac setup and mumbling about the importance of user experience but hammering home that brand and user should be in agreement. He’s illustrating this point with some cute cartoons.

The interactive experience is like an iceberg apparently. An experience iceberg. The visual part sits above the surface (what most people see) but the main part (that people interact with) is below the surface. We spend too long focusing on the bit above the surface. It doesn’t matter how much you polish the visible bit if it’s a wreck underneath. Basically, you can’t polish a turd …or a turdy iceberg. Instead we should work on the experience, which is the stuff under the surface. The reason we should work on this is that users will spread the word about good and bad experiences.

At this point, Steve mentions social objects, misattributing the term to Hugh instead of Jyri. I don’t quite see the connection with social objects unless he’s trying to say that any good user experience is automatically a social object because people will talk about it with their friends. That’s not quite my understanding of social objects. Can I include the term social object in every sentence I write? Possibly (social objects).

Don’t work too much on the surface: work on the experience underneath. That’s Steve’s takeaway point.

Now Andy is up to talk about the importance of brand. To demonstrate his point, he will refer to classic British comedy acts like Morecambe and Wise.

Andy makes the point that branding isn’t about what’s up on the billboards. It’s more about the experience and emotional attachment. Think Starbucks. Think Twitter.

Quoting Seth Godin, Andy says that a brand is really about getting people talking to each other. You know, the viral thing.

Now for an Eric Morecambe interlude. There is a connection though. In the past, everyone used to watch the same television shows and share the experience. There were far more people watching the Morecambe and Wise Christmas special than the most-watched TV programme today. Back then we consumed media in a very different way. These days it’s harder to reach those numbers and create something that spreads so widely. Back to the Eric Morecambe jokes now.

Andy plugs Dan’s book. Instead of thinking of systems-centred design, we can practice user-centred design. What if we make people something they love emotionally instead of asking them what they want? This is reminding me of Henry Ford’s quote that If I had asked people what they wanted, they would have said faster horses.

Then there’s activity-centred design. Look at what people do instead of asking them.

Finally, there’s genius design. This is the Apple approach. You create something that you think is going to be fantastic and the user will then tell you if you were right. But you mustn’t fear failure otherwise you will never release anything risky. Yes, it’s the old “learn from your mistakes” lesson.

Andy likes the idea of inspired design. A usable design need not be a safe design.

Design should be more like one-liners from Eric Morecambe. That’s his takeaway point.

An awkward silence follows. Our compére, Paul Boag kicks off the Q and A by asking C’mon, it’s all good and well to say it’s okay to fail and learn from our mistakes, but I don’t think our clients would like that very much!

Steve says that a beta testing period is a good time to fail. You can then learn from your mistakes and still improve the product. It’s humbling to learn that we don’t know what users want.

Andy says this what we hired for—to create and experiment and sometimes fail. Otherwise we’re just painting by numbers.

Steve says creating great work requires a great client.

Next question: is there any way of measuring the value of user experience?

Steve says you can measure it by how much people talk about it. But there’s no magic bullet for measuring it.

The next question may or not be about inspiration. The advice from the panel is not to create Frankenstein designs by mashing up the best bits of other sites. Those bits don’t work so well out of context. That may or may not answer the question.

Now a question about roles and who should be doing what. Silos are bad, mmkay? Engineers, designers, developers …who calls the shots? Andy insists on doing his own wireframes. He also designs using HTML and CSS. He doesn’t want to get bogged down in process. Who wants to spend their answering Basecamp messages. Steve reminds us that design is about solving problems and that isn’t the exclusive domain of designers—engineers are good at that too.

And with that, Paul kicks them off the stage.