Neither I, you, nor anybody else can convince an executive to invest in user experience.

— Jared M. Spool, “Why I can’t convince executives to invest in UX (and neither can you),” Center Centre, accessed November 18, 2025.

Design in tech companies is a weird sport. With an undergraduate background in Architecture, I’ve spent my entire adulthood in an industry that struggled to attain business relevance. When I switched to tech in 2018 to become a UX designer, I was starry-eyed. It was refreshing to immerse myself in a world where it felt like design had won the battle for recognition — IDEO and the D-School’s Design Thinking framework defined what design means to businesses, and McKinsey’s report ( “The Business Value of Design” ) quantified design maturity, and correlated it with business performance. Design jobs were booming, and designers finally earned salaries on par with engineers.

Design wasn’t just decoration — it was the “secret sauce” that differentiated Silicon Valley products. At least that’s how the outside world saw it.

Around 2018, I read an exhibition publication called California: Designing Freedom. Curator and writer Justin McGuirk wrote:

The San Francisco Bay Area is home to probably the densest concentration of designers in the world. They are there because Silicon Valley’s technology industry needs them. Design is what makes technology useful and accessible to ordinary people. Without designers shaping the human experience of a product, no piece of tech would make it to market.

— Justin McGuirk, “Selling Freedom: Tools of Personal Liberation,” in California: Designing Freedom (London: Design Museum, 2017), p.9.

Rereading this today in 2025, I can’t help but feel a massive disconnect. My core memory of working in various tech companies has been an ongoing struggle to:

1. Advocate for design to colleagues and leadership (demonstrating metric wins, running brown bag events, onsite workshops, you name it);

2. Actually do the design work and carry out some semblance of design process;

3. Ship designs in one piece as much as I can.

I don’t know another function or role in the tech industry where it seems like we have to do our jobs at the same time as — and I will avoid saying “demonstrating value” here because it’s more than that — we carry out some sort of divine duty to make the product (let alone the world) a better place through our creativity.

I confess I’ve allowed the corporate culture to shape me. I know we technically have to avoid dark patterns, but (let’s say hypothetically) if a dark pattern that had accidentally come to be is responsible for 60% of the company’s ARR, who am I to stop that train right now? Will changing sterile copy on a modal into more emotive copy radically change a conversion? Probably not, so I won’t bother here. Focus on what matters.

There’s an overwhelming sense that to advocate for good design means more data analysis and ROI calculations. But if design has otherworldly powers, it requires otherworldly approaches for advocacy, not more left-brain exercises.

Introducing William Edwards Deming (1900–1993)

Let me take a detour to tell you about W. Edwards Deming, a renowned American statistician and management consultant known as “the father of quality management.”[1] He was influential in post–World War II Japan, where major companies like Ford-Mazda adopted his philosophy, helping give rise to the country’s eventual manufacturing prowess.[2] Coming from a pioneer of the modern age who championed using data to monitor and improve quality, his famous quote rings even more strikingly:

The most important figures needed for management of any organization are unknown and unknowable, but successful management must nevertheless take account of them.

— W. Edwards Deming, Out of the Crisis (Cambridge, MA: MIT Press, 1986), p.121. Emphasis is mine.

Let’s take an example. Imagine you run a restaurant. To inform business and management, you might measure costs and revenue, dishes sold, average delivery time, and tips received.

What’s much harder or more expensive to measure accurately: the warmth and hospitality of your servers, the pride your chef takes in perfecting each dish, whether a couple had a magical first date at your restaurant and will return for anniversaries, the camaraderie between wait staff and kitchen staff, whether your restaurant becomes someone’s comfort place during a hard time, the reputation spreading through word-of-mouth in the neighborhood.

Designers are predisposed to care more about the latter than the former — and that’s the source of our frustration. While we have many tools and methods to gauge qualitative feedback, measuring it comes at a high cost of time, energy, money, and specialized research talent — and the outcomes might still be hugely biased and inaccurate.

We’re burning energy in the wrong direction

Where does this leave us — product/UX designers? We are left wrestling with data and trying to make design improvements to prove it can move some needle through “quick wins” and “low hanging fruit,” nowhere near that transformative power McGuirk described. And I know I’m not alone, but one by one we are slowly giving up. For one, we are not set up to design- think, our process and “design work” as diced up as the Jira tickets in our dev team’s scrum boards, and most of us are just trying to keep our noses above water. As Medium writer Chris R. Becker describes the daily life of a designer in vivid color:

