The design decisions that you know are right
Were you ever in a situation where you felt like your expertise and judgement were overruled by a stakeholder who knew little about design?
Did you ever feel like an accessory to the project? Someone who just tags along?
I think that we’ve all been in this situation at some point in our careers and it can be frustrating, you might feel trapped.
So, how do we end up there in the first place?
Usually, this kind of situations happen with our stakeholders who are non-designers and whose expertise resides in a different area.
But I’ve found along the way that most of the issues or concerns that our stakeholders bring to our attention are often just a matter of misunderstanding or miscommunication.
When we train to be designers we’re mostly told that we should be proficient in: Photoshop, Illustrator, XD, Sketch, Figma or any other tool out there.
But I believe an essential thing that makes us better designers is the ability to explain the “why” behind the solutions we propose. And if you’re lacking this ability, there is a high chance of ending up on the losing side of the argument, forced to make some changes you will not agree with.
The first failure
The first big project I worked on was a web application which manages and stores documents that people in the medical laboratory need to have fast and easy access to. The UX was done and approved and it was time I presented how the UI will look like, so I joined the meeting, shared my screen and then started iterating on the obvious:
“And this input field is next to this dropdown and the buttons are blue, this image is in high resolution and it’s square.”
And of course, they didn’t like it.
It was the wrong way to go in the first place, because I didn’t tell the client the reasoning behind why is that button blue or why I chose that layout. If I had to go back and do it again, I would start explaining the visual hierarchy and why it is important: because it emphasises the information architecture by bringing important things into focus.
Why is that button blue? Because it goes hand in hand with their branding guidelines and because it needs to be a focal point for the user, to emphasise the main action on the page.
You’re enough!
Many times, your solutions getting rejected makes you doubt your skills, or gets you angry at this other person who knows little about design.
We may not like to admit it, but it does makes us doubt our skills. It triggers our impostor syndrome and all the fears that come along with it.
But the truth is you’re smart, you know what you’re talking about, because you are an expert in your field.
What you need to do differently is adapt your communication to your audience.
Design solutions come in all shapes and sizes from the complex and analytical to the simple and aesthetical, and if communicated properly, they’re capable of changing how someone thinks about your solution and design in general, both now and in the future.
How to become a better communicator
Once I realised that one of the most crucial tasks I have as a designer is to communicate my ideas/solutions to the people I work and interact with, this is what I tried and worked for me so far in my attempt to be a better communicator.
The first and most important thing of all: Be a nice person, or at least try!
We are more willing to collaborate with people who prove themselves to be honest and open to new ideas. Talk to your developers, have some brainstorming sessions with them, it might surprise you how they can contribute to your UX solutions.
The second thing: Don’t just slam your ideas on the table, explain them with words the other person can understand. Adapt to their level of UX maturity.
You may come across people who have never worked with designers so far and you have to start from scratch by explaining what’s design, how it can help the project and what’s the ROI of UX.
Use storytelling, talk about your user’s pain points.
If the developers and the stakeholders can’t relate enough with the users, they won’t go the extra mile to solve their problems.
Talk about the challenges that your users face, about what happens if they won’t succeed in completing their flow.
In my trial and errors so far, I’ve discovered what works well are analogies to a real-life scenario that your audience can relate to.
Analogies
So, for example, I was working on this complex web application and my client asked that we remove the breadcrumbs from all the pages, to save space on the vertical. Obviously, it made a lot of sense for them to ask something like that.
To convince them of the value of those breadcrumbs, I went into storytelling mode and made an analogy with Hansel and Gretel:
Me: So you know how Hansel and Gretel used bread crumbs so that they would know how to find their way back home ?
Client: Yes.
Me: Well that’s the exact thing we’re trying to do here, help our users get back home and always be aware of where exactly they are in the application so they don’t get lost along the way.
Get them to empathise with your solution by creating parallels with something that they already experienced, in this case the prerequisite was that they needed to have read Hansel and Gretel at some point.
Be patient with developers, they’re nice people !
One of the things that I do as a designer on my current project is approve the implementation of the solution, so I basically check if the UX logic was implemented correctly, if the UI looks the same in 90% of the cases. If it doesn’t, it’s fine as long it won’t affect the user’s flow or create usability issues, you get the picture.
While doing this for my current project I noticed that a developer did not properly align all the elements on the right side, so each element had a different padding. I pointed this out, but he didn’t have an issue with the elements not starting from the same point.
Again, I went intro storytelling mode and I asked him:
Me:Do you have a book at hand?
Developer: Yes.
Me: Can you please open the book?
Developer: At what page?
Me: It doesn’t matter. Do you notice how most of the lines on that page start from the same point?
Developer: Yeah.
Me: Well, the reason why they all start from the same point is so that people can scan a page vertically.
It’s easier for them to follow and read the information if you give them a clear and well aligned vertical path.
Me: Imagine how frustrating it would be to read when each sentence on the page started from a different point. If we align them to start from the same point, this will improve readability.
This was the moment when it made sense for him why I was suggesting that he needs to do a few tweaks to his implementation and not because I was the pushy designer asking him to do it my way just because I said so.
So, I used something from his life experience to explain the risks of bad alignment and visual load. I got him to relate with our users.What’s the lesson here?
I think it’s good to stay away from complex explanations that use pretentious UX vocabulary. It’s the pattern that’s important here, not the fancy words (although we like them because they make us feel important and in control).
Build your story with the end in mind before figuring out the details in the middle. What’s your objective? What are the expected results? What are you trying to fix or improve for your users?
This approach allows you to reassess the solution whenever changes appear along the way. We have to reiterate our decisions to the client and constantly adjust in order to reach our objective.
So, for example if your solution is not feasible from a technical perspective or it takes too long and the client is not committed to invest that much time, COMPROMISE!
It’s easy to justify and adapt to these new limitations if you have your final objective in mind. What if that screen you designed can’t be implemented exactly how you envisioned it? Have a meeting with your developers, get them to empathise with the users by explaining to them the paint point you are trying to address.
It’s critical that we understand just how important good communication is to design. We have to turn those words into something that will enact change and compel people to get on our side. The way you talk about your design decisions is key to ensuring that you will always end up with the best possible user experience.
