I’ve been in the software design business for well over a decade now; such amount of experience cannot be simply shared, neither with exhaustive blog posts nor with a series of workshops and presentations. It has to be experienced right there in the front-line where your decisions can elevate your product to unexpected success or turn it into useless piece of code that nobody cares for.
That is why I feel safe writing about my experience and sharing my knowledge. Know-how is not only theory. Anyone can learn theory by attending a course or reading a book. The real know-how is gained by practicing, making the decisions and taking the chances. Real know-how becomes a second nature to its bearer, it becomes an instinctive understanding on a level that has nothing to do with facts, guidelines or best practices.
Over the course of years I have observed the evolution of understanding of UX in several companies and it was rather easy to identify certain key decisions each of the companies had to make – sometimes even several times over because the chosen path had proven to be wrong.
Hence I’m offering a reminiscence on the ever-popular “10 things you should know about…”, this time aimed at User Experience and Design and the way software companies handle them. These are the ten myths that I’ve often encountered in the past and I keep seeing them even these days.
1. Data Are The Product
This is a popular engineering myth. It is rather natural, given that the engineering focuses on data gathering and evaluation. However much data are important and intriguing, they do not make up your product – unless you’re developing a database control panel.
If this myth is popular within your company, it only proves one thing: your product teams have lost vision of the product and the management followed suit. Or maybe the vision was never there, which is the worse of the two options. Either way, remedying this is going to be painful and will take time.
Why should people bother to use your product instead of doing their work manually? If you can’t answer that question instantly, then your product probably doesn’t make a difference and your customers might as well be using any common data viewer with approximately the same effect.
2. Features, Features, Features
Can your product perform a hundred various operations? Two hundred? More? Good for you, but – do your users know? Most importantly – do you only offer these features when it’s relevant?
I have encoutered products in my past that I could call “rich on features”. They really could do a lot, but they all shared one critical flaw that made them very unfriendly. They were advertising them too much, up to the point when they overwhelmed the user.
As a common user I have just signed in and all I wish to do is to see “what’s new” and “what’s on my ToDo list for today”. Do I really need to know that I can create a reference to a copy of an entity in your software? Why should I be forced to see that and another forty similar options? The usual answer to this question is along the lines of “because it’s a feature”.
It’s great that your product has all those features, but I don’t care. I will be happy if I’m presented with them once it’s relevant. Just don’t force them on me. It is confusing, it overwhelms the user, and it makes the product difficult to use.
3. Customer Knows Best
Henry Ford once said: “If I had asked people what they wanted, they would have said faster horse.” He had managed to sum up a huge and wonderful lesson on how little customers actually understand what they want. It’s why I’ve chosen this quote instead of spending thousands of words on explaining.
We should listen to the customer, but not accept everything we’re told. In software industry, customers come to us because they have a problem, and they expect us to find a solution. In mistaking their suggestions for solutions we would do ourselves -and the customer- a bad service.
Remember, the customers do not know how to solve their problems. If they had, they wouldn’t have come to you. But they did, and they expect you to be the expert and find the solution. Be the expert, then. Listen to what the customers have to say about their problems and concerns, but be critical to anything they suggest. Use your expertise to put yourself into their position and find your own solution.
Don’t promise anything other than “We will find a solution”. Any other commitments, contractual or not, will harm you in the long run.
4. User Needs to Customize
They don’t. It’s simple as that. Have you ever seen a user launch a software, looking forward to the awesome and incredibly cool task of setting up hundreds of options, choosing which columns they want to see in a table and in what order, whether or not they want to be notified and in which manner, or how many items per page they want to see?
I’ve seen users launch a software only to become disgusted and annoyed if they were presented with all these customizations. Users don’t want to create a meaningful interface. They want one out of the box, instantly – and it is your sacred duty to provide one.
You don’t buy flight tickets expecting that your captain will ask you what altitude you’d prefer, whether you want to fly through a storm or circle around, whether it’s okay if they retract landing gear on takeoff or they should keep it out during the flight, whether you’d like them to take some extra fuel in the very unlikely case your plane would need to standby before your destination traffic control clears you for landing, at what angle should the pilots approach the runway, whether they should compensate for crosswind or not…
You buy flight tickets and you expect a simple service: Get on the plane, fly, get off the plane. You don’t care for all the details, you just want results. Your own users want the same: They want results, not a ton of options. And just like you rely on your captain to make the best choice, they rely on you.
5. User Wants to Decide
Do they? Is the constant pressure of having to decide really the reason why people should use your product? I don’t think so.
If there is any single reason why anyone is using software instead of doing things the “old way”, it is because they want the software to make their task easier. The key to that is in eliminating most of the analytic work and decision making and in limiting them to a few simple and straightforward ones.
Imagine yourself driving a car; you need to turn right and slow down before you make a full stop at your garage. Those are the important decisions that you can make intuitively, without focusing. How about a car that would require you to specify the exact angle your left wheel should turn? And the right wheel? Keep in mind that in order to perform a safe turn these angles are different, so you need to calculate the difference and enter it. How much force (in Joules) do you wish to apply to your brakes? Would you rather apply a linear increase or fractional one? And would you prefer if the applied pressure was distributed evenly between rear and front brakes? Or would you rather put more force on the rear brakes? By how much? …
Nobody wants a car like that. And, let’s be honest, nobody wants a software like that, either.
6. User Fears Change
This is true to an extent – but it does not mean user fears improvement. To understand what it actually means, put yourself in their shoes: they have spent hours or days reading the manual to your software, learning how to use it and what to do in certain unusual cases. Naturally they are worried that all their knowledge would be useless and that the process they’ve learned to know by heart would be – different.
Yet the real fear is not of change, but of change for the worse. A change that doesn’t do anything to make the process more transparent and intuitive is always a change for the worse. It brings extra cost in the form of having to re-learn the product, but it offers nothing in exchange.
When changing things, always do so with your users in mind. Make changes that will make their lives easier. A meaningless self-serving change can kill your product as surely as a key feature that doesn’t work.
7. Usability Is Secondary
Many companies still believe that it doesn’t really matter whether or not their product is usable, as long as it delivers in functionality. It’s difficult to argue with the entire company, so if you’re a UX Designer, don’t even try to argue this point.
Instead, work hard to provide a vision of what your products might look like. Build an interactive prototype that would show the alternative and try to present it to whoever is the decision maker in your company. Being able to involve some of the company’s customers also helps; customer feedback is usually a great leverage.
Demonstrate your knowledge of the customer’s problems by showcasing one or two of the most frequent scenarios and point out the different experiences the users achieve in the “current” solution and in the “new” one.
If this doesn’t work, there is only one advice I can give you: move on. A UX Designer has no place in a company whose “don’t-care” approach comes from its key players.
8. UX Design Is About Colors And Icons
It’s curious how wide-spread this myth is. It’s almost as if icons and color were magic spells that somehow, miraculously, make a product better.
A designer I’ve worked with used to say: “I may add a ribbon to a turd and polish it if you want me to. However the result will still be a polished turd with a ribbon.”
Rough as it may sound, it’s inevitably true. A company cannot expect brilliant mind-blowing awesomeness when all the Designer is allowed to do is – to tie a ribbon ’round a turd.
9. Tend To UX When Features Are Done
This is one of the worst things that can happen in software design: Features have been implemented, and now it’s time for the designer to do his magic and turn the ugly thing into a passable product. As a designer, I advise my fellow designers – don’t even try.
In my experience, a good UX Design requires a rather long process that begins with the UX Designer making a series of meetings with the Chief Architect, someone from Customer Relations, and the Product Manager. Together they need to determine what the product should bring to its users, and how.
UX Design is inseparable from the process. Planning features is pointless unless you know how to present them and how your users are going to use them. Knowledge of the way your users’ minds work is one of the key attributes of a good UX Designer. Use that resource and listen to your designer.
Or don’t, and deliver the mediocre data-driven product that nobody cares for. The choice is yours.
10. Anyone Can Do UX
It is no random chance that this is the final of the Ten Myths. It is the most dangerous of them all.
To understand why, we must realize that User Experience is a highly specialized area. It requires practical experience, ability to listen and learn; a UX Designer must be able to analyze incoming requests and information and pinpoint the real core of the problem before suggesting a solution. A UX Designer must be able to put himself into the customer’s shoes and approach problems in new and innovative ways. Knowledge of human psychology helps, too. But most of all, a great UX Designer needs to be a rare combination of scientist and artist.
User Experience is both – an art and a science. The science part is about analyzing information, knowing the standards and being able to determine user expectations. The art of UX Design lies in the designer’s ability to be creative, innovative, and to deliver visually stunning results.
Just because you’ve seen a space shuttle on TV it doesn’t mean you could build one. Yet it appears that everyone who had ever seen a computer software feels knowledgeable enough to design one.
And that is why this final myth is so dangerous, and why so few companies have ever managed to deliver a truly stunning User Experience and most of them fail to deliver even a decent one.
