Unlikely Blog: Lessons from new product development and beyond

10 ways to piss off your designer without even trying

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 — pitfall #1 in my post "Top 10 mistakes startups make in user research (without a designer)" — 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.

  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 (see pitfall #2 of "Top 10 mistakes startups make in user research (without a designer)"). 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, consider which of the situations above they might be struggling with. Having honest conversations when difficult situations happen can resolve many disagreements, but it is a learned skill to do so effectively. The teams that have learned how to do so through interpersonal communication training have found it to be pragmatic and immediately applicable, leading to more effective collaboration.

Feb 28, 2024 · 6 min read

Top 10 mistakes startups make in user research (without a designer)

The startups that I’ve worked with in the past have made common mistakes with user research. These mistakes were avoidable because they were known to designers, but these startups didn’t have in-house design expertise. I’ve also been at big companies with established design teams that made the same mistakes because Design was not a mature practice and was treated like a service org.

  1. Not having a budget or making time for user research.

    At early-stage startups, founders are often the only people to speak to potential users — most startups do not have the expertise or budget (it isn't a priority) to hire a researcher or a designer trained in research. Circumstances set precedents. What was regrettable becomes the norm. When startups do grow and gain the ability to do in-house research, the reluctance remains because the founders believe they already understand the target user. Their success (as evidenced by investments in their startup) buoys their confidence despite the lack of rigorous research.

    While the early team could share the responsibility for user research, talking to people is hard. Early-stage startup teams are often comprised of engineers. As an engineer, I never spoke to any users. It took a lot of practice before I could approach people to ask questions. Talking to users can be a struggle for anyone not trained in the process, even executives whose job is communication. User research is a learned skill. The team might be tempted to skip research out of discomfort or in the spirit of moving fast, but that may contribute to the startup's failure.

  2. We know our users because we are them.

    On the surface, a team may believe in the importance of understanding the target user and their needs but then err in thinking that more user research is unnecessary because they are the target users and can speak on their behalf. However, by working on the product, they already know too much to be representative. This can be tough to change if no one at the startup has enough experience or credibility to disagree with the people thinking about this problem the longest (especially the founders).

  3. Using surveys to determine the feature list.

    Well-intentioned teams that believe in listening to users can make the mistake of creating a list of features and then sending users a survey asking which ones they want. I have seen this multiple times. In most cases, the surveys are biased and can lead the company to draw faulty assumptions. Crafting unbiased questions is difficult if the team has not been trained. Surveys can be helpful if the team has performed qualitative research and uses them to falsify hypotheses. Otherwise, creating roadmaps based on survey results can potentially waste time and money.

  4. Pitching during a user interview instead of learning about the user.

    Startup teams are naturally excited about their ideas, so when they speak to users, they tend to sell instead. Their questions are variations of: “Would you use this?” In the face of such enthusiasm, people may say something positive to not disappoint. However, this derails the conversation and turns an opportunity to discover unmet needs into another data point for confirmation bias.

  5. Talking to only 4-5 people.

    Startups should be wary of talking to too few users and mistakenly applying best practices for usability testing to user research. Most common usability issues can be discovered by talking to 5 users. But that only applies to usability testing of a feature or prototype, not to exploratory user research. Usability testing determines if a user can complete a task, whereas exploratory user research is for discovering unmet needs. If the team is still looking for product-market fit and trying to understand potential users, talking to 15-20 people would be more helpful in uncovering motivations and patterns in their behavior.

  6. Treating user research as a one-time event rather than a continuous, iterative process.

    When teams invest in exploratory research, there can be pressure to get it right, especially if research is done infrequently. This mindset leads to disagreements. The research is unlikely to answer all questions, leading some team members to doubt its usefulness and validity. The purpose is to learn about user motivations and behaviors — complete agreement on the findings isn't the end goal. Research is often not comprehensive, as that would take a long time, so some gaps in understanding are to be expected. Ongoing user research reduces the pressure, ensures that the team has a shared understanding of the user, and helps them to iterate and test hypotheses, increasing the chances of creating something valuable.

  7. Not clearly defining the target user.

    Teams can make the mistake of assuming that a product is suitable for everyone. Anyone could use it, but not everyone will. The hope might be that the product will have a large user base. But, at the beginning, the team needs to be specific. Explicitly focusing on a user segment helps the team have a shared understanding of why they build and for whom. When the team allows the target user to remain loosely defined, team members may make assumptions, leading to disagreements about product direction and potentially building a mediocre product that no one wants.

  8. Being too literal in listening to the user.

    Teams that make changes based on what users say without understanding their reasons run the risk of undesirable outcomes. Building without understanding the underlying needs and motivations may miss the mark and create something users do not value. Users typically cannot articulate what they need (they may not know), so relying on their words for product direction can lead to disappointing results.

  9. Users do not know what they want, so don't ask them.

    Some teams understand that users cannot articulate what they need but mistakenly use that rationale to avoid seeking user feedback (citing Steve Jobs as inspiration for their approach). They build without validating their hypothesis and do not iterate because there is no user feedback. Months to years can pass before the product is available to end users. If the team is wrong about their initial hypothesis, they will have wasted significant time and money. Frequent evaluative user research helps teams to course-correct early and often. Users may not be able to articulate what they want, but they can give feedback on whether or not a prototype fulfills a need.

  10. Only the founders understand the user.

    The founders are the first to talk to potential users, but if they are the only ones, they become the gatekeepers for all decisions. This may work in the early days when the team is small but hard to scale as the team grows. Some are convinced they have the answers, led by their intuition. I believe in intuition and also in the need to validate it with user research to keep confidence from becoming hubris.

    The lack of continued user research and reliance on the founders results in slow decision-making. No one person, not even the user researcher, should hold the key to understanding users. Even backend engineering decisions that may not seem like they require any knowledge about the end user can have undesirable ramifications down the road, limiting the experience that the team can build. At that point, it might be too time-consuming and expensive to change. Having a shared understanding allows everyone on the team to independently make decisions that contribute to a better user experience.

User research may feel daunting, but shouldn't be avoided despite the lack of a user researcher or designer. Given the typical startup configuration of engineers and founders, there are ways for interested team members to perform user research. To get a guide for how to do so, subscribe to stay updated with my “Scrappy UX for Startups” series.

Feb 19, 2024 · 5 min read

Success in new product development is unlikely…so?

New product development is intense and often fails, but it is so much fun — I love it. In my career at tech startups and big companies, I have worked through many cycles and experienced the enormous stress and pressure that going from 0-1 has on individuals and how that impacts team dynamics. I have experienced ambiguity, uncertainty, doubt, and fear in figuring out how to productize ideas, where failure likely meant the end for a startup (and unemployment) or the dissolution of a business unit inside an established company. Given that 90% of startups fail, good outcomes are unlikely.

Even so, many people are attracted to new product development while unprepared for its demands — I was. Many teams excitedly begin believing they have the answer until reality doesn’t match intuition, despite all their hard work and efforts. At that point, frustrations mount, and tensions rise, further impeding progress. Having been through this process many times in different roles (Engineering, Product, and Design), I have multiple perspectives and the experience to lead teams and coach others through the inevitable ups and downs. It is a bewildering roller coaster ride with tremendous learning opportunities and impact that is less stressful with experienced guidance.

An essential part of coaching teams in new product development is developing healthy interpersonal communication among team members. Team dynamics are intangible but critical. The impact of effective communication may be hard to quantify, but the lack of it can be felt keenly. Team conflict makes succeeding in new product development even more unlikely.

Some think of “unlikely” as a negative term, as in “but that’s not going to happen.” I think of it as “yes and.” Even though the reality of creating a successful new product has a low probability of success, teams can achieve unlikely good things through structured experimentation, short learning cycles, and rapid iteration. While none of this is revolutionary, knowledge doesn’t necessarily translate to action. Having a framework for going from 0-1 is helpful and even better when adapted to suit the team — I’ve done this effectively multiple times by understanding the goals and needs of the team and its members.

In creating a consulting venture to coach teams on new product development, interpersonal communications, and product design, I aim to share the joy that knowing the positive impact of one’s work brings. Outcomes that may have seemed unlikely before may not be unlikely so.

Jan 23, 2024 · 1 min read