Hardware Connectors

Hardware connectors let prototypes respond to physical device inputs — touch gestures on a mobile screen, camera input for AR features, accelerometer data for motion-based interactions, and GPS coordinates for location-aware flows. Testing these interactions early, before hardware-dependent code is written, prevents costly rework.

PrototypeTool supports both real device testing through the companion app and simulated hardware inputs through the editor for desktop-based prototyping.

Testing hardware interactions through prototypes

Hardware-dependent features are traditionally difficult to prototype because they require the physical device and often custom code. Hardware connectors bridge this gap by providing standardized inputs that prototypes can react to.

A mobile banking app that uses face recognition for authentication can prototype the entire flow — camera activation, face detection feedback, success and failure states — without implementing actual biometric code. The prototype uses the hardware connector to simulate the face detection result and test the surrounding user experience.

This is valuable because hardware features are often the riskiest part of a product. They involve the most unknowns, the longest development timelines, and the highest cost of failure. Prototyping hardware interactions early surfaces usability issues when they are cheap to fix.

Setting up hardware connectors

1. Install the PrototypeTool companion app on the target device. The app connects to your workspace over local network and streams device sensor data to the editor.
2. In your project, open the Hardware panel and select which sensors you want to use — accelerometer, gyroscope, camera, microphone, GPS, or touch pressure.
3. Create sensor triggers that respond to hardware input. For example, a "shake" trigger fires when accelerometer values exceed a defined threshold, and a "location change" trigger fires when GPS coordinates move outside a geofence.
4. Map sensor data to variables so the prototype can use hardware input in conditions and display. Compass heading can drive a map rotation, ambient light can trigger a dark mode switch, and microphone volume can animate an audio visualizer.
5. For desktop testing without the physical device, use the sensor simulation panel. Drag sliders to inject accelerometer, gyroscope, and GPS values manually. Replay recorded sensor sessions to test with realistic movement patterns.
6. Run the prototype on the physical device through the companion app to verify that real sensor input produces the expected prototype behavior. Compare physical test results with simulated results to validate the simulation accuracy.

Hardware connector pitfalls

• Designing hardware interactions that work perfectly in simulation but feel wrong on the actual device. Simulation cannot replicate the physical experience of holding and moving a device. Always test on hardware before finalizing the design.
• Ignoring device-specific differences between sensor implementations. Accelerometer sensitivity varies between phone models. Design interaction thresholds with enough tolerance to work across the devices your target users own.
• Over-using hardware inputs for features that work better with standard touch. Novelty wears off quickly. Hardware input should solve a real interaction problem, not just demonstrate technical capability.
• Testing hardware features only in ideal conditions. GPS is imprecise indoors, accelerometers drift over time, and cameras struggle in low light. Prototype the degraded-input experience alongside the ideal one.
• Not providing fallback interactions for devices that lack specific sensors. If the prototype requires a gyroscope and the user's device does not have one, the feature should degrade gracefully rather than failing silently.

Tracking hardware test coverage

• Sensor coverage: The percentage of hardware-dependent features that have been tested with both simulated and real device input.
• Device coverage: The number of distinct device models on which hardware interactions have been tested. Test on at least the three most common models in your target audience.
• Degraded input testing: Whether each hardware feature has been tested under poor conditions — low signal, dim lighting, unsteady hands — not just ideal scenarios.
• Fallback coverage: The percentage of hardware features that have defined and tested fallback behavior for devices that lack the required sensor.

When hardware connectors add value

• When the product relies on physical device capabilities like camera, GPS, motion, or biometrics that fundamentally affect the user experience.
• When testing with real users on their own devices, where device variation makes it essential to verify the interaction works across models.
• When evaluating whether a hardware-based feature is worth the development investment by testing user reaction to the concept before writing device-specific code.
• When prototyping IoT or connected device experiences where the prototype needs to simulate interaction with physical objects that do not exist yet.

Key concepts

• Hardware connector: An integration that allows prototypes to respond to physical device inputs such as sensors, cameras, or location signals.
• Device preview: A mode that renders the prototype on a connected device, enabling testing of touch, motion, and orientation interactions.
• Sensor simulation: A way to test hardware-dependent interactions without the physical device by providing simulated sensor values.

FAQ

• Which devices are supported? iOS and Android devices via the companion app, plus desktop browsers with webcam and microphone access.
• Can I test hardware interactions without a physical device? Yes. Sensor simulation lets you inject test values for motion, location, and other hardware inputs directly in the editor.
• How do I handle device-specific differences? Create device-specific preview profiles that define screen size, input capabilities, and available sensors.

Next steps

Connect one hardware device using the setup process above and verify that sensor data flows into your prototype as expected. Test the connection under the conditions your users will actually encounter before expanding to additional devices.

Related resources

• Api Bridge Basics
• Prototype Test Plans
• Integrations Api
• Prototype Workspace
• Support center
• Release notes