• The UI for filing bugs is inscrutable and has too many hoops to jump through.
• No one does anything unless every field has been filed meticulously and there is a clear repro.
• The designer is ridiculed if the thing isn’t actually a bug, is a duplicate, or if it was filed in the wrong place.
• Front-end bugs are automatically “minor” or “nice to have”s without listening (as there is no loss of functionality, and no data loss).
• The designer is always responsible for stating how it should work, without being able to say “I am not sure why, but this started feeling off and it’s in an important place. Can we investigate?”
• “This is as designed” is an automatic conversation ender.
• The tiniest of external reports, social posts, or blog posts, immediately are prioritized higher than in-house experience.
• Once every few years, a designer gets 20+ demotivating automated emails saying 20+ bugs they filed over the years have been closed automatically during a purge, without any word of explanation.
• Simple human touches like “thanks for filing!” or “nice catch!” never enter the picture.
• Engineers never file design bugs themselves.

If you’re an engineer, I can sense you might be getting frustrated, as most bullet points I listed look like extra work. I agree with you. It is. This post is as much about process, as it is about culture and the incentives it establishes. The best places I’ve worked were filled with shared trust and treated bugs as a joined responsibility of everyone, rather than a black-and-white division into “filers“ and “fixers,” with the ultimate end goal always being user’s experience – nothing else.

I also understand this dives right into an age-old tension between manufacture and craft. Bug-fixing processes have to be well-oiled bureaucracies with very specific rules so that they don’t turn into a pile of vibes and Brownian motions. But design (and, by extension, a lot of front-end) doesn’t work like that. Design needs room for taste, for careful exceptions, for escalation of immesurable things, and for a certain flexibility in even the basic definitions.

If it’s a tiny, but embarrassing bug, or a flow killer, or a thing that bothers your most valuable group of users, or something appearing in a well-trafficked place – it is no longer tiny. If it’s working as intended, but it feels buggy to the user – it ought to be a bug. If it’s a long-standing bug, it should be considered as cumulative damage already done, not “oh, this has been like this for a long time, no one cares.” If there’s a shaky repro, but the bug feels important, you need to work from principles or analyze the code. If it’s something no one mentioned externally (ergo: why fix it?), consider a lot of bugs rankle but never get reported, particularly if your company doesn’t project an external presence of caring about feedback and acting upon it. cough cough Apple cough cough cough cough cough dies coughing

Of course, designers have responsibilities in the process also, among them mutual respect and understanding of engineering, clarity of communication (particularly about things that are hard to reason about mathematically), seeing patterns that could be grouped into bigger bug bundles to make fixing more efficient, (occasionally!) helping figure out a fix if the obvious fix isn’t available, and shared understanding with their team about what actually matters. There is always a thousand details that could be better, but for every thousand only a hundred might actually be worthwhile. Flooding the bug process with irrelevant minutiae that won’t realistically ever be fixed is not very helpful.

This is the only way I know of to capture the full spectrum of bugs that ruin software – from front-end to back-end, from visual/​interactive quality to works-or-not functionality, from what can be measured to what never will be. And this is not just about designers, of course. It’s not even about any non-engineering function. Design serves everyone; if your bug-filing UI or your process or your definitions are not well-designed or -balanced, I strongly believe you’re also hurting engineers on your team. And you’re definitely hurting your users.

Complementing my previous post, a lot of great thoughts in this post about invisible work from Hardik Pandya:

When the project succeeded, her work had dissolved into the project’s infrastructure. The doc was just “the doc.” The tracker was just “the tracker.” The alignment was just how things were. People forgot it had ever been otherwise. That’s the thing about good coordination. I’ve realized that when it works, it disappears. You can’t see it precisely because it worked.

Even though Pandya didn’t call that out, it’s worth highlighting that his “founder friend” example wasn’t a woman by pure chance; often the invisible work becomes the second shift of women in the workplace. And then:

The problem is that recognition follows narrative. When a project succeeds, credit flows to the people whose contributions are easy to describe. The person who presented to the board. The person whose name is on the launch email. The person who shipped the final feature. These contributions are real, I’m not diminishing them. But they’re not more real than the work that made them possible. They’re just easier to point at. Easier to put in a slide. And I think that’s where the unfairness starts, slowly, without people really noticing.

However, I disagreed with these parts:

There’s no framework that fixes this. You can’t design a rubric that captures “held the project together.”

Wait, why not? This is a similar challenge to quantifying design contributions (some of which might not clearly map to KPIs or sometimes even OKRs). You can’t measure being in the flow, true user satisfaction and frustration, or world-class-adjacency of taste. But it doesn’t mean you cannot design a system or a rubric that recognizes and talks about them.

An absolutely fantastic post about software nudges and pop-ups by Mike Swanson:

If you’ve ever read about “choice architecture” and nudging, this will feel familiar. The modern language for it was popularized in the late 2000s, and the core idea is simple: how choices are presented changes what people do, even if nothing is technically forced.

Then product teams go one step further. Instead of just shaping choices, you can shape timing. Prompts start showing up in the middle of workflows because that’s when the user is “most engaged.”

The industry also has a whole discipline around persuasive design and how to move someone from intention to action with prompts, friction removal, and well-timed triggers. B.J. Fogg’s behavior model is one of the more cited frameworks in this space.

Some nudges are genuinely helpful. But the same machinery that helps you discover a feature can also be used to push you into something you didn’t come here to do. And once the machinery exists, it gets reused.

I am finding myself wanting to quote most of it.

You cannot easily measure the resentment. Or the rage clicks when they smash a button to dismiss another “did you know” pop-up. You cannot easily chart the moment a user thinks, “I used to like this product, and now it feels needy.” You cannot easily quantify the slow erosion of trust.

I have long been frustrated by how the “growth” interfaces haven’t really evolved past cheap and loud pop-ups and defaulting to “let’s just show it.” One of the behaviours that bother me a lot that’s not listed in the post is, for example, installing an app and receiving one or even more “here’s what’s new” onboarding callouts. Hey. I just installed you. Everything is new.

Anyway, maybe one more quote:

Optimize for trust, not just return visits. Short-term engagement can be increased by annoyance. Long-term loyalty is harder and more valuable. The best products I use don’t constantly remind me to use them. They quietly do their job so well that I come back when I need them. That’s what tools are supposed to do.

Worth reading the whole thing.

From Dave Karpf’s essay:

From the vantage point of 2025, optimization is clearly no longer a priority for the tech platforms. Google’s search results have gotten worse. Google doesn’t care. Facebook is awash in AI slop. It welcomes the slop. Amazon is filled with fake products and fake reviews. All of these companies still dominate their categories. Degrading the user experience isn’t costing them. The motivating belief that these companies had to optimize, or else they would be out-competed, no longer drives Silicon Valley behavior. Optimization was an era. That era has ended.

Hidden inside that essay is also a link to The Resonant Computing Manifesto, with this good paragraph:

Most of us got into tech with an earnest desire to leave the world better than we found it. But the incentives and cultural norms of the tech industry have coalesced around the logic of hyper-scale. It’s become monolithic, magnetic, all-encompassing—an environment that shapes all who step foot there. While the business results are undeniable, so too are the downstream effects on humanity.

From Jeff Veen:

It reinforces my belief that teams need a culture that values attention to detail when building products. Tiny annoyances so often get neglected as we rush to ship, but the consequences accumulate, souring the whole brand. It’s not a long journey from “Ugh, these AirTags…” to “Apple has lost their way…”

But in my experience, those rough edges seldom go unnoticed by someone, somewhere, who was unable to stop the momentum of a product release for such an “insignificant” flaw. Or, even more consequentially, they did not feel it was safe to do so.

I want to quote so much of this essay, so I’m going to do just that.

I’ve always felt that culture is made of the accumulation of small acts of gracious leadership: acknowledging moments of bravery during a retro, teasing out a reticent comment during a product review, and on and on. It can come from other places too, but it is most effective when it comes from the top.

If you’re leading a team remember: Never criminalize pride in craft.