Diagram of user interactions with an N64 controller.
All articles
May 5, 2020 | Updated Jan 5, 2022

What to Know Before Starting (and Finishing) Hardware User Research

Blink is unique for applying our user research processes and approaches to both hardware and digital experiences. Some of the most complex and engaging digital experiences go hand in hand with specific hardware, and some of the most exciting hardware is useless without a visionary digital experience.

Congratulations! Your team is in charge of a new hardware product’s user experience. Where do you start? Below is a sample hardware user research flow, marked by the questions you might ask along the way.

1. Our new product idea is great! But how and why will people use it?

Before your device enters the development phase, your team needs to know what it’s building. The answer begins with understanding how and why people will use it. A good place to start is by conducting foundational research on comparable devices to learn how people interact with them. In addition to testing, conducting a heuristic analysis of a device can provide valuable insight, and analyzing user reviews can be a good gauge of user sentiment. As for understanding why people might use a product, there are a lot of great UX tools (e.g., personas, journey maps, and the jobs-to-be-done framework) for unpacking core needs and use cases that we like to have in place early in the design process.

2. How do I test it if it doesn’t even exist?

One of the things that I love about HW user research is the creative challenge of reproducing an experience without a working device. We often use non-working prototypes and simulate user interactions by asking study participants to imagine they are in a specific setting with a desired goal. We might give them a simple replica of the device form factor to execute a task toward meeting that goal. The “device” could be as simple as a block of material or a prototype constructed of basic components designed to match the size, weight, and other core attributes of the real thing. If you need to simulate a system response you may be able to use a methodology which we have used extensively called Wizard of Oz testing, where someone in another room controls a prototype’s response as the participant interacts with it in the lab.

It’s important to remember that most of the time any feedback is better than no feedback! Even the most rudimentary user testing can generate valuable insight, expose issues, and reveal how users are interacting with your device, giving the product team signals that guide their development decisions. Best practice: test early and test often!

3. How do I track user testing over the dev cycle?

Early on in the development cycle, you should begin establishing high-level UX goals. These tenets articulate what a successful user experience looks like and how you want users to describe their impression of your product. An example might be “The most comfortable wearable widget on the planet.” Success criteria metrics, or the data that defines each UX goal (e.g. “I can comfortably wear the device for X minutes/hours”), will frame the research questions that you will test against throughout product development.

Success criteria are reported in a UX scorecard, which shows the evolution of the criteria over the life of the product development and lets the team know the products status. UX goals can cover the end-to-end experience with the product, from unboxing to first-run experience and ongoing usage. Your clearly defined and supported UX goals should be the mantra that your entire organization follows and ultimately bases many of its decisions on.

When reporting your results, effective visualization of your test outcomes is a powerful tool for effecting change. Rather than sharing the data in its raw form, which may require interpretation and explanation, creating a well-designed visual representation of your findings that clearly describes your outcomes can help coalesce consensus more quickly, fast-tracking the decision process and ultimately the development cycle.

Blink researchers partner with our visual designers to express our findings through clear illustrations. This is a sample of some hypothetical illustrated findings for an N64 controller.

4. It’s working now (Kind of…). How do we test a device that is only partially ready (and really buggy)?

Now it gets really interesting. Your device isn’t really ready until it’s…really ready. But your device will be only partially functional at some point, and you will still need to get feedback. This is a great opportunity to learn how well it’s working, uncover issues, and see where you stand on meeting your UX goals. You may get to test only certain features or experiences, but that’s OK. The objective is to stitch together an experience that simulates the scenario that surrounds the working component as best as possible. This way, you’re testing the broader experience in context — not just an individual part. You may need to combine working components with non-working components and ask participants to use their imagination.

As is often the case, products in development can be buggy and may exhibit unpredictable behavior. The only option is to roll with it! When testing, be prepared with workarounds and backup devices. You should also have an engineer on hand to troubleshoot any problems. Be sure to let the participants know that they will be using a prototype and may experience some unexpected results. When informed, participants are typically very forgiving.

Man testing a virtual reality driving simulator.
Sometimes research sessions call for complex prototypes. We simulated some aspects of a driving experience for this research.

5. But this thing is Top Secret. Nobody can know about it! Now what?

Companies are very protective about their product development, especially with new technology. How do you effectively conduct user testing on a confidential product without exposing it to the public? The process usually requires utilizing internal employees and/or friends and family who can be trusted not to divulge product information. You won’t have the luxury of recruiting participants who match your target audience, and an inherent company bias will be present. Keep that in mind and be sure to include that caveat in your results. In cases where confidentiality is important but total secrecy is not paramount, setting up strict NDAs to be signed by recruited research participants who are not connected with the company is a good way to go.

6. How do we know it’s ready for market?

As the product approaches its final development phase, it’s time to conduct readiness testing. This “last mile” typically takes place after you’ve announced the product, allowing you to bring in actual target users as participants. At this stage, you should be able to conduct a complete end-to-end study, from unboxing to first run and ongoing usage. Readiness testing is often the first chance for the team to observe hardware and software together in their completed state, creating a single cohesive experience. You can now assess the final product for how well it’s meeting UX goals. It’s also a valuable opportunity to compile a list of known issues. This list not only includes to-do items for ongoing work for the product team but also provides an “eyes wide open” view of the product for the senior leadership and marketing teams so they can be prepared to respond to user feedback and product reviews.

Let Blink show you the way

I hope these lessons and recommendations help you get started on the right path as you embark on user research for hardware. Each hardware user testing situation is complex and unique. Stay flexible and be creative!

If you’re looking for an expert team to put your hardware to the test, get in touch with Blink. We’d love to hear more about your project needs.