Imagine that you are a product manager of, say, a website builder. And you constantly receive requests from clients: “Why don’t you have a“ Save ”button?”, “Copy blocks from one project to another”, “I need a paper clip, when will it be?”….

Are you going to implement them or not?

Let’s figure it out. The wishlist usually comes from users in its raw form: it is formulated superficially, reflects only external “symptoms” or is generally related to the problem only indirectly.

And that’s okay!

From experience, customers ask for a feature if:

1. Have become accustomed to the functionality in another system (for example, there is a repost in other social networks, but not in yours).

2. Feel uncomfortable (do not control what is happening, expect one thing and get another) and try to figure out how to avoid it. They offer interface solutions based on their own life experience.

How to deal with the first batch of requests is up to you. This is directly related to product vision and positioning. How much you want to be similar to your competitors, what functionality do you think is necessary, and what is superfluous.

But the second half of the wishes concerns the UX of the current product. Is it convenient for users inside, is it clear what and how to do, can they solve their problems, are they satisfied with the result.

Are these requests important? Yes! Do I need to do something with them? Of course! But the irony is that if you do whatever the customers ask, you can completely confuse the product. Before rushing to fasten something, you need to think with your head, and why they ask for it, why clients feel bad without it. Thinking like that often leads to useful ideas 🙂

Any available methods will do: from discussing possible reasons in a team, “5 Whys”, a Metrica webvisor to full-fledged UX testing on live users.

For example, your editor knows how to save changes automatically, but clients ask for an explicit Save button. Does this mean customers prefer manual save over automatic? I doubt it. Most likely, this means that customers are not sure whether the system has saved the document or not and want to personally control this moment. The problem will probably be solved by making the retention indicator more visible (bigger, brighter, in the right place, add animation …).

Making an indicator – looking at the reaction. If there are no more requests for the “Save” button, we are great. If nothing has changed, we think further.

What annoys them

Imagine that you are trying to get something out of an inattentive employee. They entrusted him with the task – he planted mistakes, did not take into account some of them, and forgot half of them. You get angry and come up with ideas on how to make it work better – you suggest creating a checklist, writing a cheat sheet, learning how to use the calendar …

This is exactly how clients behave when fighting an application. They are uncomfortable, they are angry that the system did not save the change, did not warn about something in time, they get irritated and scold her for being “stupid”. And then they themselves try to offer a plug – a solution for each specific case based on their experience – what they saw elsewhere in a similar situation. This is where Wishlist grows in the “I want a button like this” style.

They want magic

In fact, clients don’t need any buttons. They just want the system to behave like an intelligent, delicate and unobtrusive person-assistant – she remembered everything, knew everything, promptly suggested, took into account the context, and used common sense. So that she can delegate the task and be sure of the result.

Ha! Wow “simple”! They would have tried to do this themselves. But in general they are right, the ideal system should be like that.

Only then will there be value in the product, when it turns from a dull blank into something that helps people, and is guaranteed to save them from mistakes, isn’t it?

People get used to good things too quickly.

Smart inventions that make life easier are constantly appearing around, and people are getting used to the fact that much can be done easier and increase the requirements for things around them (especially information systems and digital devices).

Imagine that you bought a new electric kettle and found that it does not know how to turn itself off when it boils. 20 years ago that was fine, but now such a kettle simply won’t survive on the market.

With the same save button – before, applications did not know how to save anything themselves, and people developed the habit of constantly pressing Ctrl + S (I still press it myself, even where it is not needed :). Modern systems store user-generated content automatically. It is comfortable and natural. Customers are used to this and expect similar behavior from your application. And if they are not sure that your system is saving everything on time, then they try to take control of this crucial process and ask for the “Save” button.

What to do?

1. Listen to users – what they complain about, where they are indignant. Ask for feedback. Paying special attention to dissatisfaction is almost always an unjustified expectation – the client thought that the system should behave this way, and it behaves that way.

2. Do not rush to do what you are asked to do right away. Trying to understand what they really want is to look for a problem. Study, ask open-ended questions, dig, watch what they do and where they stumble.

3. Do not hope to solve the problem once and for all. Try solutions and see the result. If the result is unsatisfactory, try again and again. Nobody said it would be easy 🙂

Source: olgashavrina.com