Another 10 UX mistakes to avoid

7 minutes read

In a previous article I listed 10 common UX mistakes to avoid and outlined how to go about side stepping each one. Well like a modern day Hollywood franchise I’m back with 10 more because all good things need a sequel and it seemed a shame for so many important UX mistakes to be left on the proverbial cutting room floor.

1. Leaving usability issues to later releases

You know in some ways user experience is a lot like DIY (bare with me here). As any home owner will tell you there are always a million and one things that need to get fixed and improved around the house, from dripping taps and scuffed walls to dodgy light sockets and creaky banisters. If you’re like me you’ll make a big list of stuff that needs doing and then decide to do it all some other day because you’ve found something much more interesting to do. Well the same is also true of usability issues. You often have a bunch of stuff that has been flagged up as causing users problems but somehow they never get fixed because a fancy new feature is seen as more important, or there simply isn’t time to get it fixed for the next release. The issue invariably falls by the way side and gets lost in the mists of time, never to be resolved (sob). Rather than leaving usability issues to later releases try to ensure that you test early and often so that you can get them fixed in time, or even delay a release if the user experience isn’t up to scratch. If an issue really can’t be fixed in time for the next release then make damn sure that it makes it in for the next one because as Neil’s (unofficial) first law of usability issues tells us, the longer you leave a usability issue the less chance there is of it ever getting resolved.

2. Coming to the design battle discussion unprepared

I’m sure that you’ve been in a few heated design battles, erm I mean discussions in your time. They usually involve either something seemingly really minor, like the colour of hyperlinks or something very highly prized, like real estate on a homepage. Voices usually get raised, people become very animated and swords are often drawn ready for combat (metaphorically of course). In such circumstances it’s always worth ensuring that you’ve come ready for combat, preferably with lots of evidence to back up your position. This might be in the form of user feedback, analytics data, research findings or even just a really good reason for why a particular design is a good idea. People find it much harder to argue against facts, figures and findings than just opinion and conjecture, so try to bring these to the table and hopefully you’ll come out of the battle, I mean discussion victorious.

3. Failing to explain UX terminology

Like most disciplines user experience has its own set of secret terminology to maintain that all important cloak of mystery. Do you think your average business person knows precisely what wireframe are? What about a contextual enquiry or a heuristic evaluation? It can be all too easy to use UX terms without releasing that people are not going to know what they mean, or even worse will misinterpret them. For example when you talk about wireframes, they might think that you’re referring to the finished visual design, so are going to be a little surprised when you come back with something as colourful as an old black and white movie. This is why it’s so important to explain UX terms that are used (or even use terms that people are likely to be familiar with), to communicate exactly what UX deliverables such as prototypes, wireframes and personas are and to set expectations upfront. This way you can keep misunderstandings, not to mention nasty shocks and surprises to a minimum.

4. Being overly negative

Remember that feeling you got when you received a piece of school homework that you’d spent ages and ages on only to get a rubbish mark? Pretty disheartening wasn’t it (and to all those would said ‘no’ – you’re lying). Well that’s the same feeling that people get when you tell them that the design they’ve spent ages lovingly crafting sucks (although hopefully not in those exact words). A great deal of user experience design involves critiquing, evaluating and testing designs, whether its as part of usability testing, design critiques or simply delivering your two pennies worth about a quick UI sketch. It’s therefore no surprise that often UX designers find themselves delivering bad news. Pointing out problems, potential issues and improvements is of course vitally important but remember to not be overly negative because this can sometimes be counter productive. Only delivering bad news can not only reduce recipients of said news to a sobbing mess but also increase the likelihood of resistance to your feedback. No one likes hearing only bad news so also be sure to point out what’s good about the design – what works well and what improvements can be made. By outlining what’s good about a design as well as what’s bad you’re more likely to get buy-in and avoid the reputation for being the office Eeyore.

5. Becoming too attached to a design

