Make the button bigger — or why designers and clients keep arguing
We share the same goals but still speak different languages.
Today most UI/UX designers know that before you start creating layouts of website or mobile app, you need to do research to study the users and understand the goals and objectives of the project. But there is still the “cargo cult problem”.
“During World War II hundreds of thousands of American troops poured into the islands from the skies and seas, many of “cargo cults” sprang up in villages in the South Pacific. The outside world, with all its material wealth, suddenly descended on remote, indigenous tribes. The locals didn’t know where the foreigners’ endless supplies came from and so suspected they were summoned by magic, sent from the spirit world. So, to entice the Americans back after the war, islanders throughout the region constructed piers and carved airstrips from their fields. They prayed for ships and planes to once again come out of nowhere, bearing all kinds of treasures: jeeps and washing machines, radios and motorcycles, canned meat and candy.”
Source
So do we.
Someone builds CJMs, someone writes user stories, someone goes to users with questions about problems and goals, but not everyone understands why they do it. The simple fact that design is problem-solving can be heard from every corner, but something still goes wrong.
The most popular answers to the question “why it was done exactly this way?” are:
- 1st place: that’s what my customer definitely wanted
- 2nd: all our competitors do the same
- 3d: why don’t you just leave me alone?
As you understand, these answers can’t be accepted. Except the third :)
“My customer asked me”
No, they didn’t. Let’s look at the case.
What the customer says: we need to make this button twice as big!
What the customer means: we have analytics system shown that there’s a user scenario which begins with this button and ends with the last step of the sales funnel. I think we should make this button larger so that more users can see it, and then there’ll be more traffic in the funnel.
What really happens: the cat says “meow”, the duck says “quack”, the customer says “make this button larger”. Everyone speaks in his own language, so the tasks of the usability designer is not only to hear what the customer says, but also to understand what he really means and find out how the customer’s vision corresponds to reality.
In our example, there is no data to prove that the button is somehow related to the desired result (conversion to purchase). So far, we know just the fact that there is a “button” → “something” → “profit” scenario. First we should check if the button is actually needed in this scenario. Perhaps we can change the script so the user can start with the second/third/penultimate step? Or maybe the user expected the button to move him somewhere else, so the next step of scenario are wrong? Then if we make this button twice as big even more people will be mistaken and follow an error scenario.
The only way to find out what the users really want and what they expect by pressing this button is to ask them yourself. Short “partisan” usability testing is quite suitable and doesn’t require almost any expenses. At the same time, we’ll find out if users have a problem with noticing this button (since the customer asked to make it bigger).
Now let’s talk about the designers who say: “I tried to prove to him it’s not a good idea, but he was pressuring me!”. Yes, it happens. If you were sure that you’ve found an easy way to increase conversion and someone tells you to forget it, you will insist, won’t you? At least, this is what it looks like from the point of the customer.
It’s a foregone conclusion if you say “I choose this decision because the customer asked so” — this means you forgot to ask him “why?”. Why does he want you to do this exactly? What goal does he really want to reach? The more times the question “why” is asked, the closer you get to what the customer really thinks about.
“But our competitors do the same”
Ok, benchmarking is a really good thing. But the fact that you were lucky enough to find a good idea doesn’t mean you haven’t to check that it’s the best option for you and it’ll work in your interface.
Google Chrome gained its popularity (inter alia) because they removed most buttons/options/settings from its home screen while other browsers had it at that time. Most services focused on working with text show all formatting tools at once, but Notion (and Medium, yes) didn’t do so and won. It’s possible your service/product will only get better if you do NOT repeat your competitors’ ideas.
Benchmarking does not end with finding and copying an idea. Then this idea must go through thick, thin and N iterations of testing, after which, if it’s effectiveness for you is confirmed, you’ll be able to answer not “because the competitors do so”, but “because we checked, and it suits us according to criteria a, b and c”.
So, what should a usability designer do when customer asks to give his idea a try?
- exhale
- ask “why?”
- and once again
- figure out the methods available to solve this problem / reach this goal
- choose the best one (it may be the way your customer proposed)
With this approach, you can get not just the most effective solutions for your product, but there will also be one less customer in the world who says “all these designers are never listen to what they are told” :)
