Makers, and specifically designers, are often taken aback when clients push back on allocating funds toward user research and testing. We hope to shed some light from a software team’s point of view.
What exactly do you mean by user research and testing anyway?
User research is the act of learning more about users in the system for which a software solution is being built. The team wants to learn more about these users. They hope to either uncover and/or validate assumptions around what users are trying to accomplish in their tasks and any surrounding motivating factors.
User testing, in the context of software, is the act of learning more about how users interact with a software product. Teams can gather qualitative and/or qualitative feedback from users that can shape the software. You can do this testing with paper sketches or the production application or anywhere in between these two.
The team can use this information, along with an understanding of the business needs/goals, to build a solution. Meeting both user and business needs means a higher likelihood of a successful product.
How is user research/testing beneficial to the project?
Testing is most beneficial to the team because it brings a voice from outside the client and the team into the fold. There can be a strong echo chamber when building a product, and this process can allow the team to adjust accordingly.
Why are some clients scared to talk to their users?
In general, it’s hard to have any idea critiqued by users, and it becomes harder the longer you wait to get the idea out in front of your users. It can also be hard to put out something to existing or potential customers that isn’t fully baked.
It’s harder for some clients to face the facts than others. It often feels like different incentives are impacting the stakeholders of the product. And, this ultimately impacts the question of testing.
Speaking generally, the product manager is more focused on the immediate success of launching anything. On the other hand, a higher-level stakeholder at the organization may be more interested in building the right thing. Each, thus, has a different take on the value of testing the product. Incentives and company culture can play a big role here.
It can be costly. But, clients pay the cost either way. There is a real price to pay to conduct testing. However, from our vantage point, it’s a small price to pay to receive critical feedback at the right time. Choosing not to pay the cost up front just bakes additional risk into the product clients are paying for. It’s just that the cost isn’t realized immediately.
You can look at this decision as a bet or insurance depending on the client’s risk profile. It’s a bet if they feel extremely bullish on the product, the team, their knowledge of the space, and their users. This would allow the client to essentially cut a corner and save money or redistribute the funds to additional features or other needs. But, as mentioned, this also creates a more risky foundation on which to build the product.
Clients who have a lower threshold for risk might opt to look at testing like insurance, where they are paying the upfront cost to reduce the risk. This, in theory, would get them to the ideal state of the product in a more linear fashion.
How much will it cost?
It’s a scale and tough to say. Teams can get valuable information from a few short impromptu interactions with customers. But, that might not be adequate for every circumstance. The bottom line is to work with your team to create the appropriate plan for the engagement. We are here to help our clients get the most value from the engagement. That said, we highly value testing at Atomic. We can scale the research up or down to match the needs of the project or the budget.
What actually goes into conducting testing?
As in all law classes, the answer is that it depends. We want to have an area of focus on the problem we are solving with the software. That means that, depending on where you are in the product lifecycle, the more specific the area of focus, and the more potentially actionable the feedback can be for the team.
Determine how much research or testing is necessary for getting the information you want. For user research, the team can simply observe the users. They can interview them. For user testing, they can show prototypes or put the real product in front of the user to capture their reactions. The team will create the game plan and schedule and run the interviews/tests. We strongly encourage our clients to get involved or listen in on the testing. It can be rewarding to hear the feedback and comments firsthand.
The team captures data and returns their findings and suggestions. There are three possible outcomes. First, we might suggest conducting more research. Second, we may validate our assumptions and so we stay on the current path. Or, maybe we saw some serious warnings and the team should reconsider the approach.