Your team has spent ages working on a radical new design for an application. Everyone in the team thinks that it’s the bee’s knees, expect unfortunately the users who where less than forthcoming in their praise during some usability testing. Do you keep hold of your pride and joy and tell yourself that those pesky users don’t know what’s good for them, or go back to the drawing board? In situations like this it can be very difficult to ditch a design that you’ve spent a lot of time working on (and probably become very attached to) but often this is precisely what you should do. It’s a mistake becoming too attached to a design because ultimately you must be able to assess each design objectively. If user feedback is indicating that a design isn’t working then don’t be afraid to change it. Of course this is again why getting early and frequent user feedback is so important and it’s also why coming up with a number of different designs is such a good idea. Take a leaf out of Apple’s design book and come up with a number of designs which you can then whittle down to the one that works best. This sort of design Darwinian selection not only leads to the survival of the fittest design but also generally stops you becoming too attached to a particular design, simply because it’s the only one you’ve got.

6. Buffing and polishing deliverables until they sparkle

A good designer (or design team) should be judged on their design, not their deliverables. Unless you’re sadly not able to see a design through to delivery and as such your end goal is a set of deliverables (for example you’ve been brought in just to deliver a design spec) then it’s a mistake to spend any more time on deliverables than you really have to. Sure you don’t want documents with lots of typos and wireframes that look like they’ve been put together by a five year old (although I’ve seen plenty of wireframes where a five year could have probably done a better job) but certainly don’t spend more time making your deliverables look good than actually creating them in the first place. Take a leaf out of Cennydd Bowles and James Box’s Undercover User Experience design manifesto and focus on delivery, not deliverables. Ultimately deliverables are only a means to an end, it’s the delivery that really counts.

7. Starting from scratch

A lot of UX design is about creating stuff. Creating prototypes, creating documents, creating designs and so on. Whenever you’re creating something you’ve got to start from somewhere but it’s certainly a mistake for that somewhere to always be from scratch. Rather than creating a persona from scratch see if there is a template out there you can use (like this persona template). Rather than creating a set of scenarios from scratch see if there are some example scenario documents out there you can borrow the format of. Rather than creating a new design from scratch see if there are some design patterns out there you can utilise. Sometimes of course you really do have to start from scratch, but really this should be the exception rather than the rule.

8. Failing to dot the I’s and cross the T’s

When it comes to user experience often the devil is in the detail. A user’s experience is made up of a thousand tiny details, from a mouse click here to a piece of text there and if those details are a bit slap dash in parts they will eventually build up to one crappy overall user experience. This is why it’ so important to make sure that all those tiny details are as intended and as they should be. That copy doesn’t contain any typos or spelling mistakes. That text casing is consistent. That elements are properly aligned and so on. Don’t think that you can rest easy because everything will be picked up by the test team, or perhaps the development team because their focus is usually on the functional side of things, not the UX side of things. Ultimately the design team should be responsible for the UX design, therefore poor attention to detail not only reflects badly on a website or application but also the design team behind that website or application.

9. Letting information about users slip through the cracks

How much information do you have available about your users? Probably more than you think. There’s the customer satisfaction survey that was run last year that you weren’t aware of. There’s the persona research that was undertaken for a different project. There’s the report from a usability testing consultancy that’s gathering dust somewhere (you get the idea). Often user research, usability testing and UX design work is carried out by different teams within an organisation, or even farmed out to different suppliers so it’s no surprise that the information can become very fragmented. Often really valuable information about users gets lost in the ether because teams don’t talk to one another, don’t organise their user information or simply don’t bother to retain it from project to project. This is why it’s such a good idea to have regular discussions between teams and to have a place where information about users can be shared, stored and discussed (such as a Sharepoint or Basecamp site).

10. Over analysing every design decision

There’s a now infamous story from Douglas Bowman about Google testing 41 different shades of blue to see which one performs best for a particular design. Now this surely takes over analysing every design decision to the extreme but don’t make the same mistake of using A/B testing, or user testing as the only means of making a design decision. Sure it’s great to get some feedback for a design but often you just have to make a call and go with you’re UX design gut instinct – and if that fails you can always ask the magic eight ball.