Some cultures don’t have a distinct word for the color blue; instead, it’s considered a shade of green. Identifying bugs can be a lot like that. It’s difficult to see them as separate from “how the software works” when they blend in.
With AI, it’s easier than ever to generate code. But software can be like buying jeans: sometimes you pay for something that doesn’t fit well and you only want to use them when you have to (like mowing the lawn or painting the house). Software doesn’t have to be ill-fitting and unpleasant to use.
What’s a Bug?
So what is a “bug,” and how do you find one? Why aren’t they always obvious?
A bug is behavior or an outcome that varies from what is intended or expected.
This requires knowing what “expected” is. What if you’re new to a team and don’t really know what that is yet? That’s an opportunity to notice things that don’t make sense and to ask questions about why something is being done a particular way. (Think Tom Hanks in Big asking why the new toys were supposed to be fun.)
Bugs in software are like flies buzzing around your head: a localized, annoying feeling that distracts you from what you’re doing. When I’m testing a new feature or using an existing system to get my test data into the right state—any snag in how easy the software is to use is subtle. But, I’ve learned it’s a big red flag saying, “Something isn’t quite right here.”
Recognize a Bug.
As you are building or testing a feature, consider the following:
- “Did I just hesitate? Why?”
- “Did I need to read something twice?”
- “Did I have to guess what would happen if I clicked this?”
Noticing when you have these responses will help you ask questions earlier in the process and should result in more cohesive and useful software. (You’ll be learning to distinguish blue from green!)
Here are some things to consider.
Check for Unclear or Wrong Informational Messages.
Read informational and error messages carefully. Does the message make sense? Is the text accurate? Is it clear why there is an error, and does the user understand what action is required to resolve it?
For example, displaying a message like “The payment amount must be less than the balance” when the user enters 0 or a text string in the payment field doesn’t make sense. Instead, prevent the user from getting into that state: validate input as they type, restrict invalid characters, and tailor error messages to what they actually did.
For more on writing great error messages, see How to write error messages that actually help users rather than frustrate them.
Things Don’t Add Up.
Look for errors wherever your app displays calculated information, such as total price, balances, or scheduled times.
If you’re showing numbers, does the information make sense together? For example, displaying line-item prices without a visible quantity can make it hard for users to understand how the total was calculated.
Are the units clear and precise? Consider applying a credit card fee based on a percentage of the total. Does the cart show “Tax: $3.33” on one screen and “Tax: $3.34” on another because of rounding?
Also think about calculated states, such as “Overdue” for a payment or when a store is “Open” or “Closed.” If I’m in Illinois driving to Michigan, that I search for may be closing sooner than I think since most of Michigan’s time zone is ahead by an hour.
Don’t Confuse the User.
“It works perfectly. It’s just confusing to the users.”
That often means it was coded exactly as indicated in the spec, but doesn’t make sense in terms of the effort and flow required for the user to get something done.
I remember experiencing this when I processed a record that changed the state and removed it from the view, without any messaging indicating the process was completed successfully. I didn’t know where to look for the record and the app lost focus, leaving me very confused. After talking through this more with design, a toast popup message was displayed indicating which tab the row was successfully moved to.
That’s Not How Other Apps Do It.
When I moved to Ann Arbor, I went to the Ace Hardware store. I remember walking to the door, stepping on the black mat, and then taking a full minute to realize the door was not going to open by itself. My frequent trips to Meijer had subconsciously conditioned me to expect that stepping on a black mat when exiting a store would automatically open the door.
Similarly, whatever your app does, your users are bringing expectations from other apps they’ve used.
For example, when I review designs with a Search field, I want to see a “Clear” button so users don’t have to select all the text or backspace every character—especially if they’re not hotkey-savvy. Look at other apps with a similar function: what behaviors and controls do they share? Which expectations can you adopt instead of surprise?
The point of coding software isn’t the code itself. It’s creating an application that someone can use to get something done.
Defining a Bug
Understanding where your software is missing the mark starts by paying attention when your antennae twitch while you are feature-testing. Once that becomes second nature, bring the same practice into your design planning and reviews by asking:
- Does the workflow make sense from the user’s perspective?
- Is behavior consistent across similar screens and actions?
- What features do you appreciate most in the apps you use every day?
- How can you bring that same comfort and efficiency into the apps you create?
When you can clearly see whether something is “blue” or “green” (whether it’s a feature or a bug), you’re much better equipped to build software that truly fits your users.