90 Percent of Everything - by Harry Brignull

An introduction to Web Intents – an interview with Glenn Jones

Harry Brignull — Fri, 20 Jan 2012 08:06:55 +0000

Glenn Jones is a Founder/Director of Madgex. Glenn is currently co-organising a Design-Push event on Web Intents in Brighton (25-Feb-2012).

If you work in UX and you don’t know much about Web Intents, you’re missing out on a discussion that could have a big effect on the user experience of the entire World Wide Web. This interview should give you an insight into what it’s all about.

From an end-user’s perspective, what is a Web Intent and how does it help them do stuff?

“Web Intents” is the name of a framework for “web-based inter-application communication and service discovery”. That’s a pretty jargony definition, so let’s take a practical example.

Let’s say you found a photo of a cat on an image hosting site. There are certain standard things you might want to do with it. You might want to edit it, share it, bookmark it, order a print, or perhaps subscribe to other photos in that feed.

So, let’s say the website owner wants to give you some way to carry out these actions (or “intents”) on this object.

What’s the best way for them to do this? Take sharing, for example. There are hundreds of services out there. Should the website show a massive grid of all of them? That’d be the easiest solution, but it’d give a cluttered, tiresome user experience. So what if the the website shows just the 5 most popular services? Again, that’s not a great, as it might not include that one service you personally prefer to use.

What the website owner really wants is some way to magically know which services you want to use, for any given object (e.g. photo) and verb (e.g. share, bookmark, print, etc). This is what the Web Intents framework intends to deliver – to provide users with a single button for any of these given actions, that, when clicked, takes users straight to the services that they prefer to use. As such, it aims to improve the UX of the web.

There is a debate about the name. Some people (such as Tantek) believe it should be called a “web action”. Others want to call it a Web Intent. From an end user point of view, it doesn’t matter, since they’ll never see the name. But it’s arguable that a good name could help adoption by publishers and web developers.

It sounds it could be a real pain in the ass for users to configure their Web Intent services. I can almost imagine a browser preferences pane with 100s of options in it. Please tell me it wont be like that!

This is exactly one of the problems that Web Intents tries to avoid. Let me talk you through what a user journey might be like, roughly speaking (though bear in mind none of this is set in stone yet).

Let’s say you’ve got a fresh install of a browser and you’ve never used any of this Web Intent stuff ever before. You are browsing away, go to twitter.com, log in, and post a tweet. Behind the scenes, twitter will register it’s services with your browser. Then, let’s say you go to Tumblr and write a blog post. Tumblr, then, will also register its services with your browser. This way your browser will gradually build up a list of services that you hold accounts with and that you actively use.

Later on, let’s say you visit a website which contains a share button – one that’s powered by the Web Intents framework. If you click the share button, the browser is then passed some data (in this case, the URL) and your intent (to share). It responds by showing you a UI that allows you to pick one of your preferred services – in this scenario, it’d present you with twitter and tumblr as choices. You’d pick one, and then you’d be taken to a web page provided by that service, in a pop-up or full page.

I should emphasize that this is a rough vision of how it might work. All this is in development at the moment.

We all know that defaults can be a very powerful way to influence user behaviour. Are there any plans for Web Intents to have default services, so, for example, if I click “Share”, could I have it so I am automatically taken to Twitter and none of the other services get a look-in? Or will I always be presented with an interstitial dialog where I then choose from a list of service providers?

To the best of my knowledge, the browser vendors haven’t yet committed to including this feature in their UI.

Personally, I don’t think defaults are the right way to go. I think the user should be shown a list of matching services that they actively use. A more interesting solution would be to sort the list of possible services by by frequency of use. Defaults are too black-and-white.

Will users be able to configure their Web Intent services from a preferences panel within the browser?

Yes I believe the browsers will have to create some sort of preferences management UI, but the whole point of the approach is that it works without ever needing the user to go into a separate configuration interface. The configuration happens bit-by-bit as you navigate around the web and use the feature.

A UI should be available to those users who really want to tinker with their settings. It could look a bit like the extension manager in Chrome or the add-on manager in Firefox.

If Web Intents relied on users manually twiddling lots of settings in a complex settings panel hidden somewhere in the preferences dialog, then the feature would most certainly fail.

So are Web Intents just about pushing content out from one service to another?

No, you can also receive data – for example, if you wanted your app to pull in a contacts list from elsewhere. Also, you can do a round trip – like with image editing, the user pops off to their chosen web-based image editor, then returns with the finished image when they click “done”.

Facebook’s “like” button puts their branding on millions of web-pages. Why would they throw this away in favor of unbranded web-intents powered share buttons?

It’s not a one-or-the-other decision. If the Web Intents framework gets adopted, then it would probably be in their interest to make their service available in addition to their like buttons.

If I ran an image hosting website, and my income relied on users ordering prints from me, I certainly wouldn’t want to use a Web Intent that allowed users to swap in a competitor’s service onto my buttons. A feature like that could destroy my business. Do you think some web businesses will be intimidated by Web Intents?

It’s not scary. As a website publisher you would pick and choose which Web Intents buttons to feature on your site. The idea is that you’d pick ones that would provide functionality that is not core to your product and otherwise expensive to build.

Why do you think the Web Intents framework is going to succeed?

The Web intents framework paves over a well trodden path. We already have vast numbers of buttons for sharing between and linking between sites, and these button are the starting point for billions of interaction today. We are simply trying to standardize something that is already there.

How can the UX community get involved?

I think the UX community should take a great interest in the development of up-and-coming features. It’s better to engage early on, rather than waiting for the browser vendors to deploy new features and then deal with any problems. This especially true of Web Intents which will create new types of user journeys which could be a big part of the web.

For the past couple of months I have been working with two designers Danny Hope and Andy Dennis to organise a UX design event on February 25th in Brighton. We are trying a slightly new format that we’ve coined a “design push”. The idea is to take a current technology such as Web Intents and focus a group of UX designers on a day of open collaboration with the aim positively adding to its development and adoption. We have been luck enough to members of both the Chrome and Mozilla teams coming along to partake in the event.

So join in the discussion and get your voice heard.

Why I never use panels provided by remote usability testing services

Harry Brignull — Tue, 17 Jan 2012 18:46:02 +0000

User research. It’s right there in the name. A user is someone who actually uses your service. Equally valid is the idea of a “target user” – someone who doesn’t yet use your service, but has a genuine need that it would fulfil.

User research has to involve these people. Otherwise, by definition, it’s not user research.

When you use a panel provided by remote usability testing service, you end up gathering data from a bunch of freelancers – professional participants who know the kind of things they’re expected to say. At best, they’ll make a real effort to take the tasks seriously and you feedback. At worst, they’re just actors, going through the motions to get paid.

Real user research involves recruiting participants who honestly care about the problem your service is trying to solve. They’ll engage with the information, weigh up their options in difficult decisions, and carefully consider implications. Most importantly, they’ll draw upon their life experiences to weigh up the benefits of your service against their current practices and other competitors.

One of the biggest strengths of remote research is the fact that you can cast your recruitment net far more widely than with face-to-face research. Remote research is well suited to sourcing real users. If you use remote research techniques and then test irrelevant participants, you’re missing the point of it all.

——

Edit 1: This post isn’t intended as a criticism of remote usability testing services per se. Most services offer a predefined panel alongside the option to recruit your own users. I’m advising you to recruit your own, and to take care in doing so – it’s as simple as that.

Edit 2: Nate Bolt has reminded me that ethnio is a good tool for recruiting your own users, including the ability to intercept users live off your own site. I’ve used it a few times, and it gets my vote.

Anatomy of a Hardware Usability Testing Rig

Harry Brignull — Wed, 14 Dec 2011 14:35:19 +0000

These days we all know how easy it is to record usability testing sessions on a desktop computer. You can use Silverback on a Mac ($69.95), Morae on PC ($1,495) or you can try one of the many other screen recording tools on the market today.

If you need to record research footage from a device that doesn’t support software recording (e.g. a Kindle), then you’ll need to point a camera at its screen. This is simple if you don’t want picture-in-picture: you can make a sled like this, mount a webcam on it and record the footage using any free recording app (like Quicktime). If you want picture-in-picture, then it’s a little more complicated but still doable. On a Mac, you can fudge Silverback to record from a second webcam by using an app like macam to display that webcam’s footage on your desktop. If you’re on PC, you can use AmCap ($29) in a similar manner or Morae in its “mobile device study” mode [PDF].

However, specialist UX research agencies often use “Pro” video production hardware for multi-camera recordings. Even though this is far more expensive than software, the results can be better – often giving higher frame rates, better resolution, and less chance of drop-outs when transmitting live footage.

Speccing up your own hardware rig can be an intimidating prospect. Luckily, my friends at Amberlight (a London-based UX research consultancy) have agreed to share the specs of their rig, so you can create your own.

Before I start, I want to preface this little instructable with an important point: the quality of your research is determined by the skills of your team, not by the recording equipment they use. The point of a rig like this is simply to ensure that stakeholders can watch the live session clearly from another room, and so that good quality highlights can be shared. This helps with buy-in and decision-making, but don’t loose any sleep if you can’t afford it.

The first component we have here is an ELMO P30s document camera. You may have seen this sort of thing on lecterns in lecture theatres. It costs about $2000, but with the price tag, you get a good lens, good resolution (1280 x 720) and a high frame rate (30 fps).

Some researchers don’t like document cameras, saying that they cause participants to hold the test devices in an an unnatural fashion, and that they often hold them out of shot or at the wrong angle for the camera. This is true, but document cameras are still useful because they are so general purpose. You can shove anything underneath one start recording straight away.

In the picture below, you can see the next component – an HD DV camera on a tripod, pointed at the participant’s face. This gives you the second video feed for your picture-in-picture output.

Both video feeds are run into an HD Video Mixer (a “TV One C2-6104a”, approx. $4200) shown below.

This video mixer is used to create the picture-in-picture (PiP) composition. It’s important to use an HD mixer so the resolution of your footage doesn’t get reduced at this stage. The audio from two boundary microphones is also mixed together, using an audio mixer (a Focusrite Pro Studio Audio Interface).

Next, we get the picture-in-picture footage output as HDMI, which is fed into an HDMI splitter (pictured below). One feed is sent to a recording device, the other is run into another room in the building for live viewing.

Since HDMI cables are expensive and don’t work well over long distances, the cable is fed into a CAT extender (pictured below), so that the signal is transmitted over a standard ethernet cable.

In the picture below (front right), there is a small HDMI hard disk recorder (an Atomos “Ninja”, approx. $1000). This little thing takes the video input and records it directly to hard drive, no laptop need. Alternatively you can record your footage onto a PC or Mac using an HD Video Capture Card.

Also of note in the Amberlight lab is a couple of femtocell boxes, pictured below. These are mobile network signal extenders, so they ensure good 3G coverage within the lab. To test low connectivity they simply turn these boxes off.

So that’s pretty much it. Huge thanks to Amberlight for being so open and willing to share! If you have any suggestions about better/cheaper/different rigs then please post them in the comments below.

Nick Disabato on Dark Patterns

Harry Brignull — Mon, 31 Oct 2011 11:02:03 +0000

You may have noticed things have gone really quiet on this blog lately – let me reassure you that it is still very much alive. I’ve been taking a short break to focus on some very cool projects at Clearleft, together with fixing up a 150 year-old house in my spare time… and trying to get it all done before the birth of my second daughter. Phew!

Anyway, I’ve just discovered this presentation by Nick Disabato on Dark Patterns which he presented at the Web 2.0 expo in NYC last month. It’s very nicely put together, and contains a whole load of new examples.

Deceptive UX: How To Trick People and What To Do About It