A UX Designer joins a software team (1 VP Product Designer, 1 PM, 1 TPM, 2 Designers (1xUX (new), 1xUI), 4 FE Dev, 3 BE Dev, 1 QA). The 12-person team is dedicated to 2-week sprints. The UX Designer picks up design tickets associated with dev commitments defined by the VP Product and PM via the PRD (Product Requirement Document) in Confluence and Jira. The UX Designer joins daily scrum calls to support active dev work and reports on the progress of new work on assigned tickets. The UX Designer jumps into creating UX flows and screen updates for existing or new components in Figma based on predefined requirements. At the end of the Sprint, the Designer hands off design tickets to dev to be scoped and prioritized into a future dev sprint.

— Chris R. Becker, “Let designers Think,” Medium, November 11, 2025.

Reading this literally gave me chills. (Except, in my case, at one point I was also that PM, and was working on five different workstreams concurrently.)

Recently, I attended Rikki Teeter’s virtual talk on Conscious UX, in which she argues that in the age of AI, human-centered design values — equality, inclusion, compassion, and empathy — will become even more paramount as we design AI features for people. In professional circles, we may discuss these “designerly” ideals, but they are far out of reach in our corporate lives. How might we speak the same language as others and stay relevant in a cross-functional meeting about revenue and cost centers? Or in our daily engineering standup? Being able to address any of these as a designer feels like a luxury, but walking away from them would mean losing ourselves.

Unless we can cause a sea change.

Advocating for empathy… with empathy

There are many ways to approach design advocacy. But I learned early on that there’s a quick — and brutal — way to cut through the noise and connect with executives and non-designers on your team.

To illustrate, I can share a personal anecdote from years ago.

It was January — the new year had just started. I was a relatively new designer at an interior design tech startup, and the process was a mess. All the usual stuff: I was thrust into a mid-progress project for an e-commerce checkout flow and assigned a random page to design. Someone designed the first step, and I designed the confirmation page with little to no explanation of what happened earlier in the journey. It was haphazard — and a chaotic product experience always reflects a chaotic team workflow.

We urgently needed to break from the old way of shipping and implement proper design processes and quality control. The team was building and building, but the customer frontend looked amateur, and the backend creative tools that our in-house designers used were completely unusable. We were shipped constantly, but engineering investment was going down the drain because literally no one was using the tool.

However, the CEO had all these new features on her wishlist that she wanted us to build. I was placed in an uncomfortable position of needing to suggest that we pause and rework many of the existing features first.

Finally, I remember bracing myself and taking a deep breath before raising this question:

“If this product was homework, how would you grade its design?”

Gulp.

She paused for a moment — and it was apparent that I had cut to the heart of the issue.

“D.”

She came to realize that while she founded a company that provides design services and e-commerce, she could only rate the design of her branding, product experience, and services a “D.” To her, it was unacceptable — it brought back to the fore a misalignment between intention, expectation, and reality.

This marked the beginning of change. Over the next few weeks, the company set a six-month goal to bring the design up to at least a “B.” How is a “B” defined? At this point, we didn’t have a clear definition. It just meant “to a decent degree, without going overboard and dragging out development time.” It was a scrappy startup — trusting our gut for now was fine. At least we had some structure. As a result of that conversation, the CEO gave me complete reign over project management. She handed over the keys and said, “Do what it takes to make it better.”

This is what we managed to accomplish:

I could make a whole case study presentation about the process that got us from the “before” to the “after” image, but what really made it happen was that one conversation.

I’m not saying everyone should ask their leadership this same spicy question tomorrow. (Or do — if you feel like they’re low-ego and open to challenge.) But I do think there’s a time and place for raising:

• How good do you think the design is now?

• What do you think the poor design quality is costing our business?

• How good do you think it needs to be?

• How much are you willing to invest to make it happen?

Because when was the last time anyone did the most basic thing — to stop for a moment, hold the product in their hands, and take a good hard look at it? These questions throw the ball back in their court. It makes them wonder what they can do to help. Because chances are, most leaders want their product to have a good user or customer experience and understand that it makes a difference to their business success. You don’t just want buy-in — you want them to have true ownership.

