What Does Quality Mean to You?

About a year ago, I was in a conversation with one of our clients when they asked me this question: 

“What does quality mean to you?”

I gave an answer in the moment, but a better answer came to me later. As a developer, the easy answer is something about unit tests, code coverage, and bug-free releases. That’s where my brain went first.

But the question stayed with me. And the longer it sat in the back of my head, the more I realized how much bigger it was than I’d given it credit for. 

This blog is my answer to that question today. 

Starting from QA

I came up through QA before I became a developer, and that changes how I think about quality. When you spend your early career finding problems instead of solving them, quality stops being a checkbox at the end of a sprint. It becomes a lens you can’t really turn off. 

When I work on a feature now, I don’t just think about the happy path. I’m constantly asking myself: 

• How could this break?
• Where would a user get confused?
• What assumptions am I making?

When I’m smoke-testing a form I just built, my first move is to open it up and just mash random keys on the keyboard. It sounds silly, but you’d be surprised at how many bugs that catches: missing validation, special character issues, or missing input limits. 

That QA instinct has a cost, too. Sometimes I slow myself down second-guessing edge cases that aren’t going to matter. Still, I’d rather catch the problem at my desk than have a user find it in production. 

Over time, I’ve realized quality is about much more than catching bugs. A product can technically work and still fail the people using it. That’s where my definition expanded into three things: reliability, process, and trust. 

Reliability 

This is the baseline. Software should do what users expect, consistently. Nothing destroys confidence faster than opening an app, trying to do something simple, and watching it fail. That moment is what we’re really trying to prevent when we write tests, validate inputs, and think through edge cases. 

But reliability goes beyond uptime or test coverage. A feature can be bug-free and still feel unreliable if users struggle to navigate it, misunderstands what it’s asking, or hesitate because the experience feels inconsistent. 

Quality isn’t just about whether software works. It’s about whether people feel confident using it. 

Process 

Quality is built throughout development, through small disciplines that compound over time. 

For me, that looks like writing unit tests as I go, manually testing edge cases before regular flows, documenting bugs as they’re reported so they become future regression tests, and (maybe most importantly) pushing back on requirements that don’t quite make sense. 

That last one is easy to skip, especially under deadline pressure. But it’s often where the most important conversations happen. On a recent project, we were asked to reuse an existing modal from elsewhere in the app. Technically it worked. But the user’s entry point into that modal was different in our flow, and the language on it didn’t quite match the mental model the user would have in that moment. I pushed back. We didn’t end up doing the full rewrite I suggested, but we landed on updating the call-to-action button label as a middle ground. It wasn’t a huge change, but it was the right one. 

Process doesn’t always mean adding more steps. Sometimes it just means slowing down long enough to ask, “does this actually make sense for the person who’s going to use it?” 

Trust 

This is the one I think matters most, and the one I would have completely missed if I’d answered the interview question early in my career. 

Quality builds trust. Users trust a product when it behaves the way they expect. Stakeholders trust the team when issues get surfaced early and solutions get proposed thoughtfully. Teammates trust each other when the code they pick up is clean, tested, and well-considered. 

A feature can be technically correct and still fail if it doesn’t earn that trust. 

When Working Isn’t Enough

On my last project, one of the things I’m proudest of was our UAT process. Not because the software was bug-free at that point — although we’d done the work to get it stable — but because UAT became the moment where we caught the things that worked but didn’t feel right. 

A feature designed in Figma and signed off by everyone would suddenly feel off once business users actually had it in their hands. The verbiage we’d used on a screen didn’t quite land. A flow that made sense in mockups didn’t match how users actually thought about the task. Sometimes we even caught data that wasn’t displaying quite right, bugs that had slipped through everything else. 

None of those were huge changes. But each one made the product noticeably better, and we kept adding them as enhancements into the next sprint. That iteration loop was where the quality really lived. 

We were doing this informally and there wasn’t a structured process around it, which is why I was glad to learn that UDig has built an internal approach and tool around exactly this idea. The team calls it “Adoption Groups”: a way of breaking a product into small, testable pieces and putting them in front of real users without any training, then feeding what you learn directly back into the next iteration. It’s the same instinct we were following on my project, with the structure and rigor we didn’t have. 

That last part, putting it in front of users without training, is the piece I keep coming back to.  

If a user can sit down with a feature and figure it out, you’ve built something people will actually adopt. If they can’t, it doesn’t really matter how technically correct the code underneath it is. 

Back to the Question

I still don’t think there’s a perfect answer to “What does quality mean to you?” It’s one of those questions that probably gets a better answer every few years as you keep working. 

But today, my answer would be very different from last year. Quality means reliability, software people can count on. It means process, building it throughout, not at the end. And it means trust, building something people can genuinely depend on and want to use. 

So I’ll turn it back around: 

“What does quality mean to you?”