Debunking common UX myths

10 minutes read

There are all sorts of user experience related myths, misconceptions and down right mis-truths out there. All UXers use Macs; you’ve got to wear skinny jeans to be a real UX designer; Jakob Nielsen has declared the letter ‘C’ to unusable, to name but a few. Here are some of the most common UX myths that I’ve had to deal with and why they’re simply not true.

If it’s not above the fold people won’t see it

For those who aren’t familiar with ‘the fold’ it’s an old newspaper term for the part of the front page of a newspaper that’s initially shown (in the good old days when newspaper were huge and had to be unfolded to be read). In the world of the web it refers to the part of a web page that’s initially shown when the page loads. Now whilst eye tracking studies have shown that elements above the fold will be seen first (people generally read in an F shape pattern), they have also shown that people do read below the fold. Indeed it can be argued that with the increasing prevalence of mice with a scroll wheel, not to mention touch screen navigation, people often prefer to scroll pages than to click through to new pages. This is perhaps why I’m noticing more and more ‘mega homepages’, as employed by many blogs, newspapers and other news sites (for a really massive homepage check out Cooper – a US design agency). For a nice outline of why you should be reconsidering your views on the fold checkout out Paddy Donnelly’s article on Life Below 600px.

The fewer clicks the better

Fewer clicks = better right? Well not usually because the number of clicks a user takes to get to a page or to complete a goal is not as important as the complexity between those clicks. For example, 5 simply clicks is usually preferable to 2 or 3 complex clicks because although the user has to undertake more interactions, the thought required for each interaction is less. Make clicks simpler not necessarily fewer, after all there’s a reason why you no longer see one page checkouts and why most homepages don’t look like Craig’s list. Fewer clicks are however well suited to more advanced users, such as short cuts and Amazon’s 1-click ordering.

You only need to carry out user testing with 5 users

I blame Jakob Nielsen for this one. After all, he has written an article titled Why You Only Need to Test with 5 Users. The number of users you need to bring in when it comes to user testing primarily comes down to the size and diversity of your user base. Ideally you should be carrying out testing with 3-5 participants from each user group, so 5 users only really makes sense if your product is only used by one type of user. Interestingly Jakob acknowledges this in the article so perhaps the title should be ‘Why you only need to test with 5 users in some instances, but with more in others, er it depends on your users really…’.

I generally find that for most user testing bringing in 8-10 users is best (although remember you will often get a few no shows so always recruit a few spare). This means that you can get a good spread of different users and that the vast majority of usability issues should be found. You also need to think about how much confidence you will need in the results, especially when reporting back to stakeholders. After all, it’s much easier to dismiss a usability issues that was only found with one user, as opposed to 3 or 4.

If you can’t meet with users, you can’t do UCD

Obviously if you can’t get hold of any users at all then your user-centred design options are somewhat limited (although you can still do user scented design!). In practice this is very rarely the case and even if you can’t meet with users face-to-face (which should always be your preference), you can still carry out user-centred design activities remotely, such as:

• Remote user testing
• Unmoderated user testing
• Online surveys
• Telephone or web cam user interviews
• Conference call focus groups

For a good introduction to these methods check out the Remote Usability website.

You can’t carry out user testing until you’ve got a working prototype

Whilst it’s certainly easier to carry out user testing with a working prototype, and easier still with a fully working product, don’t think that you need either of these to do user testing. All you really need to carry out some user testing is a user and something for them to interact with. That something could be some sketches, some wireframes, some design mock-ups; basically anything that communicates the design to the user. By playing the part of the computer (which is why the method is sometimes called wizard of Oz prototyping) you can ask the user to interact with the prototype and then tell him or her how the system would respond. This sort of paper prototyping is very useful for testing design ideas and concepts because you can get invaluable user feedback before investing too much time and effort on a design.

Don’t waste your time with a usability review if you’re carrying out user testing

Why carry out an expert usability review and user testing? Simple – because a usability review will find issues that user testing might not find, and user testing will find issues that a usability review might not find. Ultimately for user testing you’re at the mercy of chance. Research has shown that on average you need to test with about 15 users to find all of the significant usability issues with a design (at least according to Jakob Nielsen). Since this is ‘on average’ and you will rarely if ever test with this number of people anyway, issues will invariably fall through the cracks. This is why it’s a good idea to carry out a usability review prior to user testing. It will raise lots of potential issues that can then be evaluated, tested and explored during the user testing. For an interesting comparison of usability reviews and user testing checkout Webcredible’s article called Expert usability review vs. usability testing.

UCD takes too long and costs too much for most projects

This is an interesting one because I think that it comes about from the mistaken belief that if you care about the UX design of your product you must undertake a full blown UCD process, including oodles of user research, fist fulls of interaction design and truck loads of user testing. This invariably takes rather a lot of time and costs rather a lot of money, and so UCD gets the reputation of taking too long and costing too much for most projects. This simply isn’t true because you should in fact undertake whatever UCD process is appropriate and feasible for the project. If it’s a small project where the user experience isn’t likely to be crucial to its success (yep – UX isn’t always the be all and end all) then you might undertake only a few quick and dirty UCD activities. If it’s a project where delivering a fantastic UX is instead crucial to its success then you might undertake a more comprehensive UCD process. Even if timescales and budgets are very small there are always some Discount usability activities that you can do (although I prefer the term Guerrilla HCI because it means I can pretend to be Rambo). It might mean carrying out a quick user test with a work colleague, grabbing a few customers for a quick chat over coffee or spending 30 minutes putting some rough personas together.