Not everyone is Steve Jobs or Brian Chesky, but many can be persuaded to care

The most “design-led” Silicon Valley tech companies are founded by visionary designers like Brian Chesky or Steve Jobs. This might suggest that a company’s design culture ultimately depends on the founder’s DNA, perspective, leadership, and will. That may be true — but we can still influence our leaders and peers. The key is appealing not to their left brain, but to their right.

We can try our hardest to make the case with data, but we can’t easily measure joy, laughter, annoyance, or frustration. Even if we could, we should ask: given how expensive measuring is, is that how we want to spend our time instead of doing the work?

I’m not the only one thinking along these lines. Medium writer Ida Persson wrote about it in her article, “A designer’s role is NOT ‘at the table,’” suggesting it’s instead “in the making room.” Under the subheading “Rather than asking designers to change, maybe it’s time to rethink business,” she writes:

By rewarding only certain types of behaviors in business, we’re neglecting the importance of other ways of being and communicating that are just as critical. We’re missing out on creativity, and we’re missing out on the magic that happens when we value differences.

I’m increasingly realizing that just as empathy is at the heart of design, advocacy requires it too. A design-led culture can’t be built through spreadsheets alone — it needs to be understood, experienced, and championed by the entire team and leadership firsthand.

Fortunately, good design isn’t rocket science. It’s common sense — and that’s something we can all appeal to.

If you are a designer, founder or anyone else “going through it” in a startup and need a sounding board, I’m open to ☕️ chats. Book me at: https://adplist.org/mentors/lai-jing-chu.

Notes:

1. Deming’s work on quality and management has apparently influenced Apple, Amazon, the Obama reelection team, and US Homeland Security’s Operation Warp Speed. The more I dig into it, the more I find Deming to be a fascinating yet underrated figure — but I don’t want to fall into a rabbit hole yet. I came across this website and blog all about him by John Willis, former Chief DevOps Evangelist at Dell, where he mentions that “although he is not well known by the general public, the few people who know a lot about him talk about him in an almost cult-like fashion.”

2. Deming lists the “Seven Deadly Diseases”: Lack of constancy of purpose; Emphasis on short-term profits; Evaluation by performance, merit rating, or annual review of performance; Mobility of management; Running a company on visible figures alone; Excessive medical costs; Excessive costs of warranty, fueled by lawyers who work for contingency fees.

3. There’s a second reason why “the most important things cannot be measured” (though I’m taking it out of the main article for better flow): data imprecision. Deming’s theory of variation tells us that exact answers differ depending on whom you ask. Take the restaurant example again — if we ask “how many people are in the restaurant?” the answer varies depending on whether your count includes the restaurant staff or those dining in the outdoor space. There’s no straightforward answer. (Paraphrasing from “The myth of management,” blog post by John Willis.) As a former growth PM, this type of data analysis challenge was one I faced daily.

I’ve been asked this question countless times over the years, and the same struggle echoes across the internet. Case in point:

The only consensus seems to be there is no consensus. After all, aren’t startups, by definition, all unique? Don’t you have to build the plane while flying it?

I can tell you — that’s not necessarily true. I’ve gone through this four times, and the experience was largely repetitive.

But there’s so little written about how to navigate sole/early designer experience — at least from the angle I’ve lived, breathed, and seen work. At one startup, I shipped nine features in six months with minimal bugs that helped a creative team deliver designs in hours not weeks. At another, I helped bring a new B2B offering from zero to seven figures ARR in 2 years. Here’s what actually worked for me.

You’ve never been told that being a solo designer (w/o PMs) is a thing

I’ve worked in tech for seven years as both a PM and a designer — sometimes one or the other, but three times simultaneously. This wasn’t by accident. Each time I held both roles, the companies were in early stages where conventional wisdom from VCs and startup literature suggests they’re too early for a dedicated PM hire.

At this stage, the founder typically owns product strategy, while the designer guides engineering execution (read: “project management”) and influences product strategy alongside UX research and design.

It’s common for designers to navigate this messy, awkward stage as the only non-technical partner on a newly forming development team. The confusion stems from a disconnect: many designers are groomed to fit a certain mold for big-name companies, but most of us end up at smaller companies where no one sets standards and ownership expectations.

