We recently hosted a webinar on the ins and outs of hardware research with UX leaders from Google, Amazon, and our own AnswerLab team. Our panelists spoke on the differences between software and hardware research, ways to build empathy, and their strategies for collaborating with product teams for successful research during hardware development.
“The user is who sees and defines what the products are, not really the designers or product managers.” - Jon Morgan, Product Manager, Google
Hardware research is vital to the success of any product entering the market as it indicates what’s needed to be adopted into people’s lives. Hardware product development has its own set of unique challenges and timelines we often don’t see when it comes to software. Here were some of our takeaways and recommendations from our panelists to get the most out of your research program.
Our Key Takeaways
You only get one shot with hardware products
“Software is something you can ship and then progressively work on improving. Hardware you get one shot. You can’t go in and upgrade someone’s hardware, but you can upgrade someone’s software.” - Shameem Hameed, Principal Human Factors & Ergonomics Specialist, Amazon
Unlike software where the timelines are quick and you can continually make improvements after launch by shipping updates to users’ devices, hardware product development is much more rigid. You have to design multiple components to work together from the get-go, and you often aren’t able to design one piece until another piece is finished. As a result, timelines are much stricter, and you can’t launch something only to decide you’ll make an improvement later. This makes research all the more necessary early in the development process to ensure you’re building the right product from the start.
Account for variations in hardware prototypes
“Your typical methodologies can be utilized across hardware and software. You can do diary studies or interviews. You can make low or high-fidelity prototypes. But for hardware specifically, it’s really about asking the right questions early on with low fidelity prototypes.”
- Sylvia Bargellini, Senior UX Researcher, AnswerLab
Prototyping for hardware brings its own set of limitations. You can’t quickly mock up a high fidelity hardware prototype. You have to rely on lower fidelity prototypes, 3D printing, or some other rapid prototyping tool. And even so, these tools don’t give you a fully accurate prototype, as the texture, color, or feel will likely be very different.
For example, let’s say you’re testing a wearable device. A rough prototype might irritate the skin while the participant is wearing it. As a result, you’ll get bad comfort data for the device. But in reality, it’s just the nature of the 3D print and the wearable might be totally comfortable. Accounting for these differences and variations in prototypes is necessary to not complicate your evaluation of the product.
Secrecy and scale add challenges to your hardware research programs
Developing a hardware product involves long lead times, sometimes more than a year in advance. If a participant were to leak something from a research session, it can have a major impact on the competitive advantage of your product. With software, teams are often working much more quickly and this isn’t as significant of a consideration.
For those that value quantitative data, getting the scale you need can also be a challenge. It’s very easy to build a software product to full completion and conduct an A/B test with thousands of people. But, with hardware, you likely won’t get this level of data. It’s difficult to get 10,000 people to physically try on a device. Instead, you need to rely much more heavily on qualitative insights. Really pay attention to what your participants are saying as well as what they’re not saying.
“You have to see behind the words that are said by your research participants.”
- Jon Morgan, Product Manager, Google
Conduct research early and often
“The product development person and product engineer are there to ensure the device has the best battery or the best circuit. The industrial designer is there to make it as aesthetically pleasing as possible. The product manager is there to make sure everything is on schedule and under budget. There’s only one person at the table who’s thinking about who’s going to use it. You’re serving as the voice of the user throughout the product development process.” - Shameem Hameed, Principal Human Factors & Ergonomics Specialist, Amazon
When research is done early, you can pivot and ensure you’re meeting user needs. Think about how people will actually use the product as early as possible, as late-stage changes to hardware can cost millions. Additionally, product launches without early hardware user testing can lead to a loss of trust with users. These are costly outcomes many companies can’t recover from.
It’s important to bring researchers into the process as early as possible to help shape the approach to product development. If product teams can clearly articulate the value to the user, the value to the business, and the necessary milestones, researchers can help shape the process and sometimes offer questions or suggestions product teams hadn’t previously considered.
Collaboration and empathy-building techniques can have a big impact
“The second you can get the designer to 'meet' the user, the quality of the design skyrockets.” - Jon Morgan, Product Manager, Google
“Research can provide that connection between silos and teams. How do pieces and accessories fit together? [...] As the researcher, I was the only one thinking about how those components worked together.” - Sylvia Bargellini, Senior UX Researcher, AnswerLab
Everyone wants to build the right product for the right user, and building empathy is a critical piece of this puzzle. When talking to a design team, share that empathy as much as you can. Designers are often deeply focused on certain aspects of the product, not the overall impact on the user. As researchers, it’s our job to bridge the gap and connect our stakeholders with real people.
Make a persona come to life with quotes, highlight reels, or even by having stakeholders observe or meet real users. Showing your stakeholders that the user is struggling to use the product can help people really understand and see the value of the research.
Consider accessibility needs from the start
“We need to consider every user in every situation.”
- Shameem Hameed, Principal Human Factors & Ergonomics Specialist, Amazon
Make sure you’re building products that work for everyone. Designing for accessibility isn’t a separate task to add to your process; it should be built into the product itself. Keep different abilities and situations in mind throughout the process so you’re not providing a separate UX for your average user versus users with accessibility needs.
Everyone benefits from accessibility improvements, and everyone experiences some form of situational disability at times in their life. Ensuring your hardware products are accessible to everyone helps all your users, not just those who explicitly need it.