High-fidelity prototypes lead to better IoT experiences
A design technologist’s guide to IoT prototyping
A little Hollywood magic and IoT prototyping have a lot in common. When building connected products and services for real-world environments, it means getting creative about setting the stage for success. Parts of the process you know well: build early, build fast, test what you build, and iterate, iterate, iterate. Often, the need for quick, frequent iterations is met with very low-fi prototypes, knocked together quickly out of paper or cardboard, or rapidly sketched up in a digital illustration package.
“Quick and dirty” prototyping can get you pretty far in some product categories, but in the broad and growing field of IoT devices, it generally doesn’t. There are a few reasons for this, which I’ve learned through direct experience, and will describe in a minute. But there’s also an upside: the tools for building IoT products have gotten so sophisticated, and inexpensive, that high-fidelity prototypes are within reach for any ambitious technologist.
A major reason lo-fi doesn’t work for IoT design is that these devices are nearly always context-specific—they’re interacting with their environment, not just responding to user actions. So to get realistic feedback about your design concept, you need a prototype that can gather its own information, often while the user isn’t paying attention to it, for example, while working on a factory line, operating a vehicle, or engaging in physical activity.
This last use case, physical activity, was the focus for our long term innovation partnership with Gatorade, spanning multiple projects such as a hydration platform and sweat patch, which recently received the 2022 CES Innovation Award. I worked on the multi-disciplinary team that designed and prototyped another soon to be launched IoT product — in less than four months, we built and took onto to the field a hi-fi prototype to get to the heart of the problem. Instead of trying to predict the future, we could jump-start our understanding of the problem space by employing these specially crafted tools in real world environments.
A little sleight-of-hand
Because IoT devices interact with their environment, it’s often necessary to put them in a realistic setting; you can’t get useful feedback on a fitness tracker, for example, by having people fiddle with it in a lab. This is another reason why a high-fidelity prototype is often necessary: it needs to work in a realistic environment without demanding attention, so users can focus on the task at hand. Low-fidelity prototypes require users to suspend their disbelief, and work around the shortcomings of the prototype, which inherently skews any feedback you might get.
For Gatorade this meant running pilots in real training environments, first at a sports academy, and then with professional athletes during practice. At the end of the pilot, we conducted user interviews to pick up the threads of the app experience users were most engaged with, to push those concepts further.
To get the pilot right though, we had to give them the device and an app that behaved in a believable way. A major component was building an app with an engaging user experience — But it took a bit of sleight-of-hand: behind the app was a balance between built-out features and hardcoded database entries managed by someone on our team.
If you’re curious how we did it, I’ll walk you through the details, starting with the tech stack we used:
Mobile framework
React Native
Database
Firestore
App Distribution
Enterprise
I’ve also distilled some of the prototype learnings into guiding principles for other design technologists or individuals to navigate coded artifacts for usability testing.
Be flexible with tooling
It’s better to build off of prior experience and rely on your team’s existing expertise. Early on, we decided to use React Native Modules, rather than having the team learn Swift, even though it meant bridging the communication between the IoT device’s SDK and the React Native app. I had some prior experience with React Native, so figuring out Native Modules helped us avoid spending long stretches of debugging later on, whereas building a solid foundation in Swift would’ve been bumpier.
The takeaway
Your team should inform your choice of tools.
Build to learn
Some user flows that are simply unavoidable, like logging into the app to see your unique profile. Instead of spending time designing and building a familiar UX flow, this is where the sleight of hand comes in: we created user profiles in the database, and sent login details ahead of time, avoiding the need to design and build out non-essential screens. Some parts of the app were more like a movie set than the real deal.
The takeaway
Faking less important user flows gives you more time to focus on new and innovative aspects of the app.
Use existing tools & open source libraries
Out-of-the box solutions are great for rapid prototyping. You can build faster, and trade one software for another. We initially used Airtable as our database, which worked nicely as a collaborative tool for the non-technical members of the team. We quickly found out it wouldn’t work for the pilot when we hit the API rate limit of 5 requests per second during our first internal test. We then integrated Firestore, a cloud-hosted database with a rich suite of tools. One of its nicer features is that it sends the listener an initial snapshot of the data, and then another snapshot each time the document changes. This meant the data being displayed to users was never stale, making the app feel incredibly responsive.
The takeaway
Don’t build a part of the app from scratch if it doesn’t directly inform your learning goals.
Keep the chaos organized
Keeping code composable and lightweight helps avoid technical snags which can derail the prototype. I found that using meaningful names decreased the need to document the code, and following the DRY principle made swapping out libraries more seamless. Refactoring as a practice while building out the prototype makes it less likely for small issues to snowball.
The takeaway
Keeping your code in order early on helps keep blood pressure down when debugging on the field.
Test internally
Internal tests were critical to making sure we’d be able to maximize learnings during our week on the field, rather than debugging, or worse, deterring users from using the app. IoT devices have additional complexity due to the Bluetooth component and initial user setup. We addressed these, and other potential sources of trouble, by running group testing sessions with people inside Smart Design first.
The takeaway
Mitigate your biggest risks by testing internally to identify issues before putting the app in front of users.
Focus on the MVP
Innovating in a new space meant growing our team of designers, technologists, engineers and product managers before setting out to conduct a real world pilot. We also engaged our IoT sensor partner early on, to extend the SDK to support new features. With so many moving parts, everything needed to come together under a unified experience, so we focused on the MVP — Minimum Viable Prototype. We simplified our core flow down to just a few actions: connecting the device, interacting with it, and pulling & displaying readings. From there, we built out the app’s user experience, integrating newer versions of the firmware as our IoT partner released new features. So even though each piece was at a different level of technological maturity, they still provided a unified experience.
The takeaway
Remember that a coherent user experience for your prototype matters more than what tech you use or how mature it is.
Explore our work in technology
About Eva Peng
Eva Peng is a Design Technologist who brings together technical know-how and user experience design. The Swiss Army knife of the team — she enjoys bringing designs to life and answering questions through technology. Previous stints were at frog design and The New York Times. Notable clients include Walmart, IBM, Square, and United Technologies. Eva holds a BFA in Architecture and Human Computer Interaction and a Masters in Information Systems from Carnegie Mellon University.