Some designers — even seasoned ones from larger, established teams — buy into the stereotype that joining an early-stage startup means shaking things up. So they try to move really fast and push a ton of things to production.

After all, that’s what it means to be comfortable with chaos, to move fast and break things, to learn and fail quickly. Right?

Wrong.

If your team wants to know whether the product has true product-market fit, you need clean data signals. To get that, it is necessary to balance speed and quality — ensuring the product is intuitive enough to for customers to complete primary tasks so the data you receive isn’t cluttered by noise.

I’ll use a hypothetical example…

I’m using a simple example here to make a point. Say your team is launching an iteration of an e-commerce shopping flow. Customers go through a multi-step process to look for products, add items to a cart, and check out.

Here are a few ways it could go wrong:

• The purchase button is no longer as obvious on the page;

• The checkout page is broken or takes too long to load;

• Payments fail to process.

Your data shows that fewer people are completing their purchase. Cart abandonment is at an all-time high.

Engineers have spent weeks developing this, but in the end you see the numbers flop.

In this case, do you know if it’s because there’s truly no market need for it, or because your product simply sucks?

“Who’d screw up such a simple feature?” — you’d ask.

I dare say, almost every startup I’ve seen — because the problem lies in the execution process, not the feature complexity itself.

The main culprit is Mark Zuckerberg’s infamous quote “move fast and break things.”[1]

That line comes with a ton of caveats. Even Facebook’s early employee, Julie Zhuo, herself wrote in her book, The Making of a Manager:

Throughout your career, you will make countless mistakes. The most frustrating will be the ones where you don’t learn anything because it’s not clear whether the issue is with strategy or execution. Every time you see a good script result in a bad movie, a pioneering company lose business to a less innovative competitor, or a genius professor do a poor job of teaching students, you’re seeing a failure of execution.

— Zhuo, Julie. The Making of a Manager: What to Do When Everyone Looks to You (p. 203). (Function). Kindle Edition. (Emphasis are mine).

While popular culture as a whole — now realizing the high stakes our tech has on society, healthcare, financial services, and the environment — has gradually walked back on the “break things” part of this motto, the ethos has become too deeply ingrained in our working culture. While seminal literature and frameworks focus on how to move agile and lean, talk of moving fast and steady at the same time remains anecdotal. [2]

Moving fast and steady means:

1. Deciding early on what not to break;

2. Building team intuition on when to move fast vs. slow;

3. Testing often;

4. Setting quality bars.

“Move fast and break things” as a saying is prevalent among brilliant, innovative, yet nascent engineering teams who believe that they are “too small for process.” To that I’d always counter with: as soon as you have two people working on the same thing, you’ve got process. The question is: is it good process or bad process? [3]

Because — while the e-commerce checkout page example reads simple and innocuous — it betrays common product development pitfalls that teams are too often reluctant to resolve.

Here are some examples of failure points that a designer could have helped address:

1. If people couldn’t see the checkout button, is it a design problem? What did the designer do to validate the placement during the design process? Has there been user testing or design reviews?
   ➡ Resolving this requires more time and financial investment in design research and processes that need designers’ advocacy. This requires sophisticated leadership and influencing skills on the part of the designer.

2. If the checkout button is buggy because no one tested it — is it because a designer didn’t get to QA before it was released into production
   ➡ Resolving this means designers would have to review a developer’s work before merging code to production. There are often cultural and technical frictions inherent to this in an early team that take time to resolve. Plus, the designer also needs to know how to do this, and I’ve never seen designer QA being taught anywhere in any formal sense.

3. If buttons aren’t working, how long would your team take to fix it?
   ➡ Let’s face it, if the final checkout CTA isn’t working, alarm bells will be going off and your team will issue a fix quickly. But what if it’s something else? Maybe it’s an “add to cart” button, or a “delete item” button? They’re still important, but who will decide when they get fixed? And when these bugs pile up, how do you help the team balance fixing bugs versus building new features?

4. Were people checking out, but are we just not tracking it correctly?
   ➡ Planning and instrumenting data tracking analytics often falls outside of both designers’ and engineers’ wheelhouse and therefore doesn’t get enough attention. However, this is arguably the most critical part of the whole process — how else would you measure and learn? [4]

