Decision-making: A UX designer's point of view

Antonio Dell'Ava, Francesco Strazzullo • Interviews With Experts • Feb 02, 2023

Francesco Strazzullo interviews Antonio Dell'Ava

When does the collaboration between devs and UX designers fail? When they don't work closely from the beginning to the end of a project - as simple as that.

Francesco Strazzullo interviews Antonio Dell'Ava, a developer-turned-UX-Designer. The interview is taken from Francesco's book titled Decision-making for Software Development Teams.
Let's explore the UX side of decision-making when it comes to designing good software products.

Francesco: Hi Antonio! I’m thrilled to interview you, so now I have the opportunity to thank you for contributing to the book by writing Chapter 5 of the book. Before starting with the questions, would you tell us something about you and your work?

Antonio: Hi Francesco, thanks for inviting me to contribute to the book and also for this interview. I am a front-end developer with a background as an interaction designer, but I’ve always loved to code. I’m also interested in agile methodologies and decision-making. Since I was very young, I’ve wanted to know about everything. I’ve been a general specialist from the beginning. So, even though my main activity is coding, I love to wander in different fields. In my free time, I love cycling and, in particular, adventures by bike.

Francesco: In your chapter, you explained the importance of UX design for developers, and your dual nature is perfect for exploring the communication structure between developers and designers.
Many software development teams struggle to work with their UX designers, and sometimes this results in a lot of rework on already-approved UI designs or discovering some UX errors only during development.
In your opinion, why does this happen so frequently?

Antonio: The number one reason the developer-designer collaboration fails is that the design team is present only at the beginning of the project and then disappears.
You will have nothing but bad experiences with a UX group isolated from the team. Equally, you will have nothing but bad experiences with an isolated dev group.

Suppose we want to minimize the amount of rework on UI during development. Even if we have already created a high-fidelity prototype of the entire system, the design should be iterative. We need the designers to continuously update our best idea with our discoveries during our exploratory journey.
Secondly, we should keep in mind that the ownership of every outcome (UI prototype, code, whatever) is shared among the cross-functional team.
There is no “designer job” or “developer job” because none of them is enough to provide business value by themselves. They are just helpful activities in a software business. When we focus only on our personal activity (the perfect piece of code or the perfect UI design), we lose sight of the business value.

This does not mean UX designers and developers should do everything together. And at the same time it does not mean UX designers’ and developers’ efforts should be immutable.
We could alternate between different instruments (like flute and electric guitar in The Good the Bad and the Ugly’s main theme by Ennio Morricone). What really matters is the resulting melody.

To summarize, what I can recommend is:

Work in cross-functional teams where designers and developers collaborate from the starting point until the end of the project;
As developers, we should try to pay attention and be proactive during UX design activities. On the other hand, we should involve designers frequently during our development work;
Alternate small steps of design activities and small steps of code activities, where designers and developers share the ownership of the outcomes;
Focus on the “rightness” for the business value, not on the perfect code or perfect design;
Developing a mutual understanding and a shared feeling is, in most cases, more important than being individually smart and skilled.

Francesco: I totally agree with you, but what can a developer do when this is not possible? I witnessed a lot of companies where UX is a silo for several reasons, and sometimes developers do not have the power to change their organization.

Antonio: Yes, developers are not always in an ideal situation in the real world. One thing that can help in these situations is to learn how to collect valuable data in a complex scenario. Knowledge is a social matter. No one can see an entire big problem alone. To complete your puzzle, you will always need to look for someone else’s opinion (who holds another point of view). That’s why a stakeholder interview is the number one skill a developer should nurture.

A stakeholder is anyone who is in some way close to or involved in the project. It could be a manager, a salesperson, someone from technical support, or simply someone who knows the domain very well. In some cases, a stakeholder could also be one of the users (especially if the software is an internal tool, not something “customer-faced”). But in general, it is usually someone accountable to say “yes, this solution could work” or “no, this solution from my perspective is wrong”; not someone who can give a final yes or no, but someone who can influence this decision.

So why is interviewing them always a good option?

To see the problem from another point of view;
To get new data and insights;
To update the data you already have;
To share the vision;
To build trust.

Stakeholder interviews cannot replace UX, but they can help gather data about the users without anything else.

Francesco: Ok, can you share some instructions on how to conduct an effective stakeholder interview?

Antonio: Sure, here are some instructions for developing an effective interview.

Preparing the interview:

Make a list of the questions you have;
Schedule it in advance when the interviewee is available and relaxed;
Communicate how much time the interview will require.

Introducing the interview:

If necessary, introduce yourself and ask your interviewee to introduce themselves and their role;
Explain the interview goals;
Start with a warmup, for example, a trivial question to put the interviewee at ease.

Conducting the interview:

Maintain a Master/Apprentice pattern where the interviewer asks questions about the key points to learn the activity;
Encourage storytelling;
Be a partner, not a guest.

What to collect:

Tools used;
The tasks to be accomplished;
The activities needed to achieve the tasks and their order;
Recurring sequences of actions;
How the work is organized around the software;
User roles, hierarchies, and organizational practices;
Policies followed, both explicit and implicit.

Keep in mind that not everything has to be discovered every time. There are well established principles about usability.
In particular, there are easily-avoidable errors that developers frequently make. Knowing a few guidelines is enough to improve the work drastically. The below list, created considering the developer mindset, contains elementary principles that quote, summarize and interpret the most well-known heuristics and usability concepts (Nielsen, Krug, Norman, and so on).

a) Use the user’s familiar language, not the developer’s language.
Date and error messages are good examples.

b) Give useful defaults.

c) Offer help in context.

d) Don’t stop the flow at the start.

e) Convey important information with multiple UI elements, not only with a single text, color, or icon.

f) Prioritize and organize information, being sure to keep the main action visible; do not have different UI elements competing for user attention.

g) Always provide the context.

Francesco: Perfect! This is an excellent explanation of how to build an effective stakeholder interview. Thanks for all the valuable insights! If our readers want to deepen their knowledge about these topics, do you have any books or articles to suggest?

Antonio: Sure, this is my list:

- Steve Krug - Don’t Make Me Think

- Donald Norman - The Design of Everyday Things

- Jakob Nielsen - 10 Usability Heuristics for User Interface Design

Francesco: That’s fantastic, thank you very much!

Antonio: You’re welcome!

Foto di David Travis su Unsplash.