It’s a pity there’s no audio, but you can download a PDF containing the slides with Nick’s speaker notes. Nick is also the author of Cadence and Slang, which Christopher Fahey described as “the book I wanted to write” – high praise indeed.

Flipping pancakes: the value of competitor evaluation

Harry Brignull — Tue, 19 Jul 2011 16:22:36 +0000

A few days ago, a friend of mine told me a story about their first visit to IDEO. At one point in their tour they saw a dozen Design Researchers standing in a makeshift kitchen, each holding a different brand of frying pan, flipping pancakes over and over again. There was one person watching and taking notes on a clipboard.

Sounds bizarre, doesn’t it? Almost like a scene from Kitchen Stories. In actual fact, there was nothing weird going on – they’d simply been hired to do some design consultancy for a frying pan manufacturer, and they were doing a competitor evaluation. Some pan shapes, weights, sizes and materials are simply better suited to the ergonomics of pancake-making than others. By looking at the competitors, they neatly kick-started their knowledge of frying pan design.

Competitor evaluations are hugely beneficial at the beginning of a project, but for some reason they’ve got a bad reputation among many designers who see them as uninspiring and uncreative. Personally, I think this is nonsense. Knowing how a competitor solved a problem shouldn’t determine your solution, and without knowing the landscape of competitor designs you can easy stumble and waste time. Here’s an example: the Mail Online iPad app first-run user journey.

Step 1: when we start the app for the first time, we’re taken straight into a tutorial. What are we learning here? Not much, but there’s something about syncing mentioned there at the end.

Step 2: a detailed explanation on how to sync. They’re clearly concerned about users syncing over 3G and then getting hit with a huge bill – a valid concern, but is it worth this much emphasis?

Step 3: another entire screen dedicated to syncing. That’s some heavy instructions right there.

Step 4: can you believe it? Yet more information on syncing. What’s crazy is that there’s 15 more pages in the this tutorial. Lucky they put in that “skip tutorial” button!

Here’s my point: had the designers of the Mail Online app taken the time to do a quick competitor evaluation, they’ve have have realised that ZERO competitor apps make such a big deal out of syncing, and none of them are getting negative App Store reviews as a result – in fact, quite the opposite is true. Meanwhile, the Mail Online app has ended up with a tedious first-run experience. It pays to know which design patterns work well in your problem space and which ones don’t. Of course you’re never going to get a groundbreaking UX off the back of a competitor evaluation alone, but it’s a good place to start.

In other words – don’t forget to flip those pancakes.

The Swiss Cheese Model of System Accidents

Harry Brignull — Fri, 27 May 2011 10:47:27 +0000

James Reason’s Swiss Cheese Model of System Accidents is quite a useful way to to think about how failures can happen, even when you have multiple layers of “defence” in place. It’s been applied to things like aviation and medical safety, but it’s equally appropriate to apply it to your own design work. We’ve all worked on projects where a number of small unforeseen issues have lined up and created serious problems. James Reason elaborates:

“[T]wo important features of human error tend to be overlooked. First, it is often the best people who make the worst mistakes—error is not the monopoly of an unfortunate few. Second, far from being random, mishaps tend to fall into recurrent patterns. The same set of circumstances can provoke similar errors, regardless of the people involved. The pursuit of greater safety is seriously impeded by an approach that does not seek out and remove the error-provoking properties within the system at large.” – James Reason (2000)

Swiss Cheese Model applied to Air Safety (Astra Project)

What’s nice about this model is that it encourages you to look at the pattern of issues that occurred, rather than to simply ask an individual to “pay more attention next time”. It’s really more of a metaphor than a model, but it’s still useful to keep in mind during your project post-mortem meetings. You are doing project post-mortems, aren’t you?

Clearleft is hiring, come work with us!

Harry Brignull — Tue, 17 May 2011 12:13:35 +0000

We’re hiring a Senior User Experience Designer, which would put you in the same role as James Box, Cennydd Bowles (who is leaving soon) and myself. As a newcomer to the company, I thought it’d be useful for me to share a few thoughts:

Great projects: the first thing I noticed when I started at Clearleft was the way sales work here. We get a fairly large volume of incoming calls from prospects, which allows us to be picky about the work we take on. We also tend not to have overly prescriptive work-plans. Proposals are written to allow flexibility, so you get to choose the right approach for your project. This makes it much more fun.
Professional freedom: there’s no expectation for you to have your bum on the same seat for the exact same hours every day. There’s no macho “who can work the longest hours” nonsense here. You’re trusted to stay on top of your project work without being nannied.
Time to write: if you sometimes feel like writing articles or blog posts at work, you can. In fact, it’s encouraged.
Feisty discussions: Clearlefties often lunch together, share knowledge and chat. Never eat a sandwich alone again.
Team support: if you get stuck on something, all you need to do is turn your neck and ask for an opinion. I’ve noticed everyone here is very willing to drop what they’re doing to help out. My work has improved hugely as a result.
Conferences: have your say and help shape Clearleft’s conference line ups. Choose the conferences you want to go to without having to justify the use of your conference budget. UX is such a sociable industry – at Clearleft you get to fully enjoy this fact.
Training: everyone here loves learning. Since I I started at Clearleft a few months ago, I’ve already had advanced analytics training and I’ve got some improv comedy training lined up (for public speaking).
Healthy lifestyle: everyone here is experienced and knows what kind of life they want to lead. It’s a friendly and calm environment, punctuated by excitement rather than stress. I’ve never seen anyone panic about anything.

Interested? Apply here.

Dave Meslin on designing for intentional exclusion

Harry Brignull — Tue, 03 May 2011 09:37:53 +0000

Here’s a brief excerpt of Dave Meslin’s TEDx talk on The antidote to apathy:

“You ever see one of these before? This is a newspaper ad. It’s a notice of a zoning application change for a new office building so the neighborhood knows what’s happening. As you can see, it’s impossible to read.”

