What is an IoT Prototype and Why Build One?

There are three reasons for building an early prototype of your IoT product is manifold: to test the concept with your target audience, to check that the technical requirements match your expectations, and ultimately to validate your business case.

But what should an IoT prototype be like and what should you expect from it? We regularly work with customer projects that start with an early prototype and end up as a successful business. This article is a condensation of our experience with IoT prototyping and the underlying building blocks.

An IoT prototype consists of:

• A user interface, such as a smartphone app or web frontend
• A hardware device
• Backend software, that implements the business logic
• Connectivity

Let’s look at them in detail.

The user interface

The user interface is what the users will see. This usually comes in the form of a web frontend or a smartphone app.

In the IoT world, this part is often overlooked because people typically prefer to dive into the details of the hardware device or the connectivity. Don’t fall into this trap.

Because the user interface is the first thing that people will see when they look at your product, it pays off to make this look good. First impressions last.

For our IoT prototype, the user interface should do two things:

• Prove the value of the system to the user
• Allow users to interact with and explore the system

Proving the value to the user

The primary purpose of the user interface in the context of IoT prototyping is to prove the value to the user.

This leverages one of the key killer features of the IoT: the ability to compute and display customer value in real-time.

For example, the value that a smart lighting system brings is that it saves power (and therefore money) to the customer. Because the system is always connected, and reports the current power statistics, the amount of power that we save is always possible to compute.

We can therefore display the amount of power saved to the user in our user interface – there by constantly proving the value of the product to the user.

Allowing users to interact with and explore the system

The secondary purpose of the user interface is to allow users to interact with the system.

It may sound strange that user interaction is merely the secondary purpose, and not the primary. But this is because we are building a prototype, and not the final product, and the purposes are slightly different. The prototype is meant to validate the business, which is a similar but somewhat different goal from the final system, which is to bring value to the customer.

In the user interface, the users should be able to see the data generated by the system and dig down into it. This allows us, as the product owner, to study what the users feel is important, as it may be something different from what we initially thought.

In our experience, the best technology to build the user interface for the first IoT prototype is the HTML5/JS/CSS combo used on the web. Today’s HTML technologies are highly responsive across devices, beautiful, and allow for very quick iterations. Also, there is plenty of engineering and design talent available for designing and implementing an HTML interface.

The hardware

The hardware device is the part of our prototype that most people think about when thinking about the IoT. But it is only one piece of the puzzle.

We need the hardware device to reach out into the physical world. The hardware device includes one or more sensors that measures something in it physical environment, or an actuator, that affects something in that same environment.

In addition to the sensor or actuator, the hardware needs some way to communicate, usually through a wireless connection.

But the technical requirements are not the only requirements: the hardware also needs to look (reasonably) good in the hands of anyone using it.

While we cannot expect to see Apple-style hardware at this stage of the process, we can leverage the latest developments in 3D printing to enclose all of the electronics and hardware into a nice looking enclosure.

While we cannot expect to see Apple-style hardware at this stage of the process, we can leverage the latest developments in 3D printing to enclose all of the electronics and hardware into a nice looking enclosure.

The backend

The backend software is where the intelligence of the system resides.

The backend part of an IoT prototype is often overlooked, because it is not visible to the users and customers like the user interface, and does not have a physical presence like the hardware device. But it is in the backend that the real magic happens: this is where the business logic is encoded.

The backend both collects data in its database but also makes decisions on actions.

The backend software often runs in the cloud.

The connectivity

The connectivity is what connects the hardware with the backend, and the backend with the user interface.

The connectivity is often split into two parts: the user-backend connectivity and the device-backend connectivity. User-backend connectivity is almost always done using the usual Internet protocols, often with a REST API. For the device-backend connectivity, there are several technology options:

• Connectivity with IPv6 meshing (6lowpan, Thread) or WiFi
• Connectivity through users’ smartphones (Bluetooth)
• Connectivity through a hub (ZigBee)
• Low-Power Wide Area Networks (LPWAN) technologies (LoRA, Sigfox)

We primarily use IPv6 meshing because of the flexibility it offers in terms of different ways to connect to the Internet, the low complexity of the access points, because it does not rely on any third party infrastructure, and because it allows for very large wireless networks in each installation while achieving a very long lifetime on batteries. Connectivity with WiFi on each device provides similar flexibility but does not have a very long range.

Connectivity through the users’ smartphones is useful for specific applications such as fitness trackers, but it not suitable for larger scale installations or remote uses. Connectivity through a hub can be seen a combination of the direct connectivity with WiFi or IPv6 meshing, but does not provide the same flexibility in terms of connecting to the backend.

Low-power Wire Area Network technologies have a very good range but can only support data rates on the order of a few bytes per day, and often rely on third-party infrastructure to operate, which may have spotty coverage or not always be available.

For prototyping, the choice of connectivity mechanism is not always crucial, because the purpose of the prototype is to validate the business through the target users, and this can often be achieved through many different connectivity variants. But in some cases the business depends on a specific type of connectivity to be available, such as remote and/or very large scale deployments. In such cases, connectivity must be well-thought through from the start.

Conclusions

Every successful IoT-based product, system, or service needs to be prototyped to validate the business and technology choices. This articles looks at the four different parts of an IoT prototype: the user interface, the hardware, the backend, and the connectivity.

Because the purpose of the prototype is to validate the business, some of the decisions along the way are different than what they are for the final product. For example, the primary purpose of the user interface is not to let the user interact with the system, but to prove the value to the customer. This must be taken into account then designing and building the prototype.

When building an IoT prototype, there is no need to go too far down the hardware and connectivity rabbit holes – not until after the prototype has proved the business case.