Be reminded that I’ve only used the dumbest, more relatable example here. Most features are larger and much more complex. Imagine the mess that compounds when the engineering team’s conveyor belt keeps churning out broken features like this. It adds up quickly.

Surprisingly, I’ve scoured the internet and have found few materials addressing the intersection between a designer’s responsibility to product quality and impact on business outcomes. But I’m willing to die on the hill that it is not wise for a team to break things excessively just to performatively demonstrate shipping speed.

So, what do designers own? Working for a small startup as my first job taught me that unless I wanted my impact to stop at Figma handoffs, I had to own not just the design blueprints, but the process of getting the design and experiential details that are critical to accomplishing the objective into production.

A ‘Product Delivery Engine’ that ties design with quality

The Product Delivery Engine is a framework I’ve developed to think about how design work flows through a team — from identifying user needs all the way to delivering working features in production. Each stage builds on the previous one, and the designer’s role is to ensure quality and clarity at every step. When this engine runs smoothly, teams can ship reliably and learn quickly from real user feedback.

Here’s the mindset shift that needs to happen:

The point isn’t to launch, it is to make sure production code is ready for prime-time.

The point isn’t to develop, it is to make sure the design intentions accurately translates to code.

The point isn’t to design, but to make sure the problem has a good solution.

The point isn’t to research, but to make sure your insights are accurate and actionable.

Here’s another way to put it:

There is no point in shipping a feature quickly if your research quality is low and your team is building the wrong solution.

There is no point in doing research if your insights cannot translate into a usable feature within reasonable time.

There’s no point in doing all the work if the production is compromised in terms of feature completeness and experience.

“But I’m not an PM, or an engineering manager, or a QA. How do I help guide the team?”

You don’t need to be an expert in every technical domain to help set production expectations and design how team communication and workflow systems work. What matters is the “what” and the “why” — let each domain expert figure out the “how.” The wireframes you have on hand, the acceptance criteria and requirement docs you write, these are the tools at your disposal.

You don’t need to be technical to realize the button isn’t working (at least at an obvious level). You don’t need to be technical to reach out to your engineer and say,

“Hey — this page needs to look like this, customers need to be able to see this element, this screen should not flash twice, otherwise they will likely fail to check out.”

By doing so, you’re not prescribing any implementation details. You’re not listing all the devices this button needs to be tested on. You’re simply laying out expectations in simple terms. You’d be surprised by how far you could go just by leading with user expectations.

A designer’s scope of responsibility includes attention to production quality. In my experience, no developer, QA, or manager has ever pushed back on my request to ensure feature launches meet the design quality bar. They welcome it. We’ve created workflows and infrastructure to make that happen. This is because even if a full-time QA is present, they may not know all the ins and outs of your feature design intentions or have the same designer’s eye. What they define as “working as expected” could be completely different from yours. This divergence increases as feature functionality becomes more complex.

The problem is I’ve not seen enough designers ask for this access. Most don’t even think of it.

So if you ask me — the first 90 days of working at a startup should involve dialing in collaboration and feedback loops between design and development to ensure there’s a straight path for your design work to reach the hands of your real users.

“But we can’t afford to slow down.”

A common pushback I hear is that raising the release quality bar slows things down. But what time duration are we measuring? Time to ship features? Or time to return on investment? If everything you ship has zero conversion, we’re all cooked. [5]

I will illustrate this with two hypothetical teams: A and B.

Notice that in these two charts, within the same timeframe, one team shipped four broken features while the other shipped three working ones.

Which team is truly faster? I’d say Team B — because it’s infinitely faster in terms of time-to-value.

I’ve seen this scenario play out many times:

A team ships a feature that happens to be a repeatable UI pattern — an upload modal, a bookmark function on a card, a save and download button.

Because the broken feature is a touchpoint accessible from multiple locations, it virtually degrades every subsequent task flow and experience you ship, hampering the task completion rates and paid conversion rates your team cares about. But because those bugs all seem “minor,” they’re difficult to prioritize without proper team processes and frameworks.

Conversely, when a standalone feature is shipped well, you not only get better product signals about what works — the features feed on each other, creating compounding growth effects.

For example, if you have a smooth sharing function to add to every subsequent core feature functionality, you have a much better chance at compounding signups.

This is literally what growth flywheels depend on.

The truth is, no one cares how many features you ship, if they are all liabilities