“You need to get halfway down to even find out which address they’re talking about, and then farther down, in tiny 10-point font to find out how to actually get involved. Imagine if the private sector advertised in the same way — if Nike wanted to sell a pair of shoes and put an ad in the paper like that. (Applause) Now that would never happen.”

“You’ll never see an ad like that, because Nike actually wants you to buy their shoes. Whereas the city of Toronto clearly doesn’t want you involved with the planning process, otherwise their ads would look something like this — with all the information basically laid out clearly.

“As long as the city’s putting out notices like this to try to get people engaged, then, of course, people aren’t going to be engaged. But that’s not apathy; that’s intentional exclusion.”

(via Steve Spyrou of Foviance.)

Alan Penn on Shop Floor Plan Design, Ikea, and Dark Patterns.

Harry Brignull — Sun, 10 Apr 2011 10:07:08 +0000

This talk by Professor Alan Penn of the UCL Bartlett School of Architecture is quite brilliant. He reveals loads of resonance between physical shop floorplan design and UI design for ecommerce, plus he explains exactly how Ikea employ Dark Patterns. Here are some excerpts paraphrased from Alan’s talk [notes in square brackets have been added for clarity].

This is the groundfloor of Harrods [above]. One of the best tourist attractions in London.
They came to us with a problem. The problem was that on a saturday, they get double the number of people through the doors as they do on the weekday. And yet they only make 1.6 times as much money. They only get a 60% uprise from a doubling of people.
So they felt they had a problem – which was that the conjestion on the ground floor was so high, that they were stopping getting the passing trade. [...] So we went to study it. we did an analysis of its spatial structure.

We observed how people moved around the whole of the shop floor. It turns out that the relationship between our analysis of spatial structure and the flows of people is a reasonable relationship. You can predict from spatial structure, flows of people around the store. However, what we found was that the flows of people did not relate to the number of transactions. So if you get the point of sale data, what you find is that what relates to the number of transactions was the static people, not the moving people. This was novel. [...] It led us to be able to suggest back to the store managers that the real problem was not that the congestion was stopping people from passing, but that the congestion was inhibiting people from browsing. It actually stopped them stopping. You just had to keep moving because there was such a pressure from the crowd behind you.

Some of our most sophisticated retailers are the supermarkets and the large warehouses. They have wonderful data. You can follow people as they shop. Here, some people who do this kind of zig-zagging all over the place [below left]. This one [below right] is sombeody who shops and does those little forays up and down the aisles…. Quite often people who shop in pairs do this.

And you can do this for lots of people and you get a picture of of the way that shopping takes place. It turns out in these kinds of stores is that what makes money is not necessarily an obvious thing. [...] Things like biscuits are very high in turn over – much cheaper [than wine] – but you make a profit on them. So there is a really interesting question that underlies profit that requires you to unpack exactly where the margins are on every line of goods. You have to look, in the store, at where all those goods are located. [...] It’s all very well if people are passing through but it’s no good if they don’t actually choose something – if they don’t convert into a real sale.”

So here we are, with conversion rates. The red ones are high conversion rates. Fruit, milk, beer coffee, more beer…
In order to study this kind of thing, it makes an enormous amount of sense to compare one store to another store to another store, across a wide range, that are all trying to sell similar things. … And we had an opportunity to do this in a study of a large electronics store.

They gave us a dozen different store layouts, said they were all the same… We said no they’re not, they are all quite different actually! – And they gave us very precise point of sale data on where exactly they make profit on each line. Wonderful data actually.
Across that dozen set of stores, there was a relationshop between three factors that were spatial in the store, and the level of profit that they ended up making. The three factors were intelligibility (how maze-like the layouts were), accessibility, and the size of the visual field. If you close down the size of the visual field on average, and make people feel they are always in a small space, they get less understanding of what’s around them, and that seems to inhibit the profitability of the store layout.

So what’s intelligibility?
[We] look at the local properties of the graph – how many streets cross this one, and how does that relate to where I am in terms of average depth from everywhere else in the graph – that’s a global property. Intelligiblity we define as the correlation between those two – To what extent does what I can see locally give me a good indication of where I am in the large scale plan of the whole thing. You can design things to destroy the relationship between the local and global [i.e. confusing], and you can design them so that the two correlate very closely [i.e. clear].
It’s something, by the way, that we find in a whole range of cities from around the world, organically grown settlements. They regularly create this property of correlating local to global [i.e. organically grown settlements naturally develop intelligible layouts].
Intelligibility is really important in the urban realm and in building interiors because it gives you autonomy. if you don’t know where you are, how can you decide where you want to go to? So… Removal of intelligibility, which is one of the things that architects can do … is like giving somebody a lobotomy. It removes your ability to act with intention.
Now – it’s very important for a space to be intelligible if you want to be able to search for what you want. And that’s all part of shopping. [...] Now, a quote, from in the Susie Steiner in The Guardian in 2005:

“When you’re inside an Ikea store, you must come to terms with a near permanent state of bewilderment: shelves stacked with flat brown boxes labelled with random codes and names; a yellow road which takes you inexplicably through bedrooms when all you wanted was some kitchen handles. And then, then, when your emotional temperature is rising and you can feel a panicky hotness around your ears, you will be faced with Ikea’s version of customer care – an underpaid teenager, trained in psychic disengagement who’ll tell you they’re out of stock. The next delivery won’t be for two weeks. No, you can’t place an order, you’ll have to return to the store. That other query? You’ll have to ask someone in bathrooms … that’s five yards down the yellow road and the queue’s on your left.” – Susie Steiner, 2005.

Let’s try to get to the bottom of what’s going on in Ikea.
I had a Masters student a few years back called Farah Kasim, who went out to study IKEA. She had to draw the plans, then she came back and she analysed them.

Now if you remember, the intelligible city layouts, they tend to have spokes around the hubs of a wheel.
So you’ve got a central area that’s really accessible and there are various ways in and out of the center, and perhaps the rim of the wheel of the outside will be accessibility.
And we look at the showroom part of IKEA [below]… and what you find is… goodness me, it looks like a really well working urban system. So my first feeling is that the computer has gone wrong. [...] this is a complete shock to me.

