Does TfL deliberately profit from user error? | April 15, 2013
Today I got a £20 penalty fine from TfL (Transport for London) because it turned out that I didn’t have enough credit on my Oyster card. I typically use the underground so when this happens you’re stopped at the barriers, giving you clear feedback and preventing you from making a costly error.
However I rarely use the DLR/Overground which is barrier free and have never had a situation where my credits had expired. It turns out when this happens the machine beeps twice rather than once. Unfortunately (for me) I wasn’t aware if this so I simply heard a beep and assume everything was OK and got on my train.
I presume there was also a message on the machine, and if I was to complain would be told that it was my duty to read the display. Of course we all know that the context if use (busy platform, unfamiliar surroundings, contact less payment and rushing for a train) makes glancing at a tiny display unlikely.
Sure this was user error, but a user error that could easily be avoided if the system was designed correctly. For a start it would be very easy to change the tone if the error message from a friendly and encouraging beep to a low toned culturally understandable buzz.
Secondly it would be easy to put the card into debit and allow users to top up on their next trip. This is what many other transit systems around the world do and what I thought the underground did as well.
Sadly TFL make user errors extremely easy and as they profit from this error I suspect there is little incentive to change.
I’ve experienced similar issues when booking rail tickets at train station kiosks. They always seem to present the most expensive ticket first (one way peak fare to London) rather than the most popular fare, presumably in the hope that a percentage of people will succumb to human error in their rush to buy a ticket and end up spending more money.
In most customer facing jobs, when user error happens you only need to look towards a friendly customer service representative to get the issue resolved. Sadly with TFL it seems there is an immediate assumption of fare evasion so rather than assistance you get slapped with a fine.
Even this would be OK if the treatment you received was friendly and apologetic. But in my experience its usually the opposite - cold, rude and unsympathetic. So what started as a small and easy to dismiss error ends up leaving you angry at an institution you spend hundreds if not thousands of pounds with, while casting a shadow over the rest of your day.
Privatisation (the legacy of Margaret Thatcher) was supposed to give us consumers better customer service and more choice, it instead it feels like we’ve inherited the worst of capitalism (profiteering) and the worst of state control (poor customer service) instead.
UX Developer is a misleading and potentially damaging job title | January 27, 2012
I was really disappointed to see a recent post from somebody I admire and respect defend the validity of the new UX Developer job title that has been cropping up of late. As well as being misleading, the title, UX Developer has implications that are damaging to the field of User Experience and will hasten the current devaluation of the term.
Despite what many newcomers to the industry may think, User Experience Design is a well-defined specialism as distinct from visual or interface design. The practice of user experience design is a specific field of study with its own books, conferences, membership organisations and college courses. User experience designers therefore have a distinct set of skills and practices that form the core of their profession.
That being said, user experience designers don’t own these practices any more than developers own the ability to code up wireframes. So it’s right that designers and developers look to understand more about user experience as it is for UX designers to want to understand more about the technology that drives their products or the designs that bring them to life. This is one of the aspects of being a professional; the desire to develop your core skills while understanding where your domain overlaps with others.
When I look at new job titles my first question is to ask what new or specific activities form the core of that discipline and make it distinct from other fields. Is this indeed a brand new field of practice or simply a catchy name for a set of composite skills? So when I first heard the term UX Developer I was intrigued. What new skills or techniques are these practitioners using that are specific to the technological side of the equation, and is there anything here I can use?
With eager anticipation I grilled every self styled UX Developer I met to find out what new skills or techniques they had developed. However the more people I asked the more disillusioned I became. Rather than being a new discipline, it became clear that UX Developers were simply developers interested in UX. So developers who wanted to get involved with the initial research, attend (or even set up) usability tests, build HTML/CSS prototypes, consider user needs when coding up pages and put pressure on designers and managers when these needs fail to be address.
I’ve been working with people like this for years. They’re called “good developers.”
There seems as little need for the title UX Developer as there is for the term UX Product Manager, UX Programmer or UX Database Engineer. Similarly, if you’re happy for Developers that do some UX activities to invent a new title, what should a UX person who does a bit of front end or back end development call himself or herself? How about front end UX designer, or creative UX technologist? That has a nice ring about it and isn’t confusing at all.
The sad truth is that UX has stopped referring to the quality attribute of a product or a set of specific skills and activities, and has become a value judgement. For some reason people think that the term UX means “better”, “more valuable” or “more important”. So by adding UX to your business or job title it somehow sets you apart as a better designer, a better developer or a better agency. That, or at least one that can charge more money. This is obviously nonsense and disrespectful to all the talented designers and developers out there. So when I see people adding the term UX to an otherwise perfectly descriptive job title, it makes me view them with a healthy dose of scepticism.
[Andy Budd spent 5 years as a designer and front end developer before transitioning to a dedicated UX designer; a role that he has had for over 8 years. During this transition period he would never have dreamed of calling himself a UX Developer. He hopes other developers feel the same way.]
The Tyranny of the Minimum Viable Product | December 22, 2011
I first came across the term Minimum Viable Product when I dropped into a talk by Eric Reis at the Web 2.0 Expo in New Year a few year’s back. As a company that has always worked on variable scope projects, defining a MVP seemed like a great way of managing client expectations. Rather than clients worrying whether your team would deliver something useful, you’d work together to define the smallest thing you could release and it still be a success. You would then guarantee that the client would meet their core business needs, and everything else you manage to deliver in that time was a bonus.
MVP also appeared to be a great way to manage the inevitable project scope creep. When new requests appeared you could discuss whether they were part of the minimum viable product. If they were, you would update your planing and budget accordingly. If they weren’t, you would add them to a suitable point in your backlog and see whether you got round to implementing them or not.
In the continuous world of the start-up, this approach works well. Your MVP is just the starting point, and once that’s deployed you’ll continue to add new features and iterate as needed. MVP is about breaking something down to a manageable size and getting it to market quickly.
In the more periodic world of traditional businesses, this typically isn’t the case. Rather than working on a product continuously, things get broken down into bursts of activity known as “projects”. With numerous different products, it’s not uncommon for there to be long gaps of time between work on a single product, sometimes several years. As such, in a traditional business setting it’s all too common for the MVP to become the P. At least for a significant length of time.
So in the traditional business setting, when a feature gets pushed out of the MVP and into large backlog or future release, we’re actually witnessing a slight of hand. We’re saying that we realise the importance of this feature to the project and commit to implementing it at some stage in the future, while at the same time secretly knowing that it’ll probably never get built. Sometimes this process isn’t a conscious thing, but all too often it is. All too often I see the backlogs, MVPs and future iterations used as a deliberate attempt to ditch functionality that the design or development team don’t like, don’t want or feel is going to take too much of their time. It’s a way of saying no without actually having to say no.
In the start-up environment, it’s not as important to get the M and the V part of MVP right, as you’ll probably start adding new features as soon as it’s deployed. However in a world where MVP=P, getting the M and the V wrong can be disastrous.
As user experience designers we talk to users, talk to the business stakeholders, review competitors and build up models of behaviour in order to determine what a system needs to do to be a success. However it’s really difficult to pin down exactly why some people will use one product and not another. For new products it often comes down to functionality. However in more mature markets, quality and user experience are key. As such, it’s really difficult to put your finger on what minimum viable means, but it’s typically not something than can be easily expressed on a story card or as part of an acceptance test.
In the rush to deliver a minimum viable set of features (the threshold elements in the Kano model) we often ignore the elements that make the product really great (the exciters and delighters in the Kano model). As quality gets stripped back in preference for functionality, we slowly see our products become ever more minimal and ever less viable. It’s very rarely one thing that does it. Instead MVP often turns into death by a thousand paper cuts.
It takes a dedicated team with a strong vision to avoid this. Sadly in agency land, it’s all to common for the business interests of the agency or the personal interests of the team to come before the shared interests of the product.
I’m not necessarily proposing a better way. Just that we need to be conscious of the subtle effects our chosen methodology and business environment can have on a product.
My thoughts on Lean UX | October 14, 2011
I first came across the concept of the Lean Start-up® three years ago while speaking at the Web 2.0 Summit in New York. I’d finished my duties and there was little else of interest on the schedule so I dropped into a panel discussion about start-ups.
One of the panellists—a chap called Eric Reis—explained how he’d been involved in two start-ups. One had been a catastrophic failure while the other a moderate success. As Eric began to recount his story I found myself nodding along with recognition and agreement.
His previous start-up had taken too long to build and by the time it was ready they’d almost run out of money. Furthermore, once they launched, the shear volume of features obscured the products true value and made it almost impossible to use.
Eric then talked about his new start-up and the realisation that he needed to understand his users and validate the product early on. Eric discussed fast iterations and his concept of a Minimum Viable Product—the smallest thing you could create to prove the business had legs. This reminded me of 37 Signals’ call to “create half a product, not a half assed product”. It also reminded me of what my friends as Doppler had done by tying together existing services to prove their social network for regular travellers could work.
As I sat listening to Eric I thought to myself, “here’s a guy who really gets user experience design” and thought it was great to see somebody from the start-up world echo what we’ve been saying in the design world for years.
Jump forward 18 months and Eric Reis has become the poster boy for the Lean Start-up® movement, lauded by business magazines like Fast Company and the Harvard Business Review. While I was grateful that these ideas were gaining wider circulation, something started bugging me. Wasn’t the Lean Start-up® simply a case of the Emperor’s New Clothes? A combination of User Experience Design and Agile development rebranded and repackaged for a new market.
Also, what the hell was that ® about?
As somebody who believes in the free sharing of information, the idea of claiming ownership of a concept like Lean Start-up® seems really weird; like Jeffrey Zeldman registering “Web Standards” or Ethan Marcotte registering “Responsive Design”. The only reason for doing this, I surmised, was a desire to own the concept and thereby profit from it. That’s absolutely fine, I thought to myself, but I didn’t want to promote something that claimed to be a movement but was clearly one person’s brand. So I decided to keep a respectful distance from the Lean Start-up® community and carry on about my business. That is until the term Lean UX started to appear on my RADAR.
If Lean Start-up® felt like the Emperors New Clothes, then Lean UX felt doubly so.
Proponents of Lean UX talked about guerrilla research, low-fidelity sketching and rapid prototyping like they were new concepts. They discussed the need for close integration with developers and the idea of “design as facilitation” like the agile movement never happened. It was as if something was being excavated and held aloft as new; something scholars had known about for years. It also felt to me like a cynical attempt by a few people to jump on a bandwagon, stake a claim to a new brand name and make money by peddling the latest hip religion. And it annoyed me.
I attempted to ignore the Lean UX “brand” in the hope that it would fizzle out, but sadly it didn’t. Instead it seemed to grow stronger. In fact it got to the point where I started to question my own opinions and see whether I’d somehow missed some vital piece of the jigsaw. Truth be told, I think I had. I just wasn’t the piece of the jigsaw I was looking for.
You see, I think I developed an immediate dislike of the Lean UX brand because it’s something I felt the UX industry was already doing. However the more I looked at traditional UX agencies the more I realised that this wasn’t the case. Instead of doing quick bursts of user research they were running month long engagements; rather than doing café testing on half a dozen people they were lab testing a hundred, and rather then sketching interfaces out on paper and prototyping them in HTML/CSS, they were generating reams and reams of formal documentation.
Over the last few weeks a grim realisation has started to dawn on me and it’s something I’m not especially happy about. I think the reason I hate the Lean UX label so much is because Clearleft is a Lean UX company. That’s why Lean UX has always felt superfluous to me; because it doesn’t describe anything new, interesting or novel; just business as usual.
I’m not sure I’ll ever be comfortable using the term Lean UX. Especially as it implies all other forms of UX are bloated and full of fat. Also, by its nature Lean UX isn’t a different flavour of UX, just a subset. As such, some projects are fine with a guerrilla approach while others require more formality. So flexibility is key.
Anyway, if feels good to get that off my chest. I guess like so many things in life the first step to recovery is realising you have a problem. So here goes…
Hello, my name is Andy and I run a company that does Lean UX.
Window on the World | August 1, 2011
A nice visualisation of a near future car journey from Toyota.
Visual Designers Are Just As Important As UX Designers | July 19, 2011
As I explained in my previous post, user experience design is a multidisciplinary activity which includes psychology, user research, information architecture, interaction design, graphic design and a host of other disciplines. Due to the complexity of the field a user experience team will typically be made up of individuals with a range of different specialisms.
On larger teams you’ll find people who focus on one specific area, such as user research or information architecture. You may even find people who specialise in specific activities such as usability testing or wireframing. This level of specialism isn’t possible in smaller teams, so practitioners tend to group related activities together.
Conceptually I believe you can break design into tangible and abstract activities. Tangible design typically draws on the artistic skills of the designer and results in some kind of visually pleasing artefact. This is what most people imagine when they think of design and it covers graphic design, typography and visual identity.
However there is also a more abstract type of design which concerns itself with structure and function over form. The output from this type of design tends to be more conceptual in nature; wireframes, site-maps and the like. One type of design isn’t any more valuable or important than another, they’re just different.
When products and teams reach a certain size or level of complexity, one person can’t undertake all these roles. When this happens, natural divisions occur. So in small to mid sized teams it’s quite common to describe people who specialise in tangible design as visual designers, while those who focus on more abstract activities are known as user experience designers.
Now we all know that visual design is an undeniable part of the way people experience a product or service, so it may feel a little odd that user experience designers don’t actually design the entire experience. It may also be confusing that when user experience designers talk about “the UX” of a product, they are often referring to the more abstract essence of the product as described through wireframes, site maps and the like.
This ambiguity can lead many visual designers to misunderstand what user experience design is, especially if they’ve never worked alongside a dedicated user experience designer. This has also led a lot of visual designers to mistakenly believe that because the work they create results in some kind of user experience, that makes them a user experience designer. While this may be true in the purely philosophical sense, this isn’t what people mean when they talk about user experience designers (try applying for a senior UX position without understanding user research, IA and Interaction design and see how far you get).
The term user experience architect was coined in 1990 but the roots reach back to the 1940s and the fields of human factors and ergonomics. We’ve had dedicated user experience consultancies for the last 10 years, and internal divisions before that. We’ve got numerous professional conferences attended by people who have been working in UX for much of their professional life. In short, User experience design is a distinct and well understood discipline that stretches back many years and isn’t simply a new buzzword to describe “the right way to design”.
Over the last 12 months I’ve come across far too many visual designers describing themselves as user experience designers because they don’t fully understand the term. Instead they’ve seen a few articles that explain how UX is the new black and decided to rebrand themselves.
I’ve also come across many fantastic visual designers who feel pressured into becoming user experience designers because they think this is the only way to progress their careers. It seems that due to a lack of supply, user experience design has somehow come to represent a higher order of design, or design done right. At best this is nonsense and at worst this is actually damaging to peoples careers.
So here’s the truth. Good visual designers are just as hard to find as good user experience designers. They have exactly the same status in the industry and earn pretty much the same rates. So you don’t need to became a user experience designer in order to take your career to the next level. Instead, surround yourself with experts, hone your skills and take pride in your work. With so few good designers out there, don’t go throwing away much prized and hard earned skills under the mistaken belief that you must become a UX designer in order to grow, as that’s just not the case.
What’s in a name: The duality of user experience | July 6, 2011
As somebody who has publically stated that they “don’t care about user experience” and is fed up of “defining the dammed thing” I find myself being drawn into discussions about the term far more often than I’d like.
Some designers think that user experience is just a made up name and that we’re all user experience designers really. Others think that User Experience is a term used by consultants to trick clients out of money and would prefer it we all just stuck to the title of web designer. Some feel that user experience is simply common sense design while others see it as a land grab to own the fun bit of the design process. This is all complete nonsense of course, which is why I keep getting drawn into an argument I don’t really want to have and one that isn’t especially beneficial to the industry.
It’s obviously nonsense to argue that the field of UX design doesn’t exist as there are hundreds of books and conferences devoted to the practice, tens (if not hundreds) of thousands of people with UX in their job title and an unfathomable number of blog posts about the subject.
I think one of the big problems is that user experience isn’t one thing; it’s several. On a basic level every item that has been designed creates an experience through use. So some people naturally assume that every act of design is in fact an act of user experience design. After all, if all design results in an experience, aren’t all designers’ user experience designers?
The answer of course is no. It’s entirely possible to design something without thinking about how it’ll be experienced. In fact I believe this is still the way most things are designed. Bad experiences are rarely the deliberate choice of the designer. Instead they are usually the unfortunate outcome of an ill-considered process.
So does this mean that to be a user experience designer all you need to do is think about the outcome? Well in the broadest sense of the term, possibly; but in the sense that it’s used by most web professionals, definitely not.
You see, as well as being a measure of the quality of an interaction, user experience design is also a field of practice. Or more specifically an umbrella term that covers several fields of practice including Information Architecture, Interaction Design, Usability, Interface Design, Information Design and several more I’m probably forgetting. All of these practices go into designing good user experiences, so are part of the user experience cannon.
As all of these are effectively aspects of good web design, I can see why experienced practitioners who have gained mastery over many of these fields no longer see the distinction or think it’s necessary. So for them, web design (or simply design) makes sense as a title. I understand this point of view and agree with it to an extent.
However there is a danger here that relates to the popular notion of the web designer and something called the Dunning-Kruger effect.
The popular notion of a web designer is that of a graphic designer— possibly with some technical skills—whose sole focus is designing the look and feel of a website. During the early days of the web this was very much the norm. Sites weren’t especially complicated and many of these advanced skills were yet to have been adopted or even invented.
Today, the vast majority of websites are still designed and built by talented generalists, and there’s absolutely nothing wrong with that. It’s just that some of the larger and more complex sites do require composite teams of specialists with a singular focus. Experts in information categorisation, human computer interaction or interface design. They also need people who specialise in specific programming languages, databases, security, or application architecture. The history of all human progress can be counted by the increased specialisation of individuals amongst a group, and I see this as a good thing.
So we have this strange dichotomy that the term webdesign can be used to describe both a novice and an expert, a neophyte and a master. This is where the Dunning-Kruger effect comes in. If you’re not familiar with this concept it’s the observation that novices suffer from the illusion of superiority and tend to rate their skills much higher than experts because they don’t fully understand the breadth of the field they need to master. Or to use a much quoted aphorism, “they know what they know, but they don’t know what they don’t know”. By comparison, experts tend to know more, but are also more conscious about what they don’t know, hence making them less sure about their expertise.
I’m currently seeing this all the time when it comes to designers discovering User Experience for the first time. Many designers have started calling themselves user experience designers because they have discovered usability testing and wireframing. However these skills are simply the tip of the iceberg and do not a user experience designer make. Because of this I think it’s important for experts to hold mastery of complex skills aloft, rather than convince people that we’re all effectively doing the same thing, when many of us clearly are not. So it’s useful for us to separate skill sets and be able to tell people that what they are doing isn’t in fact user experience design, at least not yet.
Being able to define yourself and differentiate yourself is useful in other areas like recruitment and sales. For instance if you recruit for a Web Designer rather than a Senior User Experience Designer you will end up with a very different class of applicant with a very different range of skills.
Like all job titles, they are much more useful for people progressing through their careers than they are for people who have already reached the pinnacle. So just because you no longer see a need for a job title doesn’t mean that the others don’t or that the title or practice no longer exists and we’re all just interconnected balls of design energy. Sometimes hanging out a shingle is the only way to separate yourself from the person down the road selling inferior goods.
How to break into User Experience Design | June 10, 2011
One of the most common things I’m asked is how people can break into the field of user experience design.
I’d love to be able to give a simple answer—like studying a particular course at University or starting as a UX apprentice and working your way up a series of clearly defined roles—but sadly that’s not the case.
There are Masters degrees out there, but the good ones are few and far between. With current courses failing to meet demand, there’s no way the education system will be able to cope in the next two to three years once User Experience practice has becomes the norm.
Even if you’re lucky enough to attend a good course, unless you had some level of prior experience, you’ll find it hard landing that first job. You see, User Experience is no different from the rest of our industry. There are few large companies willing to train people up so most employers need people with at least a couple of years experience in their chosen field, and preferably more.
For designers and developers it’s easy to gain experience though personal projects. This is why most of my peers came to prominence through their blogs, portfolio sites and side projects. They were blank canvases on which they could try out new skills and lean the tools of their trade. These day’s people are doing the same thing, but with start-ups and iPhone apps instead.
It’s easy for designers and developers to take on solo projects, but it’s much more difficult for budding user experience designers. After all I can’t imagine many UX Designers sitting around in the evening running usability tests, doing card sorts or designing complex sign-up processes just for the fun of it. By it’s nature, user experience design is a specialisation and one that forms part of a bigger process and a larger team.
The most successful user experience designers tend to come from a graphic design or front-end development background. As they’re already working on the parts of the project that come in contact with the user, it’s natural for some of them to be more in tune with UX problems. If they happen to work for a company without a dedicated UX person, it’ll often be left to them to solve.
That’s exactly the situation I found myself in. I worked for a company where I was the main designer and front-end developer. With nobody else to worry about the user I found myself running usability testing sessions, setting up card sorts, working out site maps and designing wireframes. The more UX work I did the less visual design and front end development I did, until one day I found myself doing User Experience design full time.
So if you are working for a small agency on in-house team and don’t have a UX person on staff, one way to break into the industry is to take these responsibilities on yourself push your company forward. As your company grows in its maturity, you will too.
Bizarrely it’s a lot more difficult to become a user experience designer in a company that already gets UX and has dedicated staff. That’s simply because the opportunities to dabble are much less. In those situations it’s worth letting your employers and colleagues know that you’re interested in moving into that field and offer to help out as much as possible. That could be helping to moderate usability testing sessions or helping your UX team design deliverables or prototype ideas.
If the day job doesn’t provide the opportunity to flex your UX muscles then you’re going to need to build your experience and portfolio through other means. One idea is to have a pet project. This is a little more difficult of you don’t have any back end skills, so it may be sensible to find a friendly developer to partner up with. Another idea could be to offer your services to one of the many ugly, badly conceived but nevertheless worthy open source projects out there. Lastly, I’d recommend going along to a hack day, Design Jam or Dev Fort style event. It will take time to get the requisite experience, but it may be the only way.
One of the most difficult problems is taking the leap and redefining yourself as a user experience person. Often your existing company won’t see you in that light, especially if they’ve always known you as a graphic designer or front-end developer. However until you’ve a couple of years of dedicated experience, you’ll find it very difficult picking up full time work.
If you’re young enough the best way to redefine yourself is to walk into the wilderness and simply call yourself a freelance user experience designer. You’ll find it difficult picking up work at first, but as you get better, more will come. Go to as many UX conferences and community events as you can. The sooner other people in the community start thinking of you as a user experience designer, the sooner you can start feeling like one yourself. There is a certain amount of re-invention going on here, but that’s going to be the only way for some people.
Of course you could think about doing a masters degree in some HCI related subject. Sadly most of the courses are 10 years out of date, so it’s less about what you’ll learn and more about the opportunities that will arise from the course. So take every opportunity to do practical work and fill out your portfolio. A year long Masters with a couple of obscure essays and a final project on machine learning won’t help you as much as a dissertation on sign-up techniques and 4 or 5 relevant side projects. It still won’t guarantee you a job, but it will probably put you a couple of years a head of where you would have been otherwise.
Sadly, until universities wake up to the need for modern courses in interaction design, until large companies and agencies set up dedicated training programs and until user experience becomes the de facto standard for web design, it’s going to be tough making the jump. But with demand for good people growing, and showing no sign of letting up, if you are interested in making the leap I’d encourage you to do so.
I don't care about User Experience | May 31, 2011
A few months ago I tweeted that we no longer needed to sell User Experience and our job was now to focus on delivering good user experiences. A few people asked me to expand on my thinking, so this quick post is in reference to that.
I’ve been running a User Experience Agency now for nearly six years. When we started almost nobody I spoke to had heard of the term user experience, let alone understood what a user experience consultancy did. There were a handful of agencies offering “UX services” in the UK, but most were really usability companies. As such we rarely, if ever, came up against other agencies offering a similar service to our own. So I spent the first 3-4 years at Clearleft explaining to everybody who would listen what User Experience was and why it mattered. I had to justify why we could’t jump straight into design and why we needed to spend weeks planning out the user interface. After all, no other agencies wanted to waste time doing “wireframing”, so could’t we just skip that part.
It was both exciting and frustrating in equal measure. Exciting, when I saw the lightbulbs go on over people’s heads, as I explained how many of the problems they faced could be mitigated with some basic research and planning. Frustrating when I could’t change people’s outlook though the logic of my arguments and strength of will alone. I suspect many of you have shared this frustration with me on more than one occasion. As such I have to thank many of our earlier clients for taking an approach which was both new and somewhat alien to them.
Over the last 2 years I’ve seen a dramatic change in the marketplace. First off, people now “get” what user experience is. And I don’t just mean designers and developers. I can’t remember the last time I had to explain to a potential client what user experience was and why it differed to others peoples approach. These days pretty much all of our prospective clients understand what user experience is and appreciate its importance.
The early part of this transition actually took me by surprise, as I’d find myself launching into my “UX is like Architecture” spiel without realising the person on the end of the phone already got it. These days, most of my time is spent explaining the nuances of our approach to UX and how it differs, often in incredibly subtle ways, to the competition. At times I miss being the “Only UX in the Village”. In retrospect that point of differentiation was actually quite easy, and helped define our character as an agency. However that no longer matters anymore.
These days we’ve stopped selling UX and started simply doing it.
Sure, some agencies or individuals haven’t quite reached that inflexion point yet, but I can tell you that it’s on the way. Demand is far outstripping supply, so if you’re not there yet, you soon will be. User Experience is no longer a point of difference, it’s just the way all good websites are built these days.
As such I’m bought to mind Jeff Veen’s comments when he said “I don’t care about accessibility.” Similarly I’m starting to care less and less about User Experience, not because it isn’t important, but because it’s the natural output of the way all good design and development agencies work and think.
Of course there are still challenges ahead, but I think the challenges are related to craft and mastery rather than evangelism. I’d be interested to know what you think?
Stop trying to design experiences and start designing products | March 21, 2011
The architect Frank Lloyd Wright famously told a customer to move their table when they complained that water was leaking from the ceiling when they ate dinner. This is almost certainly apocryphal but hints at the ego of the experience designer. Well tell our users and customers what experience they are going to have (sometimes based on research) but they have to live with the results.
In an agency centric world which I come from, designers are used like Cruise missiles. The target is acquired and we fire and forget. Rarely if ever do we get the opportunity to cycle back to see if the target turned out to be a hospital rather than a barracks. We also don’t get the opportunity to pick through the rubble. Agency design is therefor a blunt weapon and a weapon of force.
Over the years I’m becoming more and more convinced that we’re doing things wrong. That our values around interaction and interface design are skewed. That we’re constantly trying to create the platonic ideal of a chair rather than trying to design a comfortable seating experience.
Why is it that ugly websites can prosper while beautifully designed experiences lack use? Are we focussing on the wrong part of the value chain? Maybe it’s an issue of content strategy? As Karen McGrain says, maybe we’re spending our time designing the paths between a garbage tip, rather than sorting out the garbage itself. Maybe we’re the architects designing a new museum with no thought to the artefacts which will lie within?
I hear many designer bemoan the use of statistics, citing that it somehow takes their creativity away. This can be true if taken to an extreme. After all none of us want to work in an environment where every design decision gets second guessed and tested. However there needs to be balance.
Designing a perfect digital product involves a certain level of faith and artistry. However it’s not an artistic pursuit. Instead I see design more like the unravelling of a mystery. You need to have some hunches and show some big leaps of faith based on prior experience. However it’s not about the individuals skill. Good designers can, and often do, make bad products. Conversely, technically bad designers have been behind some of the most successful web sites out there.
One thing I think we need to do as an industry is to stop focussing on the big, one off products and focus on long lasting customer engagements. However we can’t do that without the help of our clients. Instead of fire and forget, we need to launch our design offensive and then constantly course correct along the way. This involves checking the success of our sites through sales and analytics, coming up with hypothesise about what isn’t working and what can be improved, and then tweaking as we go. Sometimes these changes can be intellectual, while at other times they have to be behavioural. I don’t know which headline or button copy is going to be most effective. I can guess, but my first guess probably isn’t going to be right. So don’t design around your own ego and take nothing on face value. Design, measure, iterate and test should be our new mantra.
Why I think Ryan Carson doesn't believe in UX Professionals, and why I do | September 5, 2010
In a fantastically timed bit of linkbait, Ryan Carson called bullshit on the title of “UX Professional” while attending the dConstruct conference we organise in Brighton. At the conference we announced that we were hiring a Senior User Experience Designer so it would be easy to put two and two together and assume that he was calling us out. However I actually understand where he’s coming from. I don’t agree with him mind, but I do understand.
Back in the early days of the web you just had web designers. These multi-disciplined individuals would design the pages, code up the table based layouts, set up the database and program the CMS. They were able to do all these jobs because the field of knowledge back then was fairly limited and hence the outputs were fairly basic. You could also argue that websites were basic precisely because they were designed and built by a single person, but that’s probably for another article.
As the field of knowledge grew and sites got bigger and more complex, distinct roles started to emerge. First the roles split into designer and developer. Then as sites demanded more off their back-ends you’d have database architects, systems administrators, systems architects and a whole slew of sub roles. Similarly on the front end you would find people who specialised in interface design, front end development, motion design and, more recently, user experience design.
Now user experience design is an interesting one as it’s both a series of activities (research, information architecture, interaction design etc.) as well as a job title in it’s own right. For smaller projects it’s perfectly feasible for a single person to plan the architecture, sketch the wireframes, design the interface and even code up the pages; just in the same way that it would be perfectly feasible for a single builder to plan and build an extension to your house. However as a project becomes more complicated you need more people with deeper expertise. So just as large building projects require quantity surveyors, draftsmen, architects, interior designers, wayfinding designers and a whole host of other experts, so do websites.
I think the reason Ryan thinks that “‘UX professional’ is a bullshit job title” designed to “over-charge naive clients” is because he’s never actually been in the position to need one. If you look at Ryans’ background, he worked for agencies in the late nineties and early noughties when the field of user experience was still in it’s infancy. As such I suspect that he’s never worked with a team of dedicated UX people.
In more recent years Ryan has become a conference organiser and content publisher, producing relatively straightforward websites which really don’t need a dedicated UX person. He’s also dabbled as a start-up entrepreneur, although sadly none have been a huge commercial success as of yet. In fact, Ryan is very much embedded in the bootstrapped start-up culture where all you need is a smart designer and developer to see your ideas come to life. So in early stage start-ups where you’re designing for people like yourselves, you can definitely get away without a dedicated UX person if you’ve got a talented team with enough overlap. However once the project grows, you’ll probably benefit from the help of a dedicated UX professional.
10 years ago I thought much the same way as Ryan. I couldn’t understand how companies could spend millions on a website when a designer and developer could knock something together in a weekend. Similarly why would anybody need a pretentious title like Information Architect when I’m perfectly capable of putting together the site map for the brochureware site I was working on myself?
Of course I quickly learned how naive I was being. There’s a huge difference between knocking together the site-map for a piece of brochureware and developing a complete ontology, taxonomy and controlled vocabulary for a site with hundreds of thousands of data-points. Similarly there a big difference spending a couple of days working out wireframes in balsamiq for that shopify project you’re working on and spending months prototyping and testing a complex application with hundreds of interactions.
Sadly I do think Ryan has accidentally hit on something here, and it’s a trend I’m seeing more and more of; web designers with an interest in user experience re-branding themselves as UX professionals. So there are an increasing number of people out there who are calling themselves UX designers because they’ve sketched out some wireframes and sat in on a couple of usability tests.
By contrast a typical UX person will have a much deeper understanding of cognitive psychology, human computer interaction and design research than their graphically focused colleagues. They will have more experience running stake-holder interviews, usability evaluations and ethnographic studies. They will be more versed in the creation of personas, concept models, scenarios, user-flows and storyboards. They will be able to create wireframes and experience prototypes using a wide range of tools and to differing levels of fidelity depending on the questions being asked and the intended audience. In fact there are a whole host of skills that differentiate a UX designer from a more general web designer. So if this sounds like you why don’t you check out our job for a user experience designer at Clearleft
As far as Ryan is concerned, I suspect he isn’t as naive as he sounds. After all, he’s been in the industry for a long time and even ran an online UX conference a few months back which Clearleft spoke at. So I can’t believe Ryan would put something on he didn’t believe in just for the money. If he did, that would show a real contempt for his customers. Instead I suspect it’s just a way to stir up controversy and drive traffic to his site. However if Ryan really believes there’s no difference between a web designer and a user experience designer I’m sure we can supply him a big list of books to read and conferences to attend in order to change his mind.
So I suggest that the UX community bear in mind where Ryan’s coming from and realise that for some people UX is just a quality attribute or set of activities. After all, not everybody on the web is building the kind of large scale projects that benefit from a dedicated UX resource. Sometimes a UX savvy web designer is just enough.
The best products sell them selves | January 27, 2010
The concept of ‘Pull Marketing’ is all the rage at the moment. In the age of the Mad Men, selling a new product was easy. You’d be handed a commodity product like toothpaste or washing powder and set about building a brand to set it apart from the competition. You would then buy advertising space on a small number of influential marketing channels and wait for the sales to roll in. The growth of multi-channel TV, the commercialisation of radio and the rise of desktop publishing in the 80s fragmented audiences, making it hard to get the message out. However it was the appearance of the Internet that changed marketing for ever.
Attention splintered across thousands of channels and billions of website as web-savvy shoppers began to compare products online and shop in the long tail. In a world where company owners no longer had control over the way their products were presented, power went back to the consumer.
At present only the Super Bowl advertising resembles the marketing to the old days (the ability to get in front of an enormous audience at once) and marketers have been looking to employ alternative tactics to push users towards their sites. As a result, a plethora of companies have begun viewing the web as a new marketing platform and introduced “viral campaigns” and “sticky content” to generate traffic.
The question is, will the spike in traffic generated by push tactics help generate extra sales? Push marketing gimmicks work for a while - just as a free toy inside every cereal used to - but these concepts eventually lose their polish. In this world of decreasing timescales, even social media marketing has become so 2007. Instead of being a marketing platform, the web has become a product and service platform in its own right.
To sell products in a networked world, you need to differentiate yourself by more than just brand attributes and a check-list of features. You need to create remarkable products that rise above the competition and get noticed. Products that your users will rate, recommend and tweet about. In fact, what you need to create isn’t a product at all, but an experience.
Hoteliers have known this for a long time, moving up the value chain and transforming themselves from places to sleep into memorable holiday experiences. Gone are the chocolates on the pillow to be replaced by Egyptian cotton sheets, high end toiletries and HD televisions in every room. In fact hotels have a name for these items; they call them ‘delighters’.
Mediocrity just doesn’t cut it anymore. Instead, we need to create products that sell themselves. Does this mean that marketing no longer has a place in the networked society? Far from it. Marketers often understand customer needs and pain points better than anybody. In fact, this can sometimes be the cause of frustration in itself. I know plenty of people (myself included) who’ve been wooed by the notion of integrated phone, TV and Internet services only to find yourself dealing with completely separate business units and billing systems. The marketers were ahead of the curve. It’s the product that was lagging behind.
Companies like Zappos understand the power of delight only too well. Things like complimentary overnight shipping and personalised notes are just the tip of the iceberg for this online shoe retailer from Las Vegas. Zappos have done away with the call-waiting lights and encourage their staff to bond with their customers. They even train their staff to order out-of-stock shoes for their customers on competitor’s sites. The competitors get the sale but Zappos gets the goodwill. I even heard tell of one of their call centre staff helping a clients to order pizza, although this is apocryphal. No wonder they recently got acquired by Amazon for US$1.2 billion.
Marketers have a massive role in shaping new products. They also have an enormous role in shaping people’s opinions on a more personal level. You could even say that customer service is the new marketing. New online services like Get Satisfaction are hoping this will be the case and companies like Zappos would seem to agree.
The secret sauce is simple. We need to take a more customer centred approach to creating products that solve real problems for real people. We need to listen to our customer’s wants, needs and frustrations and create products that solve them. We need to constantly strive to improve our products at their core, rather than hiding their inadequacies with slick marketing campaigns. We need to create experiences that consumers can rally around and talk about, and we need to get out there and engage with the conversation. Not everybody can or will be able to create remarkable products, but the ones that do will flourish and prosper.
So what does this mean for the future of push marketing? I think that it is increasingly becoming clear that the effectiveness of viral campaigns will inevitably dwindle, while clients will begin to question whether their “sticky content” is not just brining them traffic, but the right kind of traffic.
Concepts such as “sticky content” belie the core concepts that are required underneath. Clients are going to need to spend more time learning the needs, wants and desires of their customers when building products, applications and campaigns so that they are pushing the right kind of traffic.
Ultimately, if you spend time creating something that people want, they will do the job of marketing it for you
Good products are one in a million | January 20, 2010
- I have an idea for a thing (1 million people)
- I tried to build a thing (50,000 people)
- I built a thing that works (10,000 people)
- I built a thing that people use (1,000)
- I built a thing that’s easy to use (50 people)
- I built a thing that people enjoy using (5 people)
- I built a thing that people love (1 person)
My First Impressions of Balsamiq | April 24, 2009
I recently received a wireframe from a potential client outlining their plans for a new homepage, which in itself was pretty impressive. It showed that the client had knowledge of the industry as well as a good understanding about the importance of planning.
To produce this wireframe our prospective client had used a relatively new tool called Balsamiq, which aims to capture the sketchy nature of hand drawn wireframes with the utility of a GUI application. On the surface this seems like a really good idea and it obviously allowed the client to produce something relatively quickly with little or no prior experience. As such, I think a tool like Balsamiq does have a place in the non-professional market. However I think the tool has a number of fairly fundamental problems.
First off is the styling. As I mentioned Balsamiq tries to capture the sketchiness of a hand draw wireframe by using artificially wavy lines, comic icons and hand drawn fonts— in this case Comic Sans.
As a designer my initial reaction was one of horror, as it should be when confronted with the use of Comic Sans on anything other than a children’s party invite. Obviously I’m being ironic here, but Comic Sans is an incredibly ugly font that offends most designers aesthetic sensibilities. That being said, I understood the logic so didn’t judge the app on it’s choice of font alone.
The logic is obviously to make the wireframes seem hand sketched so people don’t become too obsessed by the visual representation and focus on the content, hierarchy and functionality instead. Unfortunately the design for me had completely the opposite affect. Instead of feeling rough and hand drawn, these wireframes felt incredibly stylised — just not in a good way. In fact, rather than saying “sketch”, they said Fisher Price to me. It was as though the whole cast of Sesame Street had given up their day jobs to start careers as UX designers. I literally had images of Big Bird sitting down at his desk and designing “My First Wireframe”.
For a tool that’s supposed to communicate ideas in a clear and concise manner, this initial reaction was large and overpowering. However I struggled through, assuming is was just my own designer biases getting in the way. Sadly, the problems didn’t go away.
The stylised lines and boxed added an incredible amount of clutter on the page, while the typography proved jarring and uncomfortable to read. Even the small details like images or form elements were annoying and vied for attention. Try as I might to ignore the design and focus on the content, it kept forcing it’s way into my consciousness making the wireframes almost impossible to consume.
While a sketched line on paper feels organic and natural, unless done incredibly well it feels artificial on screen. We all know that computers are much better at drawing straight lines than sketchy ones so the whole concept felt like artifice, like a jarring attempt to recreate something natural in one medium that is completely unnatural in another. Like an uncanny valley of UX design.
Apart from the design hindering rather than aiding the comprehension of the wireframes, I think the designers and some of the champions of the tool may have missed the point of sketched wireframes. Possibly even developing a fundamental attribution problem. A UX equivalent of cargo-cultims.
There is something very natural about using hand sketched wireframes. They are incredibly quick to produce and destroy. The quality of the lines give them a human feel and, most importantly, a shared vocabulary. We all know what we’re looking at with a sketched wireframe. There’s no artifice, no duplicity and no stylisation getting in the way. They’re pure, unadulterated wireframes, just the way nature intended. However their sketchiness is a natural artefact of the drawing process. It’s not the point of their existence in the first place. In an attempt to recreate this sketchiness I believe the developers of Balsamiq have missed one of the fundamental purposes of wireframes — to communicate.
The purpose of a wireframe is essentially threefold.
1. As a visual tool for exploring content, hierarchy and interaction problems.
2. As a tool for sharing and communication possible solutions to stake holders.
3. As a tool for envisioning and testing the proposed experience.
Now I fully believe that the first purpose is the most important and that wireframes should be used as an ideation tool before a communication tool. So if you’re happy with the style of Balsamiq and it doesn’t inhibit your problem solving skills, then feel free to use it to work out your interaction problems. However I find that real sketching on pen and paper is much more efficient here, and it’s a nice excuse to get away from the screen for 5 minutes.
If you’re using wireframes to communicate information, I personally believe that the visual clutter of Balsamiq gets in the way and is a hindrance to comprehension. Instead, clean lines and simple typography fade into the background and allow the person using the wireframes to focus on the content and meaning rather than the presentation. As such, if you feel the need to use a GUI application, tools like OnmiGraffle are perfectly suited to this.
I’ve heard people say that clients get confused with wireframes, thinking that they are actually the final designs. In fact this is one of the reasons people suggest the sketchy nature of Balsamiq. However I don’t think the problem is in the tool, but than the way you use it. If you create extremely high fidelity wireframes using OnmiGraffle that look designed, and then don’t walk your user through the process, of course there’s a chance they’ll get confused.
I’m not a huge fan of OmniGraffle or Visio wireframes either, but that’s got nothing to do with the tool. I just think they are a bit of a halfway house between sketched wireframes and a fully interactive prototype. We occasionally use them but more often than not we’ll start with hand sketched wireframes and then move onto HTML/CSS wireframes if we need to envisage or test complicated interactions with real users, which is actually quite often.
The last problem I have with Balsamiq is also to do with it’s stylistic treatment, although this time it has nothing to do with comprehension. The wireframes produced by Balsamiq looks cheap and amateurish. This is obviously just presentation biased, bit I find it difficult to take any User Experience developer seriously if they present wireframes that look like they were developed by an early learning tool. Furthermore, I imagine a good swath of clients would feel the same way. In a time when we’re trying to build up the integrity of this profession, I wonder if tools like Balsamiq actually do more harm than good?
Is your website like a leaky bucket? | February 18, 2009
A lot of companies make money by driving traffic to their sites through marketing or SEO campaigns in the hope that some of their visitors will turn into customers. This makes sense when attention is plentiful and online marketing is cheap. However as marketing costs rise and attention becomes increasingly scarce, companies need to look outside of the traditional marketing funnel. Rather than simply increasing traffic, companies need to start focussing on conversions. After all there’s no point spending large sums of money pushing people to your site if they leave when they get there.
I call this the “leaky bucket” approach to product design and marketing. When water is cheap and plentiful, you don’t mind spilling most of it on the ground as long as you capture enough to quench your thirst. If you need more water you simply open the tap faster. You’ll end up spilling more but it doesn’t matter as you’ll catch more as a result. However as water supplies start to dwindle and costs begin to rise you’ll eventually reach a point when you can no longer afford to be wasting so much water. Instead it become much cheaper and more efficient to repair your bucket. As it currently stands most websites are literally leaking customers. These are people that actively want to use your product or service but can’t due to poor organisation or design.
This is where usability and user experience comes to the rescue. By ensuring visitors can find what they are looking for when they reach your site, you can plug some of the bigger holes. However the biggest holes are usually core processes like registration or check-out. A badly designed check-out process could literally be costing your company millions in lost revenue. In fact it’s not uncommon to see shopping cart abandonment rates as high as 95% on some sites.
Some of this can be put down to people window shopping, but a lot of this is due to bad process design. Shoppers with money in their hands getting frustrated by badly designed forms, or blocked by requirements to register before purchasing. For instance we came across a site the other day that prevented customers outside the US making purchases because State was mandatory and zip code was limited to 5 characters. We’ve even seen situations where customers think they have made a purchase but haven’t due to poor feedback design. All these issues are simple to discover and simple to fix.
So as attention starts to dry up, website owners need to start looking at plugging the holes in their system or risk losing out on business. After all it’s been known for a long time in marketing circles that it’s much cheaper to keep existing customers than it is to find new ones.
Don't treat your website like a commodity | February 15, 2009
The traditional approach to product development involves coming up with new idea and then driving as many people towards that product as possible, in the hope that some of them will want it. As such we adopt the language of marketing, and talk about marketing funnels and conversion rates. If our marketing department has done a good job they will have created a campaign that not only generates traffic, but creates a previously unrecognised need. Tired? Need a break? Why not have a KitKat?
This approach treats every product like a commodity to be bought and sold. However the problem with commodity marketing is the fact that there is very little difference between products. There is so little difference between a Snickers and a Mars bar you can’t really compete on features. And because commodities are generally cheap you can’t really complete on price or quality either. So instead you create brands, build tribes and keep pumping money into your marketing campaign to ensure that when you’re standing at the chocolate counter with your 50p, for some reason your brain says “how about Twix” instead of a hundred other confectionaries. It’s not very subtle and is a bit of an arms race, but in the word of commodity marketing it’s really all the ammunition you’ve got.
Sadly most website owners treat their online products in a very similar way. Rather than creating something that users actually want, they’ll simply extend another product or service. So just in the same way that Mr Snickers may have looked at Mr Mars and said, let’s make something similar, but with nuts, your average web entrepreneur will take an existing product, service or idea and extend it slightly. Even it it’s a genuine innovation it’s usually the idea that comes first, rather than the need.
Because there is little difference between the majority of online products, product managers resort to old school commodity marketing and focus their attention of driving traffic to their site in the hope that a few people will stick. This is why most big online products seem to focus more of their attention on SEO and marketing than they do on the product itself. After all, in their eyes the site is just another product to be bought and sold. It doesn’t really matter if it’s actually any good.
To get around this problem, people need to put a lot more thought into projects at their inception. It’s easy to fixate on a good idea, but our first ideas aren’t always then best. There’s nothing to say that there aren’t even better ideas out there waiting to be discovered. So rather than jumping in there with the first idea that makes the grade, try to analyse the problem from the users perspective. Does what you’re building solve a real or simply an imagined need. Are there more important, yet to be discovered needs that your product or service could solve instead?
Go out there and do some research. Watch people use existing products or services, both online and off. Ask people what they like about the services and what they dislike. Try to find out what frustrates them about the current status quo and use this to look for unmet needs. Rather than creating just another “me too” product, see how your site fits into the bigger ecology. Rather than compete with the market leader, try to compliment their services and fill a gap they’re not able to meet. Create prototypes and test them on real users. However don’t just do this to see if the site is usable, do it to see if the site meets users needs and be willing to ditch the prototype or even the project if it fails to test well.
I think one of the reasons most online products fail is through a lack of research, planning and customer empathy. We put all our eggs in one basket, without knowing if it’s the right basket or not. We end up committing to one course of action far too early in the process, so by the time the signals start coming in it’s too late to alter course. We have this fear that the time we spend on planning is wasted as it could be spent on production instead. However research and planning can not only help you avoid costly mistakes later on in the process, it can ultimately help you build better, more fulfilling products. Products that solve real world problems and make you more money in the process.
Usability as a Marketing Tool | January 27, 2009
Despite being 2009, one of the biggest complaints I hear from people when describing their online activities is how difficult websites are to use. People get amazingly frustrated when they’re trying to do something seemingly simple and the website continuously gets in the way. It’s almost as though the people designing or commissioning the website haven’t used it themselves. For most consumers this idea seems incredible, but sadly it’s largely still the case.
Very few design agencies think about how a website is going to be used, obsessing instead on what it looks like or how it’s put together. This obsession also filters through to the people commissioning the website as it’s much easier to criticise something based on looks or features than usability.
You can understand this attitude from sites that don’t play a big role in the fortunes of the company. However it rarely seems to matter if the site is a brochureware site or the main way people do business with the company.
Over the last few years we’ve seen a proliferation of online comparison services that aim to help you get the best deal on anything from the flat panel TV you’ve been lusting over to your home insurance. The whole goal of these sites it make it easy for people to compare different options and then switch providers, so it’s amazing how badly put together they all are. While they may be technically impressive, they provide the same level of experience you would have expected 5-10 years ago.
So during the self imposed tellyfest that is Christmas, I was impressed to see a series of adverts from confused.com focussing on the usability of the site. The ad was gloriously simple. Just a collection of presumably real customers extolling the virtues of the new website and how easy it was to use. Now I may be wrong (i often am) but I don’t remember seeing any TV ads that actually sell the usability of the site as a feature. Instead they normally focus on features like the number of sites they check. Either that or they get some burke dressed up in a nautical outfit shouting at you like some deranged loon outside a sailors mission. Like that’s where I go for financial advice!
It’s only a small thing but I’d love more pure-play companies to stop selling their services through traditional means and start seeing usability as a differentiator and a marketing tool. Although the fact that they can means there are a hell of a lot of unusable websites out there, which is a worry.
Silverback, One Month On | August 28, 2008
Silverback launched just over a month ago and what a roller coaster month that was. We launched towards the end of July and within the first couple of days the app had been downloaded 7,000 times. Thirty days on and well over 20,000 people have grabbed themselves a copy. Crikey!
For the first couple of weeks the whole company was hooked on the Twitter feedback. I had a Summize window permanently open and kept refreshing the search every few minutes. Messages were coming thick and fast and I was pretty bowled over by the feedback. The messages were so unbelievably positive I actually started to worry. After all it was just a little usability testing app and wasn’t going to cure hunger and bring about world peace.
Here is just a small selection of the comments we received…
Is so stoked about the utter incredibleness of @silverbackapp he can’t sleep. - @CliffSpence
Holy CRAP! Silverback (http://silverbackapp.com) is out and it rocked my world! - @erickaweb
Think @clearleft are on to a sure fire hit. Already my clients are asking about using Silverback, just a day after it’s release! - @paulrobertlloyd
Love silverback. so much love in the details. even the stupid ape is animated when you export a session. thank you so much @clearleft ! - @reimund
Has a major user-testing chubby over Silverback. This is fantastic and just what we needed for our upcoming sessions. - @gb
It’s been longer than I can remember that I found an application to fill such a gaping void in my work. @silverbackapp is oozing promise. - @niccai
Chubbies and gaping voids aside, that’s some pretty sweet praise. As people got over the initial rush of excitement and started playing around with the app, we started to get some more detailed reviews and a stack load of useful feedback.
- Silverback: Making Usability Testing That Much Cooler
- Silverback - Usability Testing for the Rest of Us
- Silverback - Guerrilla Usability Testing
- A Review of Silverback
- Initial Impressions of Silverback
- Silverback: Usability testing for apes
- A review of Clearleftâ€™s Silverback
- Usability testing with Silverback
- Software Usability Testing for the Rest of Us
When designing Silverback our goal was to keep the interface as simple and intuitive as possible. We wanted to include features that the majority of people would use while removing features that were only of interest to a niche crowd. After all we were trying to create a lightweight guerilla usability testing app for the masses rather than a pro solution, so less Photoshop and more iPhoto. We also wanted to democratise usability testing and put it back in the hands of the creators, so price was going to be a key factor. As such we were careful not to include any features that were overly complicated to implement and could push the budget up. This is why playback got cut from the initial release and we didn’t include things like editing.
As this is just the first release, there is is a lot more functionality to come and we’ve already got a bit of a roadmap planned out. For instance we want to improve file management, add the ability to preview your session and export multiple sessions in one go. We also want to do more stuff around notes and chapter markers to name but a few.
However rather than packing the app full of features from the outset, we wanted to get the app out there and see exactly how people were using it. This process has been really insightful and we’ve had some some great ideas so far. In fact it’s really interesting to see how many different testing styles there are and which features benefit each style. If you’ve got a spare 5 minutes I’d love to hear how you run your tests and which features would make your lives easier.
One popular feature request is remote usability testing. As it happens the idea of remote moderated testing came up very early in the development cycle and was something I was keen to explore. However we’d need to build it on the back of protocols like VNC which would have been time consuming and costly. Also, if you’ve ever used VNC you’ll know how much bandwidth this requires. It could potentially work over a local network, but it would be pretty ropey across the web, especially if your test subject didn’t share the same fat pipe as you.
Remote testing is actually an interesting one. If we’re talking about testing over a local network so the moderator and clients can be in another room you’re actually moving away from the idea of guerilla testing and towards something more formal. As such, this really feels like a pro feature to me. If we’re talking about remote testing over the web, I wonder how many people would actually do this? It’s still a fairly niche activity so I’m unsure of the demand. I personally find it awkward having a video chat using Skype or iChat, so wouldn’t get the same sense of empathy as actually being in the same room as the person. That being said we’re definitely open minded about these things and may consider it for a future release, assuming the engineering and budget constraints aren’t too high.
As Silverback was our first desktop app, there were always going to be a few teething problems, and in all honesty I’m surprised there haven’t been more. However we did put a huge amount of effort into the testing phase of the project, which I’m sure helped a lot. There are a couple of intermittent exporting bugs which we hope to have fixed shortly, along with some minor UI issues. We’re also aware that the exporting speed, while similar to other apps in its class, is still a little slower than desired. So we’re currently working on that. If you do come across any issues please don’t be shy, and post them up to our get satisfaction page.
So I guess that’s about it for now. It’s been an absolutely fantastic month for our hairy friend (no I don’t mean Jeremy), and I’m really excited to see what the future holds. We’ve had all kinds of people using it from Apple to NASA and 20,000 downloads can’t be bad. It’s been amazing to hear from designers who have used the app to prove the value of usability to their boss, or universities who have decided to use the app on their interaction courses. But more importantly I’d love to hear you’re thoughts, experiences and suggestions.
Oh, and I believe Steve the Gorilla may be making a surprise appearance at dConstruct next week, so I’m sure he looks forward to seeing you there.
Design Artefacts Part 2: Content Inventory | May 5, 2008
If youâ€™re redesigning an existing site, and especially if the site is a traditional content driven site, then one of the best ways to start is by performing a content audit. The process involves going through every page on the site and noting what the page is about and where it sits within the existing navigational structure. Looking at the content from a macro level allows you to generate a clear picture of how the site is currently structured and whether this structure makes sense.
If the site has been around for any length of time, new content will almost certainly have been added since the original schema was devised. Unless the structure is particularly robust or well planned, there is a good chance that some of this new content will have ended up in areas where it doesnâ€™t quite fit. This is understandable as itâ€™s very difficult for organisations to anticipate their content needs several months in advance, let alone several years.
Unfortunately websites tend to become dumping grounds for content that doesnâ€™t fit elsewhere in the organisation. Iâ€™ve seen countless sites become little more than glorified filing systems, full of annual reports and messages from the board. Content that nobody cares about or will ever read, but that needs a home. This is very much an organisational-centred rather than a user-centred approach to content, but sadly one that is still prevalent in many of todayâ€™s websites.
There is a strong chance that the site publishers havenâ€™t taken a proper look at their content since it was initially developed. So a site audit is a handy way to find and cull out of date or irrelevant material. Stuff that has been hidden in the dark recesses of the site for years and left to gather dust. As such itâ€™s a good idea to note the date the material was created and who has responsibility for that page. That way you can pass the information back to the relevant people and get it updated or removed.
With a full understanding of the existing structure, you can tell wither the schema is still working. If not, the process should have provided you with enough insight to start forming opinions on a credible new structure. This is ultimately the goal of the content audit.
However there is one added benefit of the content audit which Iâ€™m yet to mention, but which I think is vitally important. A structured review of the site forces you to read every singe page, understand the content and talk confidently about the results. By doing this you gather a huge amount of intelligence on what the organisation does, how they work and how they communicate with the outside world. Itâ€™s a great way of developing your domain knowledge and getting up to speed on a project or organisation.
A thorough content audit will often unearth important information that has hitherto been brushed over or forgotten. Stuff you may never have learnt from your clients or only found out when it was too late. You may even end up knowing more about the organisation than many of its employees, who will often have a particular specialism, area interest or personal bias. This thousand-foot view can come in very handy as it allows you to cut through a lot of the politics and make informed strategic decisions.
The information architecture reasons for a content audit should never be overlooked. However itâ€™s the deep understanding you develop for the content, the organisation and ultimately the domain where I think the real value lies.
Design Artefacts Part 1: Introduction | February 21, 2008
I’ve decided to start a quick series of posts on design artefacts. Basically all the documents, diagrams, designs and other outputs you create during the design process. These artefacts include the following items, although I’m sure you can think of more. As the series progresses I’ll link all the items up for ease of navigation.
- Content Inventory
- Competitor Analysis
- Personas and Wireframes
- Site Maps and User Flow Diagrams
- Low Fidelity Paper Prototypes
- Interactive Prototypes
- Usability Testing Reports
- Mood Boards
- Rapid Design Iterations
- Page Designs
- HTML/CSS Templates
These artefacts are often called ‘deliverables’ as they tend to get sent to clients for formal sign-off. Sadly I think we’ve got so fixated with the project management value of these ‘deliverables’ we’ve started to overlook their real value.
During this series I’m going to argue that the benefit of these documents is formative rather than summative. That, rather than being a milestone for checking the validity and progress of your designs, they are actually critical to the formation of the design itself.
If this is the case, which I believe it is, I’m also going to suggest that we stop treating them as traditional ‘deliverables’ and handing them over to clients for approval. Instead I’m going to suggest that we work with our clients in a more collaborative and iterative manner, using a process of passive approval instead.
Personas Suck | November 15, 2007
The thing I like about Jason Fried and 37 Signals is their tight focus on what they do. They are at once their own clients, customers and dev team. This gives them a great deal of freedom when it comes to features, functionality and process. However companies like 37 Signals are definitely in the minority, and most of us have to deal with much wider range of issues and stakeholders.
The problem I have with 37 Signals is their style of writing. If you’ve read their book or any of their posts, the stuff they talk about is rarely presented in the context of their specific working environment. More often it’s presented in terms of absolutes. I’m never sure whether this is merely stylistic, a desire to create link bait, or the result of a lack of empathy. In truth it’s probably a mix of all three.
Quite often I find that they misappropriate cause and affect. For instance, they had a developer in Europe and their first project was a success, therefore the geographic location of their developer was partly responsible for that success. In reality the guys at 37 Signals are really smart, and would have been a success whatever process, language or geographic set-up they had. However there is a tendency with genius design not to realise that’s actually what you’re doing, and attribute success to other factors. Sort of like the Olympic medalist who attributes her success to a lucky charm rather than raw talent and years of experience.
A good example of this didactic style can be witnessed in Jason’s recent post about Personas. As the article explains, 37 Signals don’t need to use personas because they are essentially building products for themselves. However because personas present no value to 37 Signals, they suddenly seem to present no value at all.
Jason argues that personas aren’t real people. You can’t ask them questions and they can’t tell you when they get frustrated or when something is wrong. This is all true, but its also misdirection because this doesn’t actually have anything to do with the value of personas.
For a start, personas don’t substitute the need to do your homework, talk to real people and test your assumptions on a live audience. In fact, the best personas are created out of exactly this type of research. As Jared Spool rightly points out, you shouldn’t mistake crappy personas for personas being crap.
I totally agree that you don’t need personas if you’re building something for people like yourself. However in an agency environment you don’t usually end up building sites for other web designer. In the past year we’ve build sites for everybody from scientists and teachers to environmental activists and mobile game buffs.
The problem many companies face is that they think they are building the site for people like themselves, when in fact they aren’t. A 40 year old technical director will have a very different outlook on life than a 16 year old girl. In fact, time and again our field research has shown that client assumptions about their market can differ substantially from the market itself.
So research is definitely important, but how does this feed back into the persona argument? Well, if you’re a small company and all your team have immediate access to your user base, maybe it’s easy to ring a few people up and ask their opinions at every step of the way. However for larger companies, personas are a really useful tool for summarising and circulating the results of your user research. They are also a great way for framing internal discussions about user requirements. So rather than talking about a homogenous “user”, you can talk about “Bob” or “Mary”. Personally, I find personas are most helpful during the discovery phase, when you’re building up domain experience and empathy with the users.
That being said, personas are just one of a number of tools at our disposal. I don’t think any user experience person worth their salt would say that persoans are required on every project. Furthermore, it’s very easy to overstate the importance of personas. In fact, this is something we’ve been guilty of in a few recent projects. The biggest problem with personas is the fact that they often become just another deliverable and end up sitting in a draw unused.
I think the argument about personas is ultimately one of context. It’s ludicrous to argue the merits of a screwdriver without knowing the situation. A screwdriver is great if you’re extracting screws, but useless if you’re trying to undo a bolt! Similarly, if you’re building a site for a group of web designers, you probably don’t need personas, whereas if you’re building a site for a group of doctors, they could come in handy.
But I guess being logical and rational doesn’t create the same stir as being sensational, hence the title of this post.
Designing the User Experience Curve | October 30, 2007
I’ve been interested in how the lessons learned from game design can be used to improve online experiences for a while now. I guess this interest started when I started learning about the concept of a “flow states”.
Flow is the state of being where you lose all perception of time and you flow from one successful task to another with seeming ease. It’s great if you can get into this state at work as you feel “in the zone” and can get a lot done in a short space of time. Sadly the number of distraction in the modern work place, combined with the fact that we’re perpetual multi-taskers, makes entering into the flow state at work a rare occurrence.
The place where we’re most likely to experience flow is when we’re playing a new computer game. As you start playing a new game you start encountering a multitude of small challenges and rewards. The high from each reward spurs you on the the next challenge, creating a cyclic effect.
If each challenge was as simple as the last you’d soon get bored, so computer games create a user experience curve. As the game progresses, challenges get incrementally harder, as do the rewards. However if the challenges get too hard too quickly, people give up. So the skill is in getting the curve just right.
Creating the perfect game curve used to be the preserve of level designers and was more art than science. However as game development budgets start outpacing those of the average Hollywood movie, the market needs to expand. Blockbuster titles are no longer the preserve of the hardcore gamer, demonstrating their l33t fragging skills. Instead these games need to appeal to a much broader audience. People who want to pick up and play, without having to learn overly complicated controls.
As an increasing number of these titles are sequels, the game designers also want to make sure that people can complete the games and are primed for a sequel. Because of this, games have become less about skills and more about creating an experience, a narrative and a sense of momentum. It would be no good if your newbie gamer gets stuck on level one and gives up.
I bought a copy of Wired magazine recently, and was fascinated by an article on the user experience design of Halo 3. The developers set up a fully featured testing lab and recorded more than 3,000 hours of play from 600 gamers. Normally game testing is restricted to bug testing, but what Bungie did was usability and user experience testing in it’s purest form.
Though usability testing the developers were able to pinpoint areas of the game where inordinate numbers of players were getting lost of killed. By examining real user interaction they were able to figure out what was going wrong and come up with ways to smooth out the user experience. This involved everything from making ammo more obvious, through to channelling users in the desired direction by stopping them from going backwards.
While this could be seen as an overly prescriptive way of creating games, it’s the essence of good user experience design. By removing usability barriers and helping people achieve their goals in an enjoyable manner, you end up crafting the optimal experience.
I was really excited by this article, and think there are a lot of lessons we can learn here. Not least the importance of usability testing on the user experience. At Clearleft we always budget for at least one round of testing, and even the smallest test produces amazing results. However imagine the improvements we could make if customers really started to value the importance of usability testing and budget accordingly.
User Experience Metrics and the Net Promoter Score (NPS) | September 21, 2007
I had the pleasure if being interviewed on the .Net podcast yesterday, on the subject of user experience design. During the discussion, Paul Boag asked how it was possible to measure the affects of good user experience design. I mentioned that Clearleft always try to encourage our clients to outline their goals and define their success criteria. This could be anything from increasing conversion or retention rates, through to reducing customer service calls or complaints.
At this point, Peter Merholz mentioned something called the Net Promoter Score and said that this metric was currently proving popular in the US. I have to admit my ignorance of this, so went off and did some research. It turns out that the Net Promoters Score (NPS for short) is a really simple, yet quite powerful metric for measuring customer satisfaction. Simple because it’s derived from asking a single question, powerful because it appears to have a direct correlation to the growth and profitability of a company.
To calculate your Net Promoters Score, you ask your customers “how likely they would be to recommend you to a friend”, and get them to grade their answers on a scale of zero to ten. Zero would be extremely unlikely while ten would be highly likely. Those who answer nine or ten are considered promoters, and are the most likely people to evangelise your services. Those who answer between zero and six are considered detractors and are the type of people who will spread negative views about your services. People who score between seven and eight are passive. They are generally happy with your product or service, but are likely to switch if something better came along.
To work out your Net Promoters Score, you simply subtract the percentage of detractors from the percentage of promoters. A good score would be in the range of 50-80%, while an average score would be 5-10%. A poor score would be in the negatives, and I can think of quite a few companies that would fit into that category.
I can definitely see the value of using this metric to help judge the success of a site redesign. You could survey all of your customers just before the redesign, and again a few months later, once the new site has bedded down. The greater the change, the more successful the project.
Airport User Experience | April 5, 2007
Whenever I talk about designing navigation systems at conferences, I usually use the example of airports. Like surfing the web, when you navigate around an airport you are normally in a hurry and rarely devote your full attention on the job at hand. Instead, your senses are being availed from all sides; from security notifications and advertising, through to environmental factors like the noise and temperature. As an aside, that reminds me of something Jared Spool always says on the subject of design transparency. You only ever notice the air conditioning when it’s too hot or too cold, never when it is working just right. Anyway, I digress …
If airports were built like most modern websites, finding your way around would be a nightmare. In order to extract the most money from visitors, the airport would be littered with signs for shops and restaurants. These would take priority over less revenue generating signs for gates or toilets, which would be placed wherever there was space. The marketing department would insist on huge banners advertising their latest offers, and the maintenance men would hang them wherever it was easiest to reach, often covering up existing signage.
The problem is, this type of thinking is very short sighted. Travellers would start missing connections or get frustrated that they couldn’t find the bathroom after a long flight. People would start spending less time at the airports, or if the option was available. switch airports altogether. So by trying to increase revenue in the short term, you end up frustrating your users and potentially damaging future profitability.
Thankfully airports take a much more user-centerd approach in their design. Signs are big and occupy the most important real estate. The signage at airports is also very contextual and based on the needs of the user at that point in their journey. So when you get to departures, the most prominent signs are for the check-in desks. After checking in, the signs move you towards security. Once airside, they know you’re going to be around for a while, so will give you signs for shops and refreshments. However the gate information always takes priority, to make sure you get to the correct gate on time and don’t miss your flights.
The same is true the other way round. The designers know that when you get off a long international flight, there is a good chance you’ll need to take a bathroom stop, so they make sure there are liberal signs and facilities around the gate areas. They then funnel you towards immigration, baggage claim and then finally out of the airports towards the ground transportation. With such large and complicated spaces, I’m always amazed how airports managed to move hundreds of thousands of travellers around each day. There are definitely lessons to be learned here, so take note the next time you’re passing through an airport.
I’m flying up to Edinburgh today with my friend and colleague Jeremy Keith, to speak at the Highland Fling conference. While waiting at my gate, a woman came round with a PDA and asked if I’d mind answering some questions about finding my way around the airport. Being interested in both navigation systems and contextual enquiry, I jumped at the chance.
After the survey was finished I got chatting to the woman and asked how often they do these type of sessions and how long they last for. I was expecting her to say a couple of days or a week at most, so was surprised when she said that she’d been doing surveys full time at Gatwick for the last 6 years, and she wasn’t the only one! Rather than the one-off field studies that I’m used to, this showed the airport were committed to a long term program of research and contextual enquiry. Top marks Gatwick.
The surveys weren’t always the same. Sometimes they were objective studies around navigation like the one I’d taken. Other times they were subjective studies of peoples likes and dislikes. Asking if the surveys made any real difference, she said that McDonalds had been removed from the airport and replaced with healthier fare purely down to user research. I could personally tell that the quality of the shops and restaurants had improved over the years at Gatwick, and I imagine it has been largely due to these types of surveys. It just goes to show you the importance of talking to your users.
While I was at the airport, I decided to splash out on an expensive pair of noise cancelling headphones. I’ve been doing a lot of ravelling recently, so decided it was a sensible purchase. The shop I bought them from allowed you to test a range of models, obviously trying to tempt the busy executive to buy one for their trip. The irony was, when I opened up the package, the batteries were uncharged, rendering the headphones useless. Somebody realised that it would be a good idea to market noise cancelling headphones to distance travellers as a need was there. They just hadn’t thought about the post sales experience, and the fact that they were effectively useless without a pre-charged battery.
On a similar note, my colleague Jeremy bought some flash memory for his camera from this cool little vending machine. Kensington obviously realised that people never have enough memory for their holidays, so sensibly put a vending machine at the gate. Sadly, this thought didn’t extend to the after sales experience either. The memory came in the traditional blister packs used to stop people opening them up and stealing them in shops. The problem was, we were airside, and thus not allowed to have any sharp objects like a pair of scissors, making it it almost impossible to open the packaging.
If only both of these companies has spent a small amount of time doing contextual research or user testing, they would have witnessed these problems first hand and could have easily rectified them. Bose could have supplied pre-charged batteries while Kensington could have done away with the excess packaging. Neither of these things would have had a direct affect on their bottom line, but they would have made the purchasing experience much more pleasurable. You rarely notice good design, but bad design sticks out like a sore thumb.
Heuristics for Modern Web Application Development | January 17, 2007
Heuristic evaluation is a technique that involves analysing the usability of a website against a set of general usability precepts. One or more “experts” will analyse the target site, often following a series of pre-defined scenarios. Whenever they encounter an issue that breaks one of the precepts or “heuristics”, they will note the issue and sometimes the severity.
Heuristic evaluation is usually done either to augment usability testing, or where usability testing is impractical or cost prohibitive. Heuristic evaluation is considered slightly more objective than a simple “expert review” as the results are based upon generally agreed guidelines rather than personal opinion.
There are a number of different usability heuristics around, but the most popular ones on the web are Jakob Nielsen’s 10 usability heuristics and Bruce “Tog” Tognazzini’s basic principles for interface design.
As part of my consultancy work at Clearleft I run a lot of expert reviews and heuristic evaluations. While planning a recent evaluation, I started to feel that the existing heuristics didn’t accurately describe the requirements of a modern web application. In particular I felt that Mr Nielsens heuristics were somewhat convoluted, contained a lot of overlap and varied widely in terms of scope and specificity.
Since Mr Nielsen first created his heuristics back in 1990, the web has changed on a lot. Many of the underlying principals remain the same, but their relative weight has shifted. So using these heuristics as a starting point, I set out to create a set of web application heuristics that better reflected the current landscape.
Usability heuristics are by their nature subjective, so I don’t claim what follows is a definitive list. However I have tried hard to cover as many common usability issues as possible. There is still a lot of overlap, but I think this is because one problem can the result of multiple causes.
Anyway, this is just a first draft so I’m really keen to hear your opinions.
Design for User Expectations
Design the system around the users, their goals and expectations. Choose features and functions the audience will find useful and use the appropriate level of complexity for their experience and abilities. Make processes work in the way users expect, and mirror real-world processes where applicable. Ensure the interface always upholds its promise and never trick or mislead the user. E.g.
- Choose features that will help users achieve their goals
- Use common web conventions
- Make online processes work in a similar way to their offline equivalents
- Donâ€™t use misleading labels or buttons
Make the system as clear, concise and meaningful as possible for the intended audience. Use meaningful icons, symbols and imagery. Use the natural language of the user and optimise for skim reading. E.g.
- Write clear, concise copy
- Only use technical language for a technical audience
- Write clear and meaningful labels
- Use meaningful icons
Minimize Unnecessary Complexity and Cognitive Load
Make the system as simple as possible for users to accomplish their tasks, but no simpler. Do not overload the user with too many unnecessary choices, and make sure those choices are prioritised. E.g.
- Remove unnecessary functionality, process steps and visual clutter
- Use progressive disclosure to hide advanced features
- Break down complicated processes into multiple steps
- Prioritise using size, shape, colour, alignment and proximity
Efficiency and Task Completion
Design for user productivity, not the systemâ€™s. Optimise the system for the most common tasks. Provide experienced users with advanced features that speed up task completion. Use the most common defaults and honour user preferences and previous selections. However, allow them to be easily overridden when necessary E.g.
- Provide quick links to common features/functions
- Provide advanced features like the ability to delete multiple messages
- Pre-check common options, like opt-out of marketing emails
- Allow defaults to be changed, cancelled or overridden.
- Remove unnecessary steps
Provide Users with Context
Interfaces should provide users with a sense of context in time and space. The system should let users know where they are, where they have come from, what they can do and where they can go next. Processes should inform users of the progress they have made and the remaining duration. E.g.
- Provide a clear site name and purpose
- Highlight the current section in the navigation
- Provide a breadcrumb trail
- Appropriate feedback messages
- Show number of steps in a process
- Reduce perception of latency by providing visual cues (e.g. progress indicator) or by allowing users to complete other tasks while waiting.
Consistency and Standards
Labels, processes and interface elements should be used consistently throughout the system. The system should use common web conventions unless a new convention provides a significantly improved user experience. E.g.
- Use common naming conventions such as â€œlog inâ€?
- Place items in standard locations like search boxes at the top right of the screen
- Use the right interface element or form widget for the job
- Create a system that behaves in a predictable way
- Use standard processes and web patterns
The system should help prevent errors wherever possible. This can be done by limiting incorrect choices, accepting alternative input formats, providing guidance and inline validation where applicable. E.g
- Disable irrelevant options
- Accept both local and international dialling codes
- Provide examples and contextual help
- Check if a username is already being used before the user registers
Help users notice, understand and recover from errors
Errors should be obvious and easy to recover from. Error messages should be clear, concise and easy to notice. They should succinctly explain what has happened and suggest possible solutions. E.g.
- Visually highlight errors
- Provide feedback close to where the error occurred
- Use clear messages and avoid technical jargon
Promote a pleasurable and positive user experience
The users interaction with the system should be positive and where possible enhance their quality of life. The user should be treated with respect and their preferences and wishes honoured. The design should be aesthetically pleasing and promote a pleasurable and rewarding experience. E.g.
- Create a pleasurable and attractive design
- Provide easily attainable goals
- Provide rewards for usage and progression
User Error is Our Problem, Not Theirs! | January 17, 2007
I witnessed something happen on a web developer mailing list the other day which I’m not proud of, but which is all too common in our industry. A group of experienced users rounded on a group of less experienced users for making a simple error, and then proceeded to put them down in public for their “stupidity and laziness” in not learning the system.
Sadly this is an all too common event when the technically astute developer come in touch with user error. Rather than blaming the system they created, these developers are all too keen to blame the users for their error. This reaction is somewhat understandable, as the developers know the system inside out and understand how it works. There is a good chance they even created part of the system and imbued it with their world bias. Because of this domain knowledge they just don’t understand how another users can’t get what they find so easy.
The problem is, most people don’t want to master the system, they simply want to get their tasks done in the simplest way possible. Users don’t sit and ponder all the possible options before making a choice. Decisions are made in a split second and are usually based on the first best guess. Apart from being looked down upon by developers, this approach has a low cost of failure and makes a perfect coping strategy.
It is all too easy to blame users for their mistakes and has become a bit of an in joke in developer circles. I’m sure we’ve all heard the story about the user calling tech support because his computer wouldn’t turn on, only to realise later that he’s in the middle of a blackout. However, while funny, there stories help to create an us and them attitude of superiority. The truth is, we are all that “dumb” users at some stage in our lives and shouldn’t write off other peoples experiences just because of our own personal biases.
In most cases, it’s not the fault of the user for making an error. It’s the fault of the system for allowing the error to be made. Ultimate responsibility for the error lies with the developers of the system, the very people who are so quick to scoff at their users stupidity.
So I implore you, “don’t be that guy”. See every user error as a gift. An opportunity to exercise your problem solving skills and make the system smarter. After all the goal of technology should be to empower people, not to make them feel stupid and inferior.
User Centred Design and Agile Development | December 22, 2006
Clearleft is a UCD, or User Centred Design consultancy. We spend time learning about the people who use our clients products, and then put those users at the heart of the design process. We do this using a variety of techniques from user surveys and contextual enquiry, through to persona creation, wireframing and usability testing. The ultimate goal of this process is to create experiences that are useful and meaningful to the people using our clients software.
As a company we specialise in the architecture and design side of the equation. We understand programming and development, but it’s not a service we offer. When clients come to us for implementation, we prefer to partner with another agency that specialises in back-end development. We’ve been designing a lot of interesting web applications recently, so Ruby on Rails seemed like a natural choice of development technology. One of the interesting things about working with Rails developers is their love of agile development.
Not being a developer, I’ve always been a bit nervous about agile development. I’ve heard people evangelise the benefits of reduced documentation, fast iterations and peer programming, and it logically makes sense. However I’ve always seen agile development as a bit of an ideological clique, and terms like extreme programming and scrum methodologies hardly make it accessible to the lay person. Because of this I’ve been aware of the concept for some time, but never really looked into it. It’s always seemed much more relevant to developers, so we’ve done our thing and let our dev partners do theirs.
A few weeks ago I was lucky enough to attend the Flash on the Beach conference in Brighton. As I mentioned at the time, my favourite talk of the conference came from Aral Balkan. During his wide-ranging presentation, Aral touched on a number of topics, but the one that piqued my interest the most was his take on agile development and how it fitted into a user centred design philosophy.
At first glance you’d be excused for thinking that the two techniques were diametrically opposed. After all Agile development is about making the developer’s life easier, while UCD is about making the user’s life easier. However the ultimate goal of both techniques is to deliver more useful software, and there is a lot of crossover.
Sat in the audience listening to Aral describe agile development, I was amazed how similar parts of it were to our UCD process. The agile process starts with a “Planning Game” where the client and dev team sit down and create a series of “user stories” in plain English. These stories are then broken down into tasks which are estimated and prioritised. This is pretty much exactly what we do, except we call it an IA workshop. We start by talking to the client about their users and examining any user data we may have gathered previously. Using this information, we”ll develop a set of “user personas” and create “scenarios” and “user paths” based on these archetypes. The user paths are broken down into tasks and each task is estimated and prioritised based on utility, complexity and time/cost.
In agile development, project specifications and other documentation is eschewed in favour of rapid implementation. We take a similar approach, and avoid written documentation in favour of representative wireframes. Rather than spending weeks trying to explain how a system will work in words, we build a non-functional paper prototype or a semi-functional XHTML/CSS prototype. Our clients can then start playing with the site before a single line of code has been written, so changes are fast and involve little overhead.
This is where we diverge slightly from the agile process as we wireframe the whole system in one go whereas agile devotees will only implement one user story at a time. I prefer to plan the site out fully first as I feel it makes for a more holistic approach. One process invariably affects another, and if you’re only concentrating on one story, it is easy to miss important patterns or vital connections. We’ve never done the small, fast iteration thing before so I’d be interested to see how it works. However I’d be worried that it would make user testing difficult as you would either be forced to do lots of small user tests which would cause resource problems, or wait till enough of the system has been designed to run a multi scenario test, at which point it becomes more difficult and costly to re-program the interactions
Minor issues aside, I think the similarities between agile development and UCD are fascinating. There is a great article over at UXmatters at the moment called Clash of the Titans: Agile and UCD which mirrors my feelings on the subject. I urge you to check the article out and would love to hear your thoughts.
The Trainline: Redux | October 20, 2006
So some of you may remember me berating the usability of the trainline webiste. Well it turns out that their off-line customer experience is no better than their online service.
With a couple of days to go until the journey, the tickets hadn’t arrived. I contacted their support line as instructed by the booking email, only to be told that they wouldn’t re-issue the tickets or provide a refund. As far as they were concerned the tickets had been sent, and if they were lost in the post, it wasn’t their problem.
It would seem that the address the tickets were sent to wasn’t complete. The address on the confirmation had the name of the company and the postcode, but no street address. The telephone operator asserted that this was my fault and the reason behind the problem. However when logging into the online system, the profile page contained the correct and full address.
Of course it is possible that this information was somehow lost or incorrectly entered. After all, the usability of the site was atrocious and this was my 6th attempt at completing the booking. Maybe I missed a crucial step or accidentally deleted some important information. However if the address line was vital to the booking, you would have thought that it would have been a mandatory field and the lack of this crucial information would have prevented the booking from being completed. But alas no. Despite having the correct address information on my account, the tickets were mailed out with a partial address and they never arrived.
Whether it was the fault of the booking system, the mail service or user error, the trainline had the opportunity to turn the problem round by issuing a new ticket. Had they done so, my impression of the company would have gone up significantly. However they chose to put all the blame and responsibility on the customer, and force me to buy a new ticket. Because of this, they have lost me as a customer forever.
The motto for the trainline is “The easy way to buy train tickets”, and if my experience is anything to go by, this is far from the truth. The irony is, it turns out that you can buy the tickets straight from the station at no extra cost. Rather than wasting 2 hours of my time and the cost of a ticket, I could have walked 10 minutes to the station and bought the tickets myself.
You live and learn
thetrainline.com Usability Problems | October 2, 2006
About 6 months ago I was doing some CSS training in the north of England and wanted to buy a return train ticket. I tried to book tickets using thetrainline.com but it was such a nightmare I swore never to use them again. Sadly I didn’t learn from my mistakes and 6 months later I’m back at their site desperate to part with my money and being thwarted at every turn.
Finding train times is the easy bit. You put in your dates, location and ideal times and get back a table of results. The time dropdown allows you to specify departure and arrival times in blocks of 15 minutes. Rather annoyingly if you only specify the hour and not the minutes you get an error message. It would be much easier if the “00” minutes option was preselected to avoid this unnecessary error, but it’s a minor annoyance.
However this is where things start to go wrong. At the bottom of the page is a button marked “Check Availability and Prices”. You would naturally think that pressing this button would take you to a page showing availability and prices. After all this is the promise the website is making, and this is exactly the information I’m after at this stage in the buying cycle.
Sadly clicking on this link takes you to a page with a log-in or register prompt. Now this is really frustrating on two levels. First off the website has lied to me and not honoured their promise to show me availability and prices. Secondly they are forcing me to register for a site that I may never use, before they have given me enough information for me to make an informed decision about whether I want to register or not. This is the web equivalent of forcing me to sign up for a store card before knowing how much the store costs or if they have any stock.
Still I really wanted to buy these tickets so I struggled on. I filled in a couple of pages of information about myself, my company etc. One rather odd thing here was the “can we spam you with marketing rubbish and offer” section. The marketing rubbish option was check box you had to uncheck, whereas the offers were un-selected yes/no radio buttons. Not sure why the two different types of element for pretty much the same question, but again I let that go.
I then got to a page with a section that asked me to fill in my office address if it wasn’t the same as my business address I filled in on the previous page. I filled in the rest of the form on this page and then clicked submit. The page bought back a required field error message on the phone number of the office address that was supposed to be optional. I filled it in with the same info as before, hit submit but got back to the same error. I tried removing the spaces and trying a different phone number but whatever I did I couldn’t progress through the process. The page would just hang for 30 seconds and then deposit me back at the same point. I tried clicking the back button, but it didn’t take me anywhere so tried to start the registration process again.
This time my log-in details were pre-filled so I though perhaps my registration may have succeeded without me knowing. Sadly this was just the browser being helpful so I hit register. Strangely, rather than being presented with 3 pages of stuff to fill in I was presented with a single page asking for a name, email address and password. I imagine the data from my previous registration attempt was stored as a cookie which was nice, but it through me off a little bit. Still after 30 minutes and my second attempt at registering I was finally able to see the train availability and costs.
Was this worth the effort. In all honestly the answer is no. By forcing me to register and then the registration not working, it left me feeling very negative about the trainline.com and mistrustful of their services.