Broken features create more work for the team, clutter the product, make value harder to discover, and make businesses impossible to strategize for.

I once asked a C-suite exec, “Do VCs care about how many features we ship?”

She said, “Not at all. All they care about is ARR and churn rates. If a feature isn’t delivering results, we should just remove it.”

In other words, by shipping a ton of broken features, your hugely expensive engineering colleagues are churning out liabilities, not assets. [6]

It’s quality that counts, not quantity — and in startups, that’s no exception.

How about design? The thing that I was hired to do?

Once the product delivery muscle is built, traditional design activities finally have room to breathe. The beauty of this first-principles framework is that it puts all other design activity into context.

How and when do you conduct research? How much time should you spend on it? How do you justify research value? All of that becomes easier when you understand the development cycle and can reliably predict when you’ll have something to test. No one will invest in research if the time and process it takes to delivering a solution is unclear.

Need more time for design iterations? Want feedback from others? If you know how long development typically takes or where engineers are with the last feature, you can better scope your design before shipping.

Everything falls into place.

If the dev team is a vehicle, the designer is the headlights.

Think of it this way: if product execution is a vehicle, the designer is the headlights — illuminating the path so everyone can see where they’re going.

This is actually how I broke into tech. With no prior experience, I landed an internship at a small startup. The engineer convinced the CEO to hire me because, in his words, he “enjoyed having someone make decisions for him so he could focus on the code.”

You could also say that if a dev team is a vehicle, the designer is a mechanic — keeping the engine well-oiled so it gets places on time. (Though this probably only applies to very early-stage startups with a handful of people and no dedicated PMs.)

Once you get that engine running, the fun begins. You now have a team that can reliably ship working features in quick development loops. You know each feature delivers standalone value and creates its own success flywheel. There’s no urgency to firefight or pile on more features to overcompensate. If something doesn’t work, you can pivot without being in crisis mode.

In my experience, realizing that my responsibility as a designer wasn’t just to design the product but also to design the process — and ultimately seeing the results of my work — was how I broke into the field and gained confidence.

If you’re in a seed or pre-seed stage startup, this is often where you’ll find yourself. Being comfortable with chaos doesn’t mean you should move fast and create more chaos — it means bringing order to chaos.

I am on a sabbatical but currently looking to connect with with designers, PMs, founders, and engineers who might relate to startup pains and gains, or just to meet a new friend! Feel free to book a virtual coffee chat ☕️ with me if you wish to bounce ideas or just to meet a new friend. Very low stakes. https://calendly.com/laijing-chu/quickchats

Notes:

1. Mark Zuckerberg’s full quote — ”Move fast and break things. Unless you are breaking stuff, you are not moving fast enough” — was a core value in Facebook’s early days. He discusses the controversy in an interview with TechCrunch’s founder, Michael Arrington, in 2013. Toward the end, Arrington shows him a photo of a wall decoration hung by his employees that says “Slow down and fix your shit.” The following year, Facebook officially replaced the motto with “Move fast with stable infrastructure.”

2. Blog post: “Why you shouldn’t move fast and break things” by Chris Stokel-Walker, LeadDev, October 07, 2024. https://leaddev.com/velocity/why-you-shouldnt-move-fast-and-break-things.

3. In her book The Making of a Manager: What to Do When Everyone Looks to You, Julie Zhuo offers a list of signs that indicate strong team execution in a subsection titled “Perfect Execution Over Perfect Strategy.” These include: effective prioritization, efficient decision-making, disagree and commit, moving faster with reversible decisions, pivoting quickly based on new information, clear ownership and deadlines, and team resilience and willingness to learn (p. 204, Function, Kindle Edition).

4. Amplitude’s course “Fundamentals of Data Taxonomy Design” had designers as the audience in mind, which goes to show that analytics naming and deciding what to track falls under the responsibility of designers.

5. Anna Kaley, Director of Consulting at NN/g, describes a common headache teams face around UX debt in her article “UX Debt: How to Identify, Prioritize, and Resolve” (2018). She proposes that efficient processes are the only way to pay it down.

6. A more recent research paper titled “UX Debt: Developers Borrow While Users Pay” (2021) argues that cutting corners during development means borrowing not only against future maintenance time, but also against user efficiency — which translates directly to revenue impact.