Why Testers Stay Silent (and What to Do About It)
I recently read The Design of Everyday Things by Donald Norman. This highly recommended book explores the interconnection between human psychology and the way we interact with the designed world. Whether the technology is physical or virtual, our experience using a product is shaped not only by design elements but also by our thoughts and emotions.
In Chapter Two, Blaming the Wrong Things, Norman explains a fascinating psychological phenomenon that most people can relate to, and we can apply to gathering feedback on software implementation projects. This phenomenon is simple:
People interpret failure and success differently based on whether they are observing others or experiencing it themselves.
I see this phenomenon most often in the testing phase of software implementations. During this time, we are asking the client to try out a new piece of software, often for the very first time, and report back to us issues and bugs. But are the issues found due to poor design, or are they due to user error? The way the users interpret this difference is directly connected to the quantity and quality of feedback they provide.
Who’s to Blame?
When we have to engage with a new piece of technology, whether it's a new app or a new dishwasher, we look for design hints to guide us on the correct path. These signifiers can be in design elements that live directly within the tool itself like knobs and buttons, or documentation in user manuals with images and instructions. As we assess all the readily available information, we proceed with our user interaction and continue to look for signs, both positive and negative indicators, to give us feedback throughout the entire process.
We all know this intuitively and can probably recall a time when we struggled to figure out how to use something new. However, according to Norman, people often judge others’ struggles as a lack of skill or intelligence, rather than a result of flawed design, especially if they have succeeded at the same task. The reverse is also true: when someone succeeds, we tend to credit the design, not the individual. Norman summarizes this tendency well:
“It seems natural for people to blame their own misfortunes on the environment. It seems equally natural to blame other people's misfortunes on their personalities. Just the opposite attribution by the way, is made when things go well. When things go right, people credit their own abilities and intelligence. The onlookers do the reverse. When they see things go well for someone else, they sometimes credit the environment, or luck.”
So, whether we fail and others succeed, or others succeed while we struggle, we tend to blame individuals first, not the design.
This becomes a problem during testing: if users don’t attribute their errors to design flaws, they’re less likely to submit feedback that could improve the experience for others.
As consultants, if we’re unaware of this psychological tendency, we might assume that users will report every issue they encounter. But often, what we get instead is silence. Norman points out that with unfamiliar or complex systems, people tend to internalize failure, not because it’s their natural response, but because:
- They lack confidence or assume others aren't struggling.
- There’s social pressure or workplace dynamics at play.
- The design fails silently - it doesn’t give clear feedback that it’s broken.
As Norman says, “People feel guilty and embarrassed when they have trouble with everyday things. They are apt to blame themselves. The resulting emotions can be severe: people may become anxious, frustrated, and angry.” This guilt and embarrassment can create a culture of silence, where people’s feelings of frustration remain hidden.
In software testing, this dynamic is extremely detrimental to a successful launch. It’s essential for consultants to recognize and address this early. The first step is understanding why users may not be providing feedback, even when they’re struggling. Once we see this as a normal human response, we can begin to shift the dynamic. Here are three ways to encourage more engagement during testing.
Three Ways to Encourage Feedback During Testing
1. Encourage open, blame-free communication early and often
The first step in addressing this issue is building a culture of openness and psychological safety, starting well before testing begins. As a project manager, foster curiosity and normalize asking questions. Be transparent about confusion and mistakes so others feel safe to speak up. You can reinforce this by sharing your own testing errors or anecdotes, such as: “We’re testing the system, not the user.”
2. Test as a group
Since this psychological phenomenon can lead to silent struggles, one of the best ways to break that silence is through collaborative testing. In another post, I explore what this can look like in depth. If your team is testing in isolated silos, consider organizing live testing sessions. These can be in-person or virtual, where team members pass a test record upstream or downstream and observe others working through the same process. This naturally sparks conversation and increases confidence, helping the group surface challenges and learn together.
3. Create a leaderboard or Dashboard
In larger projects, testing efforts can become segmented by department. When team overlap is minimal - for instance, between the fundraising and grantmaking departments - group testing may not be feasible. In these cases, consider adding a visual indicator to increase cross-departmental awareness.
This could take the form of a low-stakes leaderboard showing the number of issues or enhancements logged by each team or individual. Alternatively, you could build a dashboard with testing KPIs, such as:
- Total number of issues found
- Average time to resolve
- Issues reported by department
The goal isn’t competition, it’s visibility and normalization. Sometimes, just seeing that others are logging feedback can relieve personal pressure and encourage more participation.
What This Means for Your Next Project
Whether we’re interacting with a physical object, like a dishwasher, or a digital one, like a CRM, we bring our human psychology into the equation. One of our common tendencies is to blame ourselves for failure, even when the real culprit is poor design.
When this shows up in software implementations, it can lead to underreported bugs, poor testing, and ultimately, less successful solutions. To address this, encourage open dialogue, build team-based testing opportunities, and create visibility through visual tools like leaderboards or dashboards.
By better understanding how people experience and attribute success or failure, we can create more thoughtful, supportive environments that improve software testing and outcomes for everyone involved. If you’d like to learn more about our project management methodology or start mapping out your next project, get in touch with our team!
