Building an IoT/Hardware Prototyping Platform

This is the first article of a series (parts: two and three), as this topic needs some more space and time. I have about half of the content written, so I will post updates as I go along.

Even though the Internet of Things (IoT) is a hot topic, with today’s tools it is really hard to prototype and test IoT products or services beforehand. Very few tools allow us to use hardware components (like buttons or knobs) together with software user interfaces (UIs). Most software prototyping tools are closed systems offering no or only very little outside connectivity. Most of them only allow us to link screens together and that’s about it.

Plus, hardware prototyping is more complex than software prototyping: In addition to software interfaces, you need to know something about hardware, of course. Programming skills are needed if you want to tinker with them. And some knowledge about IoT protocols and platforms is helpful, too. These are skills very few user experience (UX) designers possess since a lot of them focus on the design of digital-only products and services. Just google the evergreen argument whether UX designers should be able to code.

Motivation

I thought that this was unfortunate since prototyping is such a crucial activity for creating successful products or services. We need to make your ideas tangible, test them with users and evaluate their feasibility before starting to build the real thing. And since I have some experience with software prototyping tools and tinkering with hardware I started looking for a way to create IoT prototypes.


The solution I created enables you to rapidly combine hardware and software components using a standard user interface prototyping tool and use off-the-shelf hardware.


Hardware components can send and receive data to a software prototyping tool with it, and vice versa. You can read temperature data from a sensor, or track a hardware button click. Or you could send a text to a small LCD screen. And the UI prototyping tool allows you to prototype and build user interfaces without programming skills. But the solution could also be used for purposes other than prototyping, for example as a platform for escape room puzzles or to build your custom IoT dashboard.

 

What to Expect

Quick disclaimer: all of the components I am going to use are open source. All ideas that make up the solutions can be found online when you know what you are looking for. Others before me have explored and followed similar paths. And since I am standing on the shoulders of giants, I want to return the favor and share what I learned and explain what I came up with. None of this is private or confidential. It’s a new application of existing knowledge.

Since the solution is made of several parts, I will not describe all the steps needed to build the platform in full detail. This would be too big of a task. Instead, I will explain the underlying concepts and how they are related and will point to more detailed information and tutorials.

 

Prerequisites

Below are things that will make it easier for you to follow along. But none of it is really a must. As stated before, you will be able to find additional information online if you look for them.

  • Knowledge in UX/UI prototyping
  • Understand what a web server does
  • Some basic HTML/JavaScript knowledge helps
  • Some basic knowledge about electronics and hardware components
  • Not being afraid of the command line
  • Being OK with researching topics online

With this out of the way, let’s get started…

 

Vision & Guiding Principles

As we learned in UX 101, all products should start with an idea, a vision, or a statement that captures its essence. Here was mine of building a UX prototyping platform: Be able to build physical(IoT) prototypes, combining hardware and software user interface elements, fast and easy.

Even though this is quite a broad statement, ease of use and being fast were key aspects of the concept. To better capture the concept, I wrote down some guiding principles. These were meant to help me make design decisions when building the solution.

  • Use an existing software prototyping tool. I didn’t want to overcomplicate existing tools or break the tools’ workflow when adding hardware.
  • Use off-the-shelf hardware to be able to use open-source libraries and drivers, and harvest the knowledge of the internet.
  • Limit the amount of programming. Make it easy to make changes by non-programmers (read UXers) and reduce the complexity as much as possible.
  • Make it self-reliant and robust. The platform should work out of the box. It shouldn‘t rely on an internet connection. You will never know where your prototype will be used. Plus, it should run without any hiccups for an extended period.
  • Make it modular and flexible. Make it easy to swap or exchange parts of the solution. Make it easy to add parts.
  • Allow for a division of labor. Try to separate the software and the hardware prototyping part as much as possible, since often different people with different backgrounds will work on this (e.g. UX designers, creative technologists, and developers).

All of these statements explain what makes the solution easy to work with and allows for fast results.


Requirements

When thinking about prototypes that integrate hardware and software prototypes I came up with the following needs:

  • We want a stand-alone box to be our server. It should boot up and be ready. And it should be accessible remotely since we don’t know how and where we will use it.
  • We want a prototyping tool that produces HTML and the HTML needs to be accessible to us. HTML we can extend and tinker with. We can add and enhance it. Tools like InVision are of no use.
  • The HTML code must be stored on a web server then we can update and change it on the fly. Plus, we can view it on different devices.
  • We need a way to update the HTML prototype based on the data we receive or send from the hardware.
  • Thus, we need protocols to transfer and store information between the hardware components and the HTML prototype.
  • We want wireless connectivity between the hardware components and the server. This removes the need to solder or connect wires. The components can then be located further away from the server box.
  • The behavior of the hardware components must be easy to update and change. So we can still make changes to the prototype without taking everything apart.

These requirements did not only help me make design decisions but will also provide some structure for the notes to come, as you can see in the second part…