5

Designers are the hidden stakeholder you forgot about

 1 year ago
source link: https://uxdesign.cc/designers-are-the-hidden-stakeholder-you-forgot-about-4439a6e2f2da
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Designers are the hidden stakeholder you forgot about

Design critique can go wrong. What to do about the overlooked designer stakeholder, explained using a real scenario

Two different colour doors representing the comparison of A or B
Photo by Robert Anasch on Unsplash

Designers often deal with stakeholders and many teams cross-functionally. But what’s it like to deal with your own kind as well? I mean, the designers in your team.

The story goes like this

It all started with the question ‘design A or B’ which you often see splattered across LinkedIn.

Several months ago, a designer (let’s call her Alice) asked for feedback by posting on a slack channel of a colour change to the progress bar component. Asking whether we should stick to blue or change to indigo.

Other designers (Bob and Charlie) added thoughts with their colour preference out of the two. Indigo is their choice.

Then Darren chipped in on how it could be complicated to change the design system tokens that are being used across the board.

There were back and forth comments going on in the thread, emphasis on creating a new token to include the new indigo colour or to choosing an existing token to reuse and so on. The debate goes on with the designers talking about the complexity of implementation vs aesthetics.

All opinions are valid here. Darren had a fair point and I related to that. As for me, it’s also about the user experience. The usability. There was no context on the colour suggestion. I wanted to understand why we want to change this above other priorities we are facing in the backlog. Whether we had conducted research to have in hand in order to understand why and to prioritise this work if necessary.

So, I said… “Although indigo looks more subtle than the blue, my only questions are what is the reason to change this from a UX perspective? Are users having difficulty seeing it from accessibility POV? I think if we can get some data i.e see what users think, will help us prioritise this accordingly.”

Bob replied… “It’s an aesthetic issue. As designers we lose something important if we lose sight of aesthetic beauty and the art of our craft.”

You can probably tell Bob is a strong visual designer. In fact the team is full of strong visual designers. Anyway, I found this very interesting it was a fair point. To me, this comment sounds like the focal point is the look and feel, to improve the UI. However, it’s not what I am really asking here.

I then said…“What I am trying to say is, if we have some data to understand why we should do this from a user’s perspective rather than look and feel and to help prioritise this into the backlog of some sort. So more of a data-driven approach, as it can be high effort in the DS tokens.”

Bob didn’t respond after that. Alice (the author of the post) also didn’t respond to my questions and that’s okay if they didn’t have the answers at hand.

“Some things can’t be measured”

Eric (the head of design) finally responded to the thread with“some things can’t be measured”. That was it without further context, nothing else.

Charlie reacted to his message with an emoji in agreement.

I was confused when I read this. I don’t agree with it because:

  1. The statement discourages the focus of being data-driven and research-led.
  2. You certainly can measure this, what about the points I raised earlier in the thread?
  • Why should we change the colour?
  • What are users doing, thinking, feeling and saying about this colour of the progress bar?
  • Is it because of accessibility reasons?
  • What is the heat map and click rate telling us?

As designers, you should always ask why and be curious in everything we do. To gather as much initial data as possible to inform us to make decisions. Of course you can go off assumptions to test as well.

We left it as that. In the end, the colour of the progress bar remained blue.

Two designers sharing work for feedback.
Photo by Brooke Cagle on Unsplash

Conclusion

This is just the tip of the iceberg on what goes on in the tech industry, the workplace we are all in. Debates like this, especially within our own teams aren’t talked about enough to help others have a voice, to constantly ask why, to challenge one another, and to see what the outcomes of debates looks like.

I want to remind designers that healthy debates like this are great. Even though you disagree with the decisions made or what’s been said. As long as you have said your piece, being heard, stood your ground and fought for it, that’s enough. Because the next time, the team will listen. For extreme scenarios where you’re constantly not being heard, find a new gig that values you and your views.

I hope by sharing this story will help you in situations you may fall into. Remember that at the end of the day, you are helping to solve problems for the users and the business. Get into the habit of asking why. Perhaps try asking the Five Whys to dig deeper in the things we design for, or if something you have tested failed.

If you had a similar experience within your design team, I’d love to hear it. Let’s spread the positivity of healthy debates so other designers can grow.

Thank you for reading. If you enjoyed this, please share it and follow. You can also reach out to me on LinkedIn Simon Hoang.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK