We write software that will hate
No matter where you look, there are articles about customer loyalty, user satisfaction, intuitive interfaces and other things like that. Enough of that. Let's talk better about creating bad software, such, having worked with that, the user will hate this software, its developers, and its mouse with the keyboard at the same time.
I am a software engineer who has been developing commercial applications for more than five years. Over time, I began to notice that poorly designed applications can cause very, very negative emotions among users. How perfect the application architecture is from a technical point of view is completely unimportant here. If the program does not help the user to solve his problem, if it does not simplify his life and does not meet expectations - wait for a wave of negative. If this is exactly what you are trying to achieve, it means that the tips gathered here will help you bring your users to a white-hot.
But seriously, the purpose of this compilation is to draw the attention of developers to common mistakes, recall important elements of software projects and help in building healthy relationships with users.
')
Speed ​​is our enemy. It is impossible for an application to load anything in less than five seconds. And even better - let it be at least fifteen seconds.
Do not use, in any way, background processing of tasks. Let the user look at the empty fixed screen, not knowing what is happening, and curses everything and everyone.
Do users suggest adding a new feature to the program? Whatever it is, even if a request needs a couple of lines of code, answer this: "This is impossible." Do not even think about discussing such proposals with colleagues. Sew the user - and problems as it happened.
If the user got you so much stubborn, you can feed him with lengthy phrases: "This does not correspond to the functionality of our application", or: "I can not help you, these are the duties of another employee."
Any "agreement on the level of provision of services" - nonsense. It is perfectly normal if the system hangs tight every few minutes. And even better if we are talking about a program that, for example, is used for customer service. For example - at the checkout.
When a failure occurs in the workplace, one way or another fenced from other people's attention - this is one thing. Quite another - if your user can announce that the program is frozen, a queue of ten people. This will give him an excellent opportunity to publicly express all that he thinks about this "program."
If you are doing a project for a large company and are forced to constantly hold meetings with its representatives, spend all your meeting time talking about how wonderful this newest XYZ framework you are using. It is very important that your client does not have the opportunity to open his mouth, as a result, he will not be able to say any nonsense that his company needs some kind of new report there. After six months, start scolding the same framework for some random reason, saying that it was a mistake to choose it on the wave of unhealthy popularity. Again, this is very important - do not let the client talk, as he will certainly begin to ask about the report, a conversation about which you have been avoiding for a very long time and diligently.
If you follow the events in the JavaScript environment, then you understand what I am talking about.
The interface is a monolith. Something like asynchronous loading of individual elements is a harmful practice. All actions that the user performs, say, in a web application, should lead to a reload of the entire page. The position where the user was before, you do not need to remember. As a result, he will have the opportunity to scroll the page to the place where he did something, and see what happened.
Help, all kinds of "getting started", unobtrusively acquainting users with the basic features of the program - this is overkill. Your programs are so simple and clear that anyone can work in them without any problems whatsoever.
Just imagine how wonderful it is to enter data into a form, to be mistaken in some trifles, and, after sending it and reloading the page, see again the same form with empty fields. It is not your fault if the user misunderstood what to enter.
Never ask users what they think about the program or any of its functions. Remember - this is very important. Never. You are a genius, which in the whole world can be counted on the fingers of one hand. You are the beacon of programming. Your opinion is all that should concern you.
Let everything in your software be mysterious. For example, do not make any placeholder hints in the input fields. The user needs a program - he will guess everything. In addition, this approach has a pleasant side effect - on occasion, with the appearance of a professional, you can tell your friends about what kind of users your stupid users are.
Emails with reminders, text messages, push notifications, automatic download of new data from the Web - this is for lazy people. Your user should check everything himself. Waiting for a new message? No automation - he went to the right page, updated it, well, and then - as lucky. How often he will have to do it - does not concern us.
Your program is your rules, it is, among other things, a reflection of your vocabulary. If a certain average user doesn’t understand something, this is only his problem. Here are a couple of examples that should be guided: "Asynchronous request through a proxy browser", "Cryptographic salt."
Do whatever you want with the interface. For example, a floppy disk icon can be used to delete entries, and an asterisk as a logout button. Do not forget to record the process of working with your system using something like HotJar (and remove the user with a hidden camera). Got stuff for funny gifs.
The boot screen, and even better, one that lasts for a very long time is an indispensable attribute of any software. Even the simplest calculator should have this. It will allow the user to tune in to work with the program, to assess its capabilities and benefits in advance.
We hope the tips here will help you write a really disgusting software. As you can see, it is not so difficult. Although, it is quite possible that there will be such developers who will not follow our recommendations and decide to do the opposite.
Dear readers! What kind of “bad advice” about software development can you share?
I am a software engineer who has been developing commercial applications for more than five years. Over time, I began to notice that poorly designed applications can cause very, very negative emotions among users. How perfect the application architecture is from a technical point of view is completely unimportant here. If the program does not help the user to solve his problem, if it does not simplify his life and does not meet expectations - wait for a wave of negative. If this is exactly what you are trying to achieve, it means that the tips gathered here will help you bring your users to a white-hot.
But seriously, the purpose of this compilation is to draw the attention of developers to common mistakes, recall important elements of software projects and help in building healthy relationships with users.
')
Council number 1. The slower the better
Speed ​​is our enemy. It is impossible for an application to load anything in less than five seconds. And even better - let it be at least fifteen seconds.
Do not use, in any way, background processing of tasks. Let the user look at the empty fixed screen, not knowing what is happening, and curses everything and everyone.
Council number 2. Ignore suggestions and suggestions from users.
Do users suggest adding a new feature to the program? Whatever it is, even if a request needs a couple of lines of code, answer this: "This is impossible." Do not even think about discussing such proposals with colleagues. Sew the user - and problems as it happened.
If the user got you so much stubborn, you can feed him with lengthy phrases: "This does not correspond to the functionality of our application", or: "I can not help you, these are the duties of another employee."
Council number 3. Do not worry about application uptime
Any "agreement on the level of provision of services" - nonsense. It is perfectly normal if the system hangs tight every few minutes. And even better if we are talking about a program that, for example, is used for customer service. For example - at the checkout.
When a failure occurs in the workplace, one way or another fenced from other people's attention - this is one thing. Quite another - if your user can announce that the program is frozen, a queue of ten people. This will give him an excellent opportunity to publicly express all that he thinks about this "program."
Council number 4. Aim for the newest
If you are doing a project for a large company and are forced to constantly hold meetings with its representatives, spend all your meeting time talking about how wonderful this newest XYZ framework you are using. It is very important that your client does not have the opportunity to open his mouth, as a result, he will not be able to say any nonsense that his company needs some kind of new report there. After six months, start scolding the same framework for some random reason, saying that it was a mistake to choose it on the wave of unhealthy popularity. Again, this is very important - do not let the client talk, as he will certainly begin to ask about the report, a conversation about which you have been avoiding for a very long time and diligently.
If you follow the events in the JavaScript environment, then you understand what I am talking about.
Council number 5. Update entire web pages
The interface is a monolith. Something like asynchronous loading of individual elements is a harmful practice. All actions that the user performs, say, in a web application, should lead to a reload of the entire page. The position where the user was before, you do not need to remember. As a result, he will have the opportunity to scroll the page to the place where he did something, and see what happened.
Council number 6. Your software is easy, anyone can understand it.
Help, all kinds of "getting started", unobtrusively acquainting users with the basic features of the program - this is overkill. Your programs are so simple and clear that anyone can work in them without any problems whatsoever.
Council number 7. Form validation is none of your business.
Just imagine how wonderful it is to enter data into a form, to be mistaken in some trifles, and, after sending it and reloading the page, see again the same form with empty fields. It is not your fault if the user misunderstood what to enter.
Council number 8. Your opinion is the only thing that matters.
Never ask users what they think about the program or any of its functions. Remember - this is very important. Never. You are a genius, which in the whole world can be counted on the fingers of one hand. You are the beacon of programming. Your opinion is all that should concern you.
Council number 9. The more mystery - the better
Let everything in your software be mysterious. For example, do not make any placeholder hints in the input fields. The user needs a program - he will guess everything. In addition, this approach has a pleasant side effect - on occasion, with the appearance of a professional, you can tell your friends about what kind of users your stupid users are.
Council number 10. No reminders, auto updates and notifications
Emails with reminders, text messages, push notifications, automatic download of new data from the Web - this is for lazy people. Your user should check everything himself. Waiting for a new message? No automation - he went to the right page, updated it, well, and then - as lucky. How often he will have to do it - does not concern us.
Council number 11. Plenty of mysterious words
Your program is your rules, it is, among other things, a reflection of your vocabulary. If a certain average user doesn’t understand something, this is only his problem. Here are a couple of examples that should be guided: "Asynchronous request through a proxy browser", "Cryptographic salt."
Council number 12. Intuitive clarity is not for us.
Do whatever you want with the interface. For example, a floppy disk icon can be used to delete entries, and an asterisk as a logout button. Do not forget to record the process of working with your system using something like HotJar (and remove the user with a hidden camera). Got stuff for funny gifs.
Council number 13. The loading screen should always and everywhere
The boot screen, and even better, one that lasts for a very long time is an indispensable attribute of any software. Even the simplest calculator should have this. It will allow the user to tune in to work with the program, to assess its capabilities and benefits in advance.
Results
We hope the tips here will help you write a really disgusting software. As you can see, it is not so difficult. Although, it is quite possible that there will be such developers who will not follow our recommendations and decide to do the opposite.
Dear readers! What kind of “bad advice” about software development can you share?
Source: https://habr.com/ru/post/330596/
All Articles