In some sense this is also almost a double myth because rather than increasing costs and timescales, often UCD work can actually reduce the time that a project takes and save money. By getting early and continual user feedback you can minimise expensive rework and spot potential issues before they become very costly and difficult to rectify.

You don’t need to involve UX designers until the design stage of a product

Seems like a ‘No sh*t Sherlock’ statement doesn’t it? Why would you need to involve UX designers before the design stage for a product? Well because good UX design is not just about designing things well, it’s also about designing the right things in the first place. It’s no good having a fantastically usable and desirable product if it doesn’t’ actually do what users need and want it to do (unless of course you’re Apple and can brainwash your customers into wanting an overly priced laptop with no keyboard). That’s why UX designers should be involved from the start. Who better to help explore user needs and requirements, to study user behaviour and to help determine exactly what the product should be doing?

Analytics is your crystal ball into user behaviour

Analytics providers will have you believe that you can find out pretty much everything you need to know about your website through web analytics. Where are people going on the site? What are they clicking on? Where are people coming from and going to? Some packages will even allow you to replay individual user journeys so that you can see in excruciating detail what someone viewed and clicked on.

Whilst it’s true that analytics will tell you an awful lot it only ever gives one side of the story. It will tell you the ‘what’ but not the ‘why’. Why are people clicking on that link? Why are so many people exiting on this page? This is why it’s important to supplement analytics with qualitative user feedback, such as user interviews, user testing and online surveys. You can use these to hopefully answer some of the questions that analytics might have raised and to help fill in the other half of the picture.

All you need to do is ask your users

Henry Ford once famously said, “If I’d asked my customers what they wanted, they’d have said a faster horse”. Now you can argue that a horse is a damn site better and more reliable that most of the crappy cars that come out of America but the sentiment is sound. You shouldn’t be asking your users what they want so much as finding out what they need. By better understanding your users you can determine what is likely to be useful and desirable to them. By all means ask your users and certainly get feedback from them, but don’t expect them to come up with the next big thing.

UX designers are basically the same as business analysts

On the face of it UX designers and business analysts do a lot of the same work. Gathering requirements, specing out designs, speaking to users, and generally dealing with lots of different project stakeholders. The main difference between the two is focus. UX design is primarily focused on the user; business analysis is primarily focused on the business. This is why the best project teams have both UXers and BAs. The UXers can help unearth and define the user requirements and the BAs can help unearth and define the business requirements. Like the Mighty Morphing Power Rangers, the real power comes when the two disciplines work together. For an interesting take on UXers and BAs working together take a look at ‘Where business analysis and user experience intersect: the benefits of collaboration’.

UCD doesn’t mix well with Agile

UCD means lots of upfront research and design, which is counter to Agile, hence the two don’t mix. Well not quite because whilst a traditional UCD process with a lengthy research and design phase might not mix well with an Agile approach, a number of practices are starting to emerge for successfully integrating the two. In fact, I’ve outlined a number of these in a previous article called Tips for bringing UX to the Agile party.

Make the UX of a product as good as it can be

Surely it’s a no brainer? You should be trying to make the UX of your product as good as it can be. Well no, you shouldn’t actually. You should be making the UX of your product as good as it needs to be; in other words ‘good enough’. You should aim to deliver a ‘good enough’ user experience, not necessarily the best possible user experience. Leonardo da Vinici (the one with the code) apparently said that, ““Art is never finished, only abandoned” and the same is true of any design. There are always ways that a design can be improved but ultimately you’ve got to ask the question of whether the benefit is worth the cost?

You’re primary concern as a UX designer should be the user experience of a product

Sit down, take a deep breath and try not to scream because I’m going to tell you something that a lot of UX designers might not want to hear. As a UX designer your primary concern shouldn’t be the users, or the user experience of the product, it should be the business objectives of the product. First and foremost you should be concerned with how that product is going to succeed, whether in a commercial or non-commercial sense. Hopefully the user experience of the product is a significant part of that success but that isn’t’ always the case. In fact, you might even have to turn to the dark side of UX and employ some anti-usability design patterns. Sure UX is damn important but don’t forget that ultimately nothing is more importance than business objectives.

Anyone can do UX design

Jakob Nielsen has likened usability to cooking in so much as “everybody needs the results, anybody can do it reasonably well with a bit of training, and yet it takes a master to produce a gourmet outcome”. Well I wouldn’t have put it quite like that but yes anyone do UX design. However, although anyone can do UX design not everyone is a UX designer. Good UX design takes considerable skill and knowhow, and frankly leaving such things to non-designers generally ends up with a Hommer Simpson like abomination. As a designer you should certainly be including lots of people in the design process, but should ultimately be guiding the design to ensure that it doesn’t end up as a dogs dinner, or worse still as a web design that goes straight to hell (still my favourite The Oatmeal comic).

More UX myths

I’ve only really scratched the surface of UX myths – you can find more at UXMyths.com and Top 10 UX Myths. I’d also love to know what you’re favourite UX myths are…