Nine simple UX truths
I propose to the readers of “Habrakhabr” the translation of the wonderful article “Nine Nasty UX Truths” by Antoine Valot. There are a lot of materials on the UX theory on the Internet, but the tips below are the result of the hard work of the author, something like cones stuffed in the process. Antoine admits that he has screwed up countless times in the past 20 years, and the truths described are just some of the ways to avoid failures. Do not repeat mistakes, enjoy.
Actually, it's not difficult, even half is not as difficult as you think.
Users do not understand your color coding. Green means “good” for you, but for someone else on another screen, it can mean “unreadable” or “goose shit” or “Saigon? What? Am I still in Saigon? ” Every person sees color in his own way, if he sees it at all. He loves some colors, and hates others. And this is largely unpredictable. You will not be able to guess.
Color is not verbal or rational. It is contextual and emotional. Color is a powerful tool, but in itself it does not make sense.
')
The only thing you can do with flowers is:
Any color: the item has a color
Other color: the item is different from the other item
Gray: something is broken
Red: the designer hates you and wants to piss off
Users do not care what your icons on buttons mean, or what is written on them. You can change them every day, and no one will complain.
Change the position of the elements, and users will put your head on the peak.
People use their motor memory when using applications. Moving interface elements feels like a sophisticated method of torture. If you want to know what pure unfiltered burning hatred is, go and swap a few elements in places.
You most likely do not read this sentence. If you read, then probably did not read this article entirely from the first time. You ran from headings to quotes and maybe missed a couple of points before reading this paragraph. So it's true. And yet, why do we write an explanatory text? Why do we allow ourselves long paragraphs in our interfaces? Why do we pretend that user guides and frequently asked questions are the right solution for usability issues?
Because we are lazy, that's why! Too lazy to read, and too lazy not to write.
Do not be proud of your navigation interface, or information architecture. If navigation is an important part of your interface, you are on your way to failure.
Your task is to help the user achieve his goal. Navigating the application is NOT the user's goal. If you have done your job correctly, your application will do only one thing and will do it well, being all this time on one screen. But you are not able to decide anything for the user or even eliminate the choice, and you leave the choice to the user to the user.
Design is the making of hard decisions in order to save the user from making decisions.
Yes, well, navigation is necessary for most applications, most sites, and the user, after all, is used to using navigation. We have to make some compromises. I absolutely agree. And I almost always make this compromise and implement navigation. However, I am ashamed of you too.
Not all parts of the application are equally important. There are some things you should do first, some things you should not forget, and some that can be completely ignored.
My first UX job before the UX concept was formulated was the Information Architect. This is still the most important work that is on any project. Things have names and must be named. Identifying names and verbs is the most important part of UX.
Content is the solution. If you do not design content, you design problems.
Every time you create frames with Lorem Ipsum, you insult your users and abuse the trust of your client. And also sabotage yourself.
Loremipsitis is bad, believe me, I saw a photo.
When you are not able to deal with the actual content, but focus on designing frameworks that are independent of the content, you actually create a barrier between the user and their goal. Stop immediately. Design content and you will most likely cope with the task automatically.
Make the sitemap and navigation last. Actually, don't do them at all. Start with the most important objects on the screen: with the one that helps the user to achieve his goal. All the excess time and budget should be aimed at making this screen perfect. Focus on every detail. Spend all the time polishing each pixel. Do not deny yourself the pleasure to enjoy every minute of development.
When the deadline comes or the development budget ends, your client / boss will be very angry, will scream at you that you have not done the rest of the bullshit that they wanted to cram into the user. Be dumb, apologize and earn the reputation of one who will never finish anything ...
Fail to plan so as not to design unnecessary parts.
Let's hope that all unnecessary garbage will be delayed until the next version, and the user will enjoy a clean product until you are fired, and the one who replaces you will spoil this ideal. There is no shortage of UX designers on the market who do what they are told and what is expected of them. That is why there are so many substandard products. Do not be one of them.
User tests are something incredible, a well-known fact. No matter how incredibly smart you are or how good your interface is. Ten minutes of user test in the early stages of a project can protect you from failure at the end of the journey.
User tests they rule. If you don't make them, you are an idiot.
However, user tests do not free you from the need to be smart, work, sweat on every little thing and go through a crazy, tortuous, bizarrely amorphous design process. You must still be a genius. And this is especially true when you are developing an innovative solution or products.
When it comes to innovation, users can be evil, dull-minded, short-sighted, vain, stupid, etc. And this has to be tolerated.
User tests for new ideas sucks. If you make them, you are an idiot.
When you have a great new idea, it begins its life with a fragile fetus, barely breathing. It needs nurturing and tender care in order to turn into a fully formed innovation that can stand firmly on its own two legs and withstand the careless handling of mercenary users. User testing of a new idea as a testing of a new lamb. It ends badly, both for the idea and for the lamb. So don't let your idea go to the uninitiated ... but only until it is ready.
How to know that the idea is ready? When you worked on it for a long time, you begin to see significant shortcomings: the problems that lie in how the idea works in general, and not how to combine it all with the existing ones. When an idea starts to work close to how you have conceived that you yourself start thinking about alternatives - it's time to check.
You may think that the coders error is not your fault. True, but still it's your responsibility. Just like sending a message that will never be received, a design that will not be understood is a waste of time. You must understand your audience, and your audience - programmers. They are strange animals, but in the end you too.
If you take good care of the dev department, the developers will make you rich and famous.
Learn how to code, actually it’s time, but until you did, here's what you need to know about programmers:
Developers do not explore well-designed applications and sites to find out how they were created. They spend their time learning with the help of demos and guides written by other coders, trying to explain complex coding concepts using contrived and funny examples.
Programming tutorials teach the worst UX practices.
They do not think about the real application of these examples. They do not think about the UX of these examples. They do not care whether these examples will lead to positive results in their fictional scenarios.
Thousands of developers are learning their craft, blindly implementing overly simple, poorly designed, stupid scenarios. They develop their applications with a few clumsy forms and hundreds of hours of insane tutorials. So maybe you should be a little more specific with your specifications?
Programmers have to worry about things that no normal person would think about. You can put the Last Name field in your design, but the programmer will have a hundred alarms:
• What if a person does not have a last name?
• What if the last name is expressed as a mathematical equation?
• What if the last name is longer than 255 characters?
• What if the last name contains tabs, multiple paragraphs, non-breaking spaces, emoticons, parentheses, commas, single and double quotes?
• What if the last name changes over time?
For any normal person, these questions are absurd, but not for programmers. For the designer, this means that he should keep close to the programmers, understand them as best as possible in order to anticipate such anxieties, and keep them from completely insane.
Four design truths
Actually, it's not difficult, even half is not as difficult as you think.
1. Color does not make sense
Users do not understand your color coding. Green means “good” for you, but for someone else on another screen, it can mean “unreadable” or “goose shit” or “Saigon? What? Am I still in Saigon? ” Every person sees color in his own way, if he sees it at all. He loves some colors, and hates others. And this is largely unpredictable. You will not be able to guess.
Color is not verbal or rational. It is contextual and emotional. Color is a powerful tool, but in itself it does not make sense.
')
The only thing you can do with flowers is:
Any color: the item has a color
Other color: the item is different from the other item
Gray: something is broken
Red: the designer hates you and wants to piss off
2. Position is the most important.
Users do not care what your icons on buttons mean, or what is written on them. You can change them every day, and no one will complain.
Change the position of the elements, and users will put your head on the peak.
People use their motor memory when using applications. Moving interface elements feels like a sophisticated method of torture. If you want to know what pure unfiltered burning hatred is, go and swap a few elements in places.
3. No one reads
You most likely do not read this sentence. If you read, then probably did not read this article entirely from the first time. You ran from headings to quotes and maybe missed a couple of points before reading this paragraph. So it's true. And yet, why do we write an explanatory text? Why do we allow ourselves long paragraphs in our interfaces? Why do we pretend that user guides and frequently asked questions are the right solution for usability issues?
Because we are lazy, that's why! Too lazy to read, and too lazy not to write.
4. Navigation is a failure.
Do not be proud of your navigation interface, or information architecture. If navigation is an important part of your interface, you are on your way to failure.
Your task is to help the user achieve his goal. Navigating the application is NOT the user's goal. If you have done your job correctly, your application will do only one thing and will do it well, being all this time on one screen. But you are not able to decide anything for the user or even eliminate the choice, and you leave the choice to the user to the user.
Design is the making of hard decisions in order to save the user from making decisions.
Yes, well, navigation is necessary for most applications, most sites, and the user, after all, is used to using navigation. We have to make some compromises. I absolutely agree. And I almost always make this compromise and implement navigation. However, I am ashamed of you too.
Three truths about the process
Not all parts of the application are equally important. There are some things you should do first, some things you should not forget, and some that can be completely ignored.
5. Content is good, UI is bad
My first UX job before the UX concept was formulated was the Information Architect. This is still the most important work that is on any project. Things have names and must be named. Identifying names and verbs is the most important part of UX.
Content is the solution. If you do not design content, you design problems.
Every time you create frames with Lorem Ipsum, you insult your users and abuse the trust of your client. And also sabotage yourself.
Loremipsitis is bad, believe me, I saw a photo.
When you are not able to deal with the actual content, but focus on designing frameworks that are independent of the content, you actually create a barrier between the user and their goal. Stop immediately. Design content and you will most likely cope with the task automatically.
6. Procrastination is good
Make the sitemap and navigation last. Actually, don't do them at all. Start with the most important objects on the screen: with the one that helps the user to achieve his goal. All the excess time and budget should be aimed at making this screen perfect. Focus on every detail. Spend all the time polishing each pixel. Do not deny yourself the pleasure to enjoy every minute of development.
When the deadline comes or the development budget ends, your client / boss will be very angry, will scream at you that you have not done the rest of the bullshit that they wanted to cram into the user. Be dumb, apologize and earn the reputation of one who will never finish anything ...
Fail to plan so as not to design unnecessary parts.
Let's hope that all unnecessary garbage will be delayed until the next version, and the user will enjoy a clean product until you are fired, and the one who replaces you will spoil this ideal. There is no shortage of UX designers on the market who do what they are told and what is expected of them. That is why there are so many substandard products. Do not be one of them.
7. User Tests Kill Children
User tests are something incredible, a well-known fact. No matter how incredibly smart you are or how good your interface is. Ten minutes of user test in the early stages of a project can protect you from failure at the end of the journey.
User tests they rule. If you don't make them, you are an idiot.
However, user tests do not free you from the need to be smart, work, sweat on every little thing and go through a crazy, tortuous, bizarrely amorphous design process. You must still be a genius. And this is especially true when you are developing an innovative solution or products.
When it comes to innovation, users can be evil, dull-minded, short-sighted, vain, stupid, etc. And this has to be tolerated.
User tests for new ideas sucks. If you make them, you are an idiot.
When you have a great new idea, it begins its life with a fragile fetus, barely breathing. It needs nurturing and tender care in order to turn into a fully formed innovation that can stand firmly on its own two legs and withstand the careless handling of mercenary users. User testing of a new idea as a testing of a new lamb. It ends badly, both for the idea and for the lamb. So don't let your idea go to the uninitiated ... but only until it is ready.
How to know that the idea is ready? When you worked on it for a long time, you begin to see significant shortcomings: the problems that lie in how the idea works in general, and not how to combine it all with the existing ones. When an idea starts to work close to how you have conceived that you yourself start thinking about alternatives - it's time to check.
Two programmer truths
You may think that the coders error is not your fault. True, but still it's your responsibility. Just like sending a message that will never be received, a design that will not be understood is a waste of time. You must understand your audience, and your audience - programmers. They are strange animals, but in the end you too.
If you take good care of the dev department, the developers will make you rich and famous.
Learn how to code, actually it’s time, but until you did, here's what you need to know about programmers:
8. Programmers learn from horrible examples.
Developers do not explore well-designed applications and sites to find out how they were created. They spend their time learning with the help of demos and guides written by other coders, trying to explain complex coding concepts using contrived and funny examples.
Programming tutorials teach the worst UX practices.
They do not think about the real application of these examples. They do not think about the UX of these examples. They do not care whether these examples will lead to positive results in their fictional scenarios.
Thousands of developers are learning their craft, blindly implementing overly simple, poorly designed, stupid scenarios. They develop their applications with a few clumsy forms and hundreds of hours of insane tutorials. So maybe you should be a little more specific with your specifications?
9. Programmers love absurdity.
Programmers have to worry about things that no normal person would think about. You can put the Last Name field in your design, but the programmer will have a hundred alarms:
• What if a person does not have a last name?
• What if the last name is expressed as a mathematical equation?
• What if the last name is longer than 255 characters?
• What if the last name contains tabs, multiple paragraphs, non-breaking spaces, emoticons, parentheses, commas, single and double quotes?
• What if the last name changes over time?
For any normal person, these questions are absurd, but not for programmers. For the designer, this means that he should keep close to the programmers, understand them as best as possible in order to anticipate such anxieties, and keep them from completely insane.
Source: https://habr.com/ru/post/306088/
All Articles