90 percent of everything : Usability Blog

Written by Harry Brignull

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.

“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.