Let’s say you are a on the Gmail team.

You are tasked to address a repeated user request: users want to add labels to messages they send.

Since you are a trained designer, you ask more questions: Who is going to use this? why? when? and where?

You discover a common request — as users compose a message and just before they hit ‘Send’, they’d like to add labels to the message, rather than just the default ‘Sent’ folder.

If you are a  Designer

You probably already have some ideas (although some may be quite obvious).

You choose to add a button that will open a list of labels for users to choose from as they compose their email. You quickly mock it up and share it.

Here is how it may look:

If you are an OK Designer

You are thinking about reducing friction and automating parts of the task, maybe even using AI and a shiny machine learning algorithm.

“Let’s analyze the text,” you say proudly “and automatically suggest the BEST matching labels to users… users may accept label suggestions or choose their own,” and you hurry to mock it up.

Here is how it may look:

But if you are an  Designer

You may discover that the core reason users routinely ask for this feature is that they often need to find ‘lost’ messages in their overcrowded Sent folder.

As an Awesome Designer, you may even suggest NOT to work on this feature at all and instead focus on finding better ways to browse and organize sent messages.

And shamelessly you go home without drawing a single pixel today.

The paradox of user requests

Users are very clear with you about what they want, and at times, can be quite vocal about it. It is the Awesome Designer’s responsibility to dig deep and uncover the root cause that triggered their requests.

  • Bad Designer will satisfy user requests
  • OK Designer will ease the problem
  • Awesome Designer will eliminate the problem

So who do you want to be?



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here