[...] She followed people around the store – and guess what they do – they walk around like this. You can see the sort of lines of people [below]. In fact, if you shop in Ikea, all you do is follow people around the store. You very seldom find people going the other direction. You do occasionally but they are always looking very harassed.

My colleague Alasdair Turner invented some wonderful software agents that have vision. They can see ahead of them with a field of view. The field of view is constrained by objects in the environment [shown below]. So they sit inside a virtual model, constrained by what they can see. Each time they want to make a step in some direction, they take a step to a point at random [within their field of vision]… As they move relative to objects in the environment, it changes the shape of what they can see next, and so it cycles on.

Let’s do this on the Ikea floor plane. Each of them, every time they step on a floor tile, they make it go redder, and every time a floor tile doesn’t get stepped on for a while, it goes bluer.

You end up with a sort of map of where the computer agents [...] have actually ended up walking. And guess what, it’s very much like the pattern that we see for real people [edit: heatmap of real people vs heatmap of agents]. That tells us something very interesting. There’s a complete distinction between an analysis of space that takes no account of forward facing vision – of the way we are built into our bodies, with eyes in the fronts of our heads and a tendency to walk forward [...] and an analysis that does not have this.
There is a complete disjunction between those two.
What Ikea have done is taken away something which is very fundamental, evolved into us, and they’ve designed an environment that operates quite differently, given that we are forward facing people, embodied [...] from the way it would happen if you just looked down from outer space. Its effect is highly disorienting.
Ikea is highly disorienting and yet there is only one route to follow. [...] Before long, you’ve got a trolley full of stuff that is not the things that you came there for. Something in the order of 60% of purchases at Ikea are not the things that people had on their shopping list when they came in the first place. That’s phenomenal.
So, what’s going on? Unintelligibility and disorientation removes your autonomy. They’ve extended the threshold at the beginning of the store to this whole showroom, and used it to remove your knowing-of-where-you-are. You have to submit. You can only give in and follow the route that they set out for you, because to do anything else is really difficult. In fact, there are shortcuts in Ikea. If you want to go upstairs into the showroom, you can then turn left and go immediately down the stairs into the market place and start shopping. Expert ikea shoppers know this. Part of the reason why they enjoy it is because they consider themselves to have expertise in how to shop it.
I’ll tell you the trick. If you want to know where the shortcut is – turn around, it’s behind you. Literally.

Watch the full video of Alan Penn’s presentation

Observations versus Recommendations

Harry Brignull — Tue, 29 Mar 2011 12:20:29 +0000

I’ve noticed a fair few designers muddle up observations with recommendations when analysing user research findings. This can really screw up your design process, but thankfully it’s quite an easy one to avoid.

It’s important to always state observations separately from your design recommendations, and to try to state them in a pair. Observations are facts like “Participant 3 failed to create an account successfully” or “There’s a 25% drop out rate on step 3 of the wizard”. If you start with these facts, you add structure to the discussion: all the stakeholders can do at this point is acknowledge that there is a problem, or discuss the validity and generalisability of the observation. Once you’ve cleared this hurdle, then you can move onto the fun bit: design recommendations.

One common mistake is to make a blanket statement about user research, followed by a design recommendation e.g. “User research indicated that there were problems with this area, so we should change all the labels as follows…”. This is bad because it’s opaque. What user research? What problems exactly? Without establishing a bedrock of fact, your recommendations cannot be evaluated properly and could lead you into a bad place.

Another common mistake is to suggest the research findings specifically require a certain design change, e.g. “In the usability test 6/8 users failed to notice error feedback in the payment form, so we absolutely must to use red text here”. User research rarely, if ever, necessitates a specific design change – and until you make that change and test the impact, you cannot know how effective it will be. There will always be myriads of design alternatives, and everyone will have their own opinion. Heated discussion may occur at this point, but that’s OK – the solution is to design and test the advocated approaches.

I should add that there’s absolutely nothing wrong with stating your opinion, but it’s important to make it clear that’s what it is. When doing a post-up activity with sticky notes in a workshop, you may want to use the FOG method: mark each note with F (fact), O (opinion) or G (guess). It’s such a simple thing to do, but it adds a great deal of clarity to the decision-making process.

F**K CAPTCHA

Harry Brignull — Fri, 25 Mar 2011 14:08:11 +0000

Using a CAPTCHA is a way of announcing to the world that you’ve got a spam problem, that you don’t know how to deal with it, and that you’ve decided to offload the frustration of the problem onto your user-base. As statements go, that’s pretty lame.

If you ran a high street store, you wouldn’t force your customers to mop the floor before you serve them, on account of the people who came in earlier with muddy boots. That mud is your problem, not theirs. The same goes for spam. reCAPTCHA bothers me the most because it tries to sugar coat users’ frustration and make it palatable to site owners. Helping digitise and preserve literature is a worthy goal, but it’s a task that’s utterly at odds with what your users are trying to do at that very moment.

Sometimes site owners seem to think they really need CAPTCHAs, having been hurt by spam in the past. Without hard evidence, it can be difficult to persuade them otherwise. Well, here’s some good news – I recently got chatting to Chris Korhonen of Animoto, who’s kindly shared some data that could help you talk your clients around.

In case you don’t know, Animoto is a web app that allows users to create video compositions from their photos, video clips and music. According to their press releases, their registered user-base grew from 300k users in August 2009 to 2 million users in November 2010. Roughly speaking, that’s 2,400 new registrations a day – giving them plenty of data to run quantitative research.

In Q1 2009 they ran a simple experiment, looking at the impact of CAPTCHA on registration completion. This is what their signup form looked like at the beginning of the study:

Users were directed to the sign-up form direct from the homepage before they could interact with the product. As you can see, there was a CAPTCHA at the bottom of the form (powered by reCAPTCHA). With this design, they had a conversion rate of roughly 48%. They then removed the CAPTCHA, and it boosted the conversion rate up to 64%. In conversion rate lingo, that’s an uplift of 33.3%! They replaced the CAPTCHA with honeypot fields and timestamp analysis, which has apparently proven to be very effective at preventing spam while being completely invisible to the end user.

To quote Chris:

“We left the test running until the results were statistically significant to a 99% confidence level. We’ve followed the same testing methodology with other bits and pieces – removing demographic fields, moving things around, and so on, but nothing has moved things more than a couple of percent.”

Got any evidence of your own about CAPTCHAs and conversion rates? Comments, please…

————–
Edit #1: For some reason this article has hit the front page of Hacker News and is getting quite a lot of traffic. I should mention that yes, I acknowledge CAPTCHAs are of course sometimes unavoidable. That doesn’t mean, however, that we should ever feel good about using them, nor should we fool ourselves that users don’t mind them.

Edit #2: Links added to articles about honeypot fields and timestamp analysis.

Test your critical thinking skills…

Harry Brignull — Sun, 20 Mar 2011 08:57:59 +0000

Quite a few people in the UX industry have been moaning – myself included – about the demise of critical thinking, and the fact that people don’t question what they read before accepting it as solid fact, particularly if it comes from a well-known source.

So, what about you? Are your critical thinking skills up to scratch?

This press release / research report from Vibrant provides a nice, easy exercise for you. See if you can list the top issues. Suggestions in the comments please.

Pear Note 2: perfect for stakeholder interviews

Harry Brignull — Fri, 11 Mar 2011 17:11:22 +0000

Now, I love Silverback just as much as the next User Experience Professional, but it’s not a Swiss Army Knife – it’s designed to do one thing really well, and that’s recording users’ screens in usability tests. What about situations when you don’t need to record a screen? In stakeholder interviews, for example, the value lies in the conversation and the notes you take, not what’s on screen.

Well, I’ve been trialing Pear Note this week and it’s very neat. Here’s how it works: when you start an interview, you hit the record button and you start typing notes. If you’re like me, your notes are likely to be full of typos, gaps and rough shorthand – nothing like accurate transcript of the interview. The point of Pear Note is that it makes this into a non-issue. Every single character you type is time-stamped and linked to the audio recording.

This means that if you come across a poorly transcribed chunk when you’re reading your notes after the interview, you can simply click on a word and listen to the audio that was recorded at that point. This mixes the best of both worlds – you have text which is great for scan readability, and you have audio, which is great for quotability. (Pear Note records video too if you want it, but you’ll need an external webcam to point at your interviewee).

Here’s the other killer feature. You can publish your notes and audio as html & mp4, straight into a shared dropbox folder. This gives you a nifty web version of the desktop UI, which means anyone in your project team can open up the html page and jump through the audio and notes. Often this wont be necessary, but it’s great to know that you’ve got the assets on-hand in such a readily accessible manner.

Edit: 25% off coupon code now available!
Chad Sellers of Useful Fruit Software has kindly offered 90percentofeverything readers a 25% discount. Enter the coupon code “90percent” on the checkout page to get it for $30.

Black hat copywriting

Harry Brignull — Sun, 06 Feb 2011 10:13:45 +0000

A skilled black hat copywriter can create a page of content that says one thing when read at-speed (i.e. by normal web users) but says another thing entirely when carefully read word-for-word (e.g. from a legal perspective). Small print and footnotes are a classic examples of this. Black hat copywriting basically involves subverting well known UX copywriting guidelines, so readers are deceived rather than informed:

Now let’s look at an example on Creditexpert.co.uk – a site that allows you to check your credit rating in the UK. The homepage mentions the word “free” all over it:

If you click the big orange button, you are taken through a wizard in which the site collects your personal details. Then, you get to a page in which you are asked to enter your credit card details (view screengrab as PDF). It’s fairly likely that when you reach the credit card form, you’ll think to yourself “Huh? I thought this was free, why are they asking for my card details?”. The designers of this page must have expected this, as they headed it off with some explanatory text.

I’m sure you’re familiar with the idea of “honest” inverted pyramid copywriting: you give an accurate summary up-front, then go into progressive layers of detail, so the reader can stop at any time and still have a clear idea of what it’s all about. What we’ve got here is a “black hat” inverted pyramid, which gives a misleading message upfront, then hides the facts lower down. Let’s see it in action here:

The beginning of the message seems to tell you that your card will not be charged and that it’s just an identity verification thing. If you go on to read a bit more, then you’ll be further reassured:

And then if you read a little bit more, you’d be feeling even more reassured:

If you read the whole thing through to the end, you’ll see the real message- that the free trial rolls over into a surprisingly expensive paid plan, which will continue for the rest of your life unless you cancel.

You might argue that this is just grey hat copywriting – and that if it were black hat, they could have taken the final sentence and hidden it in a footnote to bury the key message even further. Maybe so, but their approach is enough to catch a certain number of people out. Just take a look at the Google instant autocomplete suggestions on Google.co.uk if you type the word “creditexpert” followed by a space:

Edit: Malcom Coles has shown that Google Instant suggestions are not a great predictor of scammy-ness. Even so, I’d be wary of simply blaming Google if this happens to you.

To conclude, let’s take a look at some consumer reviews:

“…veering on criminal in their billing methods” – ciao.co.uk
“Two months later, and they are still charging me £6.99 per month.” – ciao.co.uk
“What a useless ****ing service. Who needs to know their credit rating on a monthly weekly daily basis? May be once in a blue moon any more and you have mental problems.” – complaintsboard.com
“I too fell for the ‘FREE’ credit report for myself & my wife. Having requested credit card details ‘to complete the report’ I then find that they have taken 2 x payments of £7.99 from the card without my authority. [...] revenue by small print deception.” – reviewcentre.com
“Me and my wife both used Credit expert’s free service only to find a few months later we were being charged £6.99 a month for a free service we used once” – reviewcentre.com
“Joined in May 2010 and didn’t realise I’d be charged £7.99 per month if I failed to cancel – BECAUSE IT WAS CONCEALED SOMEWHERE OUT OF SIGHT.” – reviewcentre.com
“The expression ‘caveat emptor’ comes to mind. I, too, got ripped off for £5.95 for my “free” subscription since I believed Experian to be a reputable organization.” – complaintsboard.com

So what do you think? Are practices like this ever excusable?

If you were going to design Flattr’s sign-up process, is this how you’d do it?

Harry Brignull — Wed, 19 Jan 2011 17:35:09 +0000

The core idea of Flattr is great. You define a set amount of money each month (say $5) to tip content creators. Then, whenever you see something you like, you click their Flattr button and they get given a slice of your monthly quota. The size of the slice depends on how many people you tip that month – the more you tip, the less each individual gets. The concept is a bit weird at first, but if you think about it, the idea of a single-click micropayment tool is actually quite compelling. There’s no stop-and-think “how much should I give” step. There’s no worrying about hitting or going over your quota. You can click away with reckless abandon, in the same way you’d tweet, like or share content.

It’s somewhat similar to giving coins to a street busker – the exact amount really doesn’t matter to you, but the fact you’re giving something at all can have a big impact in aggregate with everyone else. The potential is huge if Flattr gains critical mass, but they simply haven’t got there yet. They’ve only logged 118k tipped items since they launched in March 2010. So why hasn’t critical mass occurred? If we take a closer look at their sign-up and ramp up process, you’ll see that user experience is clearly an important factor.

Instead of giving you my opinion, I’m going to pose this as a question – if you were going to design Flattr’s sign-up process, is this how you’d do it?

Above we have the Flattr homepage. Note that the main proposition displayed (“Get paid for your work…”) is aimed at publishers, not readers – while readers are likely to vastly outnumber creators (the 1% rule). With this in mind, and looking at the 3-step walkthrough, what do you think they’re doing wrong here?

If the user clicks the “sign up now” button on the homepage, they end up here – a standard looking sign-up form. When the user registers, they are sent an activation email, which they then need to click, and then are taken to a blank login form which they have to fill in. They are then taken to the page below.

Above you can see the interstitial instruction that they are taken to. There’s a lot of information here, which they are meant to consume before proceeding to the dashboard.

Finally the user gets get to the dashboard (above). The wizard has ended, and now the user is free to explore and do whatever they want using the interface. But there are still some highly important actions required. They have to put some cash into the system, and set their monthly quota. In case you’re wondering, the items in the orange box at the top-right of the page are not clickable.

Another issue to be aware of is their lack of a viral strategy right now. If I take the time to register on Flattr, I can then only give money sites that have already been set up for Flattr by the site owners. I can’t, for example, email you a tip via Flattr, and in doing so give you a compelling reason to sign up for the service.

So, there we have it – a brief walkthrough of the Flattr sign-up and ramp-up process. I’ve actually spoken to them and they’ve told me they’re very interested in taking on board feedback from the UX community. Please add your comments below to help shape what could be a great micropayments system.

What’s wrong with a little learning curve?

Harry Brignull — Fri, 14 Jan 2011 07:52:35 +0000

“The first business computer anyone can learn to use overnight.” (1984)

Try to think back to the first time you used a brand-new, ground-breaking, disruptive piece of technology. For me, I’ll never forget sitting in my bedroom in the early 1990s, going through the training application on my brand new Macintosh Classic. It explained how to lift my mouse when it got to the side of the mouse mat and position it back into the centre. It taught me the different functions of single-click and double-click, and how to select icons by clicking and dragging.

It was so new and so different, it didn’t actually feel intuitive to me. I could see that the Macintosh GUI was going to be far easier to learn than DOS, but at the same time there was still a fair amount of work involved. Ultimately, I didn’t care – it promised something so useful that the learning it was trivial in comparison to the benefits I stood to gain.

Now think back to when you got your first iPhone. Admit it – it wasn’t instantly easy to use when you first got it out of the box. Work was involved in setting it up. Sure, it was easy to unlock, flick left and right, start apps, and so on – but actually using it to get work done, that took some learning. Cancelling auto-corrected words. Copying and pasting. Creating bookmarklets in Safari. Entering the Euro or Yen symbol from the keyboard. Learning the work-arounds for having no file manager. They were lots of little mysteries and idiosyncrasies to start off with. Although it feels intuitive now, that’s learned intuitiveness, which, if you think about it, is a strangely wooly concept. Any interface can feel like second nature with the right amount of effort spent learning it.

My point is that disruptive technology is highly likely to be unfamiliar and will therefore have a notable learning curve. This raises some interesting problems for designers. For example, if your product has a painful learning curve, how can you convince people to invest time and effort in overcoming it? Back in 1984, Apple had to let people take home a Macintosh completely free for 24 hours, along with a 16 page instruction booklet (see Macintosh Ad above). Think about that for a moment – imagine designing something that required 24 hours of exposure for end-users to overcome bafflement and “get it”, let alone become a competent user. Web designers these days have it easy in comparison.

When the telephone was invented, Bell Co. tried to sell the patent to the British Post Office but they weren’t interested. The Chief Engineer famously responded “…we have plenty of messenger boys”. Bell then realised, like Apple did 100 years later, that people had to experience real usage of their product in order to “get it”. So Bell developed an aggressive adoption strategy to get telephones into peoples’ hands. They put phones in hotel rooms for calling the front desk, in offices as a replacement to intercoms, and near lunch counters in diners – a brilliant idea that not only got people to use them but also ensured people saw others using them in real life. It’s interesting to consider that today, Apple’s TV ads draw upon the same underlying strategy – the ads are presented like actual product demos. The viewer gets to vicariously experience real usage. The same goes for the hands-on nature of Apple Retail Stores, where anyone can walk in and play with any of the hardware for as long as they want. It’s not an act of kindness, it’s an adoption strategy.

Another problem you might face is knowing whether your product has a noticeable learning curve because it’s ground-breaking or just because it’s badly designed. The good news is that you can approach this with a simple heuristic: if it requires effort to learn, always start by assuming it’s just badly designed and let user research be your guide. Bear in mind, you’ll need to engage in longitudinal research to evaluate it properly. Typical usability testing, MVT and analytics doesn’t cut it because the time-frame is usually too short. You need to look at adoption over a period of weeks or months to get a true picture. Open and closed Betas are easy enough to implement with webapps, but physical products bring a whole different set of challenges.

What’s necessary is that you give your participants enough time to experience the strengths and weaknesses of your product in their own lives, and let them work out for themselves whether the benefits outweigh the costs of learning how to use it.

Local maxima and the perils of data-driven design

Harry Brignull — Thu, 06 Jan 2011 16:39:57 +0000

At UX Week 2010, Facebook Product Designer Adam Mosseri gave a presentation called Data Informed, Not Data Driven. It’s an excellent talk and Adam gave some really good examples demonstrating how data-driven design can take you into “local maximum”, which is essentially a design cul-de-sac caused by a blinkered over-emphasis on Analytics and MVT. In this situation, no matter how many small metrics-driven improvements you make, you’re unlikely to ever make a big creative leap to a substantially better design. Joshua Porter explains Local Maxima really well in his article The Local Maximum on 52weeksofux.com.

Local Maxima diagram by Joshua Porter

With data-driven design you can end up wasting time trying to reach the peak of the hill on the left, when there is actually a huge mountain of improvement over on the right that you’re not even aware of because it involves a radically different design approach. Let’s look at two real life examples from Facebook. Quoting from Adam Mosseri’s UX Week 2010 presentation:

“…we created a team we called the engagement team, which was tasked with understanding engagement and increasing it significantly [...] our first attempt at quantifying engagement was “R.A.W.” – reads and writes. [...] Writes are creations of either objects or connections between objects. And reads are what they sound like: reads of that information.
And so we just decided to treat all writes equal and all reads equal, and start to try to optimize for that. We did this over the past few months, and we ended up with products like comment liking. Comment liking is what it sounds like. [...] [It] allowed you to quickly and easily like a comment. [...] This RAW metric was wildly successful. It produced an 11 percent increase in likes throughout the entire system. [...] But there was a feeling within the team [...] that this really might not be the best thing to optimize for. We sort of got what we asked for. This type of write, the fact that you like the comment, is obviously less valuable than you telling us that you had a baby or that you switched jobs or that you moved companies. So clearly, all writes weren’t created equal, and we started to struggle with this.” – Adam Mosseri

This is a great example of how Facebook started off with a poor KPI, and if they had blindly stuck with it, they would have rapidly found themselves in a local maximum where they were optimising for a pretty line graph rather than for the overall user experience. Comment liking is such a low value write activity that it would have simply been a source of noise, covering up the impact of high value writes elsewhere in the system (i.e. other kinds of content publishing). In other words, the RAW metric was raw by nature as well as by name – it needed splitting down into some meaningful consituents. Back in October 2010 the Facebook engagement team was working on developing new metrics to supersede RAW – but the very fact that they recognised the problem means they were already half-way there. Adam goes onto elaborate:

“As we scale, a division of labor becomes invariably more intense, and you have different people representing different interests. We have a Photos team; we have a growth team; we have an engagement team; we have a News Feed team, etc. And all of these teams optimize in good faith for their own interests. But sometimes these interests can be sort of opposing or distracting from each other, and sometimes you can get lost in the specifics of a decision and sort of miss what we think of as the big picture.” – Adam Mosseri

He then goes on to give an example of how this caused a similar “local maximum” problem in the design of the Facebook homepage. Back in early 2008, the Facebook homepage had all of the primary navigation items on the left-hand side. Importantly, this was how you navigated to applications, which of course are an important source of revenue. Later on in 2008, there was a radical redesign of the homepage and the applications menu went from being an exposed, highly visible list (below left) to a drop-down menu (below right). This resulted in a significant decrease in traffic to applications. They tried a few different tricks to increase usage of applications within this “top navigation” page layout, and some limited improvements were delivered.

So, it turned out the top navigation approach (shown above right) was causing a local maximum, and Facebook had to basically bin that layout and create a completely new design in order to deliver an application usage uplift. The key point here is that the analysis that got them out of this rut was not data-driven. It took a creative leap to conclude that the uplifts they were getting weren’t good enough, and they needed to try something completely different.

“What we were doing here is we were optimizing for a local maximum. Within this framework, there was only so much traffic we could funnel to applications. And what we needed was a structural change. Our premise was off. Our interests were leading us down the wrong path. We didn’t realize it [...] we were optimizing for something locally, and we needed to be somewhat disruptive to sort of get out of it.” – Adam Mosseri

It’s fantastic that Facebook have the guts to share information like this, and let’s hope it continues. I guess there’s a certain level of confidence you get from from having 500 million active users that spend over 700 billion minutes per month using your site.

Some quotes in this article were paraphrased for readability. Read full transcript of quoted items

Classic Interaction Design TV: IDEO Nightline Episode

Harry Brignull — Mon, 03 Jan 2011 18:32:37 +0000

What do you mean, you haven’t seen the classic IDEO shopping cart episode of Nightline? It’s well worth a watch, if only to remind yourself that your research and design skills are not limited to the web…

Can’t see the youtube video above?

Dark Patterns: An Overview For Brand Owners

Harry Brignull — Fri, 17 Dec 2010 19:45:27 +0000

While my first presentation on Dark Patterns was aimed at Designers and Researchers, this one is aimed at Brand Owners and Marketers. There’s some new material here, but if you’ve been involved with the Darkpatterns wiki, it’ll be fairly familiar to you.

Can’t see the embedded slide deck?

If you’re hungry for more, check out http://darkpatterns.org where there are plenty more examples.