- Step 0: Know the business importance of UX-driven questions
- Step 1: Show social courage
- Step 2: Be open and accept uncertainty
- Step 3: Lead by example
Imagine a thousand failed digital products. You can go back in time build them from scratch – but this time, you double the UX budget for 500 of them, and the other half gets double the development time.
Which group will perform better?
I bet more apps will come back to life in the first group. Most digital products usually work well at the technical level; businesses fail when even the best-performing functionality is of no use to anyone, meaning it doesn’t meet the real needs of users or is sufficiently intuitive.
So, even though User Experience is often viewed as strictly a visual or graphical role, I firmly believe that designers hold substantial power that directly impacts whether an app succeeds or fails.
Let’s talk about this power.
Step 0: Know the business importance of UX-driven questions
When handed a set of functionalities to design, a designer's first task is to ensure they align with the software's core goal. In Phase 0, the designer must validate that their work satisfies users' needs. After all, that's the essence of custom software products (or any products).
During the initial software development phase, the designer asks the product owner questions ranging from “Why is this button necessary?” all the way up to “What makes this feature important for your users/your business?”. In theory, all agile team members should be empowered to ask those – in practice, I would say the brunt of responsibility falls and maybe even should fall onto designers’ shoulders.
These questions carry substantial business value. They steer development and align the app's business goals with the design process. With a relentless pursuit of user needs and ensuring that every design decision has a purpose, the application stands a better chance of meeting user expectations and driving the business forward.
Step 1: Show social courage
Such basic inquiries are often seen as a nuisance. Many product owners aren't open to addressing these questions either.
Designers must repeatedly exhibit courage and confidence in their expertise to pose these questions. They should also have the backing of their organization, which should provide support in case the product owner expresses any doubts.
The product owner may, for example, get angry because they feel that the designer is undermining their knowledge. They may also get impatient because they have already answered similar questions dozens of times – but if the answer is insufficient, the designer should press on.
The creators of the U.S. Constitution built their most crucial addendum – the First Amendment – specifically to protect against prior restraint, a form of the chilling effect that stops a citizen from uttering a potentially controversial statement in fear of (government) reprisal.
Designers should take note and feel empowered to be a well-meaning pest at every turn.
As a project manager, I ensure designers feel allowed to get the answers they want without fear of possible professional repercussions. You should too.
Step 2: Be open and accept uncertainty
Yes, there comes a point where you have to sacrifice dearly-held design principles to execute a client’s decision. Hopefully, you have hired with social skills in mind – and you can trust a designer to feel when they reach a wall that they will not pierce.
There is a small but loud subgroup in the design profession of principled apostles who find it hurtful when someone demands elasticity from them. This always surprises me – going beyond canon should be fun for a designer – after all, why are Baymard, Don Norman, and Nielsen necessarily correct?
In my career, I've noticed that the client and their unshakable faith in their assumptions is as big a challenge as a designer mindlessly believing in certain design principles. Designers are only sometimes as open to feedback as they like to say, and they tend to categorically reject suggestions if they do not fit into some design canon.
Why not put your heroes to the test?
That’s what I love about user testing. These sessions often surprise us, revealing the unexpected ways users navigate through apps. The more tests we carry out, the more I realize that users often interact with apps in ways that aren't described by any UX principles. Colloquially, users can be raccoons on meth. Raccoons that are paying clients, that is.
There's absolutely no harm in admitting during user testing, “I see how users interact, but I'm not sure what that implies – I may have to blow through a heuristic or two”. Sometimes, we must make peace with the unpredictable nature of human behavior and be open to the unexpected findings that UX research can bring to light.
That’s why flexible minds make the best designers. Being able to weave together shreds of knowledge from the weirdest of places makes this job such a challenging daily puzzle. Enabling such work is a privilege I thoroughly enjoy.
Step 3: Lead by example
The final step is by far the hardest. How to gain such (seemingly) far-reaching trust and credit, to be the bringer of discomfort to an important meeting with a pointed question?
That’s where the design ops comes in – a tool set that is the best booster of a designer’s status.
From my observations in software development companies, we often put the cart before the horse, resorting to top-down evangelization. Designers educate developers on heuristics and dictate their operations, emphasizing particular system displays or advocating for simplicity and accessibility.
But in my experience, this method falls flat. Eventually, it leads to disregarding UX values, with everyone marching to their own beat.
To successfully embed UX, you, dear designer, must start with yourself. Show, don’t tell. Treat every task, even the smallest, with the kind of meticulousness that good developers are known for:
- Provide detailed handoff instructions – an orderly set of links, designs, and descriptions. Be proactive in perfecting requirements.
- Use clear language to avoid back-and-forth questions. Sit down to explain the design and product logic to developers.
- Keep your files and folders orderly and logical. Never mix work in progress with accepted designs. Make it easy to connect a mock-up to a user story without asking.
In essence, practice design ops; an approach emphasizing the processes, practices, and tools required for efficient, effective design work. Work in such a manner that if you're out sick, a replacement designer wouldn't have to spend half the day deciphering the page structure on Figma. Your work-in-progress should be as organized as Jira or Conflux.
When developers see you taking your work seriously, they'll start to respect your UX. The ball is entirely in the designer's court, so rather than displaying Dieter Rams quotes on the wall, demonstrate the value of design through your daily grind.
And it's truly worth it. After all, uncovering the business essence of products is a rewarding mission that elevates the designer's role beyond mere graphic design.
Good luck.
