10 ways to piss off your designer without even trying

Common situations at startups and established companies that frustrate designers and make them seem hard to work with to engineers and product managers.

Designers can be difficult to work with if you are unaware of the challenges that make their jobs impossible. The challenges might be unavoidable, but understanding and acknowledging them may transform a troubled relationship into an understanding, collaborative one.

(You can use these to prank your favorite designer, but I do not recommend it unless you have a great relationship.)

#1: We don’t have the budget or time for user research.

This common situation happens at both early-stage startups and established companies. Sometimes, competing priorities create budget issues. Sometimes, inertia. A designer asks for user research when there is a gap in understanding. Unless they focus purely on visual or graphic design, designers can't do their best work without understanding the user.

Asking designers to rely solely on feedback from leadership or the rest of the team is insufficient and can be misleading. All opinions are valid without user feedback, but the highest-paid opinion carries the most weight. Accepting feedback from leaders who do not have design expertise forces designers to create what they believe to be subpar user experiences, making it difficult to do their best work. User research can be daunting, but is essential for finding product-market fit.

#2: I built the UI according to the specs.

Engineers can spend a lot of time struggling with browser and platform idiosyncrasies to build the high-fidelity mocks that a designer creates. They wrangle with unseen challenges to meet strict deadlines and still take the time to fix awkward interactions that they spot in the designs. Yet when they push the code live for review, their designer creates a laundry list of additional UI fixes. These fixes don’t impact functionality and would take more time than might be available to complete.

When I was a front-end engineer, I corrected design mistakes during implementation when I thought there was a design oversight; I didn't realize that I was wasting time and creating additional work because the designs were purposeful and optimal given the constraints. Later, as a designer, I spent long hours perfecting interactions, struggling with the edge cases, incorporating user and team feedback, and ensuring that UI elements were cohesive, elegant, and intuitive. I thoroughly documented the details to make implementation easy, yet when the UI was built, it looked like someone had thrown up all over it — it was almost the same but, to me, glaringly not.

All the elements were functional, but the proportions, spacing, and many other details did not match the mocks I had toiled over. I was frustrated to have spent all that time and effort to perfect something, only to not have it be built to spec. I was upset until I realized that my training as a designer enabled me to see details invisible to many engineers (including me when I had been an engineer) but are essential to the experience. Designers insist on the details as fervently as engineers insist on tabs versus spaces (or the other way around).

#3: This is how I would use it.

Teams that are not in the habit of soliciting user feedback rely on personal opinions to evaluate designs. While they should always feel comfortable giving feedback on UX, they are not the end users. The team does not realize that their opinions are just that — subjective opinions — so it exerts pressure on the designer to make changes.

Imagine how jarring it might feel if code reviews were a communal activity where many team members in other (possibly non-technical) roles had free reign to give their opinions. Feedback from people without an engineering background would likely be misguided, confusing, or blatantly incorrect. However, designs are more approachable by lay people than code, so designers are subjected to this treatment of their work.

In addition, the ratio of designers to everyone else is skewed, so there might be just one designer explaining design decisions to 10 or more people. Multiply that by the number of UX interactions and UI elements, and the experience quickly becomes overwhelming. Endless debates ensue and are settled by leadership dictating how things should be. The subtext in these conversations is that the designer cannot be trusted to make UX decisions despite their specialized training and expertise.

#4: You need to change the design because team member X is right.

When the designer listens to but rejects a given team member's suggestion, that person may escalate the suggestion (e.g. to the founders in a startup or a senior leader). This terrible dynamic sets the precedent for resolving disagreements by pulling rank, leading to a frustrated designer and questionable user experiences. Design decisions based on a single opinion are dangerous, even when the suggester has expertise (some team members claim expertise as justification regardless of whether or not they actually have it). To override design decisions is to strip a designer of agency and undermine them. Design mistakes should be sussed out with user feedback. So when you disagree with a design decision, it’s more productive to advocate for user research or usability testing than to wear down the designer.

#5: My family thinks we should design it differently.

No one says this, but that’s effectively the message when they proffer unsolicited feedback from family members. Debating design decisions is hard. It's impossible to do while also trying to avoid accidentally insulting someone’s family. This is especially bad if that person is the CEO or founder. It puts the designer in an impossible position and cripples their ability to respond unless they are highly adept at diplomacy. The seeming disregard for years of training and experience creates friction.

#6: Can you make it look like this?

A product manager working under tight timelines, shifting priorities, and an overwhelming workload might feel there is no time to consult with a designer early in planning and instead sketch out some rudimentary wireframes of a pre-conceived experience and ask the designer to quickly convert them into high-fidelity mocks. A designer who has not been on the project will not have enough information about the problem or the target user and is now denied the chance to brainstorm and evaluate alternatives. When working with a user experience designer (aka product designer), this assembly-line setup discounts their skills and asks them to simply push pixels (about as much fun as being a “code monkey”).

#7: Why don’t we add a tab?

Tabs are often a fast and easy shortcut to adding functionality without disturbing the existing design. But they are also the first step to a cluttered UI in a graveyard of features languishing for user attention. Tabs are expedient and can be changed later, but that follow-up work often falls off the to-do list when priorities change. Well-intentioned shortcuts lead to a confusing experience for users, and designers will bear the judgment for bad design. Asking for a tab isn't always bad, but it implies that designing experience doesn't require thoughtfulness and consideration, effectively devaluing the contributions of a designer.

#8: Can we make it stand out more?

When feature adoption doesn’t live up to target metrics, the team may question whether users know the feature is available. They may suggest visual changes to make the feature more visible rather than reflecting on whether or not the feature provides enough value for the user to use it. The feature may be buried, but no number of onboarding wizards or callouts will entice users if it does not fit their workflow. A designer may advise revisiting the value proposition, but they may be ignored if the team is already convinced of product-market fit. Debates about UI treatments and visual design will have little impact if the team is mistaken about the user needs. Under pressure, the designer yields to team opinion and creates changes that eventually prove fruitless.

#9: This article/book says we should design it this way.

It is always heart-warming when a non-designer cares so much about user experiences that they read articles or listen to talks about design and enthusiastically bring them back to the team. They may then excitedly recount a wonderful lesson they learned and translate it into advice for the designer that effectively means: "Create user-friendly experiences.” This is the equivalent of telling an engineer to write high-quality code. The designer will already know core design principles. A non-designer trying to educate them on something fundamental is likely to be interpreted as questioning their expertise.

#10: Can you do user research, interaction design, visual design, branding, some coding, and marketing?

Designers in startups are often the only ones doing all of the above. They are responsible for interviewing users, designing visuals, drafting copy, creating user flows, developing marketing collateral, and likely more. Each of these responsibilities is a discipline with its own challenges and can quickly lead to burnout if undertaken by a single person. This versatility in a designer might be treated as common and expected, but the designer is rarely compensated for what, in reality, are several roles. Wearing different hats is necessary for anyone at a startup but shouldn't be taken for granted.

Each of these situations is frustrating, but the weight of it all can make a designer’s work unbearable. So when the designer you work with is upset (maybe even act like an a-hole), consider which of the situations above they might be struggling with. Having honest conversations when difficult situations happen can resolve many disagreements, leading to appreciation and more effective collaboration.