(The On-Ramp To IoT series is based on the Prototyping Connected Devices webinar co-presented by Todd Zielinski and Bill Horan and hosted by O’Reilly. Read posts #2, Getting Connected and Communicating; #3, Selecting a Cloud Provider; and #4, Prototyping Your Connected Device.)
It’s no secret IoT devices are on the rise. Only a few years ago mobile devices and PCs were the denizens of the Internet. Now we’re seeing everything from doorbells to washing machines that connect.
This trend is only going to grow. By 2020, there will be about 30 billion connected devices. Samsung’s CEO went so far as to say that within five years, 90% of the company’s product line will be connected.
IoT is where we’re headed — and there’s a lot of development work to be done and a lot of different ways to do it. As long as the costs of networking components, processors, and infrastructure continue to decrease, we’ll continue to see rapid adoption and expansion into new markets. These changes are also making it easier for developers of all levels to try their hand at IoT product development.
Bresslergroup has been asked to develop IoT products ranging from home automation devices to medical tools to niche products like the Bruvelo app-connected coffee maker. In this post, the first of four in a series on developing Internet of Things prototypes, we’ll cover the basic anatomy of an IoT device and share our integrated development process — our framework for developing IoT devices quicker and smarter. Because in the IoT world, where the technology landscape can shift in a matter of months, you’ve got to be quick!
Anatomy of a Connected Product
First, a step back to look at the big picture. Connecting a device to the Internet adds layers of complexity. For developers who want to build IoT devices, and really for anyone who’s curious about how they work, this diagram can help you understand these layers and how they interrelate.
Working from the inside out, or from cloud to user, the first layer is electrical engineering (EE). The EE guts contain the hardware and firmware that allow the device to connect to the cloud and talk to the Internet and other devices. By definition, IoT devices communicate directly with the cloud, requiring less interaction from the user. To use a common example, an IoT thermostat learns your preferences and automatically changes your settings so your house is the ideal temperature for you at 8 a.m., 3 p.m., and 11 p.m., without you having to lift a finger. To make something like that work, we on the EE side need to make sure the device is receiving quality inputs on a consistent basis.
Mechanical engineering (ME), the layer surrounding EE, denotes the device’s physical makeup. Then comes industrial design (ID), which wraps all of the above into a package that’s physically appealing, ergonomic, and reflective of brand values.
Encompassing all of a user’s interactions with the device — whether they be physical, digital, gestural, voice-activated, etc. — is interaction design (IxD). This and the user interface (UI), whether it’s a screen, physical buttons, a combination of both, or something else entirely, define the product experience. (User interfaces are keeping apace with technology. As my colleague, Bill Horan, has written about, interfaces are becoming less screen-based.)
Our Shared Process
The user experience and the technology that makes it possible are developed by two different disciplines at Bresslergroup — interaction design and electrical engineering. But when two aspects of a design are tied so closely together, it makes no sense to develop them apart.
Just as we designed an integrated industrial and interaction design process to keep physical and digital design in synch, we’ve come up with a process that aligns electrical engineering and interaction design from the product’s kickoff.
This integrated process saves us time by preventing us from having to double-back and redevelop features later. Our process is defined by bursts of parallel development, punctuated by check-ins at crucial junctures to make sure the intended user experience and its technical underpinnings match up. The “check-ins,” when we put our heads together, are when the product makes its biggest leaps forward.
The process for each device is different, but in general it starts with design research. We do research to understand what customers need, which problems need to be solved, and what the customers expect. This allows us to define some initial requirements for the product (what it should be able to do and for which types of users).
Burst #1: User Flows and EE Research
Based on those findings IxD will start to develop use cases, or ways people might use the product, and start to create user flows — or maps of how a user might interact with the product while they’re accomplishing various tasks.
The EE team works separately to research and price out the parts, sensors, and microprocessors that will make the device unique. It’s important to determine customer expectations early on so we can select the right communications profile, the right amount of memory, the right range for the antenna, and so forth. We also consider security at this point. All of this will impact the physical device.
Check-In #1: Fit Solution to User Requirements
The two teams come together to make sure we can make a device that will meet user needs using the parts available on the market.
The IxD side might say, “Hey, here’s what the user wants. Here are the things the user will try to do and the various needs the user has.”
And the EE side will say, “Well, here are all the various pieces and ways of making that work.”
So we’ll come together and we’ll make a decision based on what works best from cost, footprint, and connectivity standpoints. Most importantly from a user standpoint, how are we going to get the best solution to work?
Burst #2: Begin To Develop
We break off again, and the IxD side develops wireframes and low-fidelity prototypes to help test the chosen concept early. The EE side now has a beginning scope of what we’re building so we try to get together some chunks of the subsystems we’ll be using in a particular product. We’ll breadboard each individual subsystem, test it, and integrate them to begin to form the working components of the system. This gives us an idea of how the systems we’re starting to choose will actually work for this application. That takes us to the next step: testing.
Check-In #2: Rapid Insight Testing
The two sides come together for rapid insight testing, where we evaluate low-fidelity prototypes with representative users. Even this early in the process, patterns emerge very quickly when you test rough prototypes with a sample size of about eight people — family and friends or people you recruit. Analyze these patterns and you’ll see where you can improve. Integrate this qualitative feedback into the next prototype and test again. We loop through several rounds of rapid testing and iterating.
Burst #3: Specs and Prototyping
IxD will update their wireframes and user flows to fix any issues found during testing, and they’ll move on to the visual design of the user interface. They’ll apply colors and branding, and all those little bells and whistles that create a really delightful user experience. They’ll start working with the development team to create a design specification and export all the assets the developers will need to start building out the UI.
From the engineering side of things we’ve already gone through our breadboarding phase and our initial component testing, and now we’ll start working on actual schematics for an alpha prototype as well as the board layout. This will take us into the first true schematic for the device as well as a framework for the firmware and the integration between firmware and hardware so we can start bringing it together for UI development.
Check-In #3: UI Development
Both IxD and EE work closely with the developer — EE to make sure everything is working and IxD to make sure everything is being implemented as was detailed in the design specification. Once that’s together we have a connected prototype to use for testing.
Communicating To Save Time
The length of this process varies from project to project. For Bresslergroup a “typical” design cycle might be six to eight months, whereas in past places I’ve worked, a short project was closer to 12 to 18 months. It can vary by industry. In the industrial and aerospace realms, it’s more like 36 to 60 months.
Since IoT moves so quickly and the landscape can transform in as little as three months, it’s important to be as quick as possible. The shared process certainly helps with that.
Collaboration early on and consistently throughout the process, almost daily, is key to making things go quickly. Having conversations all the time about exactly what we’re working on and how we’re working together is a big deal. I don’t think we get through a day without talking about some piece of a project.
(On-Ramp is an ongoing series explaining engineering techniques used in product development.)