Part Four

Connected Solution Design: Mastering Storytelling and Tension

Start with Why

Start with ‘Why’. It’s an extremely popular book by Simon Sinek, as well as an enduring rallying cry of storytellers and strategist everywhere, due to its ability to cut to the heart of the matter. Because at the end of the day, no one buys what you do, or how you do it. They don’t even buy IoT. The only thing that consumers care about is the outcome and the value it brings to them. They buy the why should I care.


According to the Harvard Business Review, digital disruption is rapidly increasing the churn on the once-stable S&P 500, predicting that three quarters of its current rank-and-file members will be replaced by 2027.

IoT is not a strategy

It’s an important distinction in an age where approximately 95% of new products fail, and 87% of consumers possess a foggy-at-best awareness of what IoT really is. No one will buy your smart tupperware because it’s smart tupperware – if it doesn’t solve a real-life problem, you’ve already committed a fatal error. The potential value driven by IoT is too great to waste on cheap tricks, especially with your company’s future on the line.

The connected world is changing the face of design

Designing for a connected world demands a different approach from designing for digital or physical products alone. The challenge of creating a coherent connected experience is multi-faceted and complex — for example, there are far fewer standards for design in IoT, products often have physical and digital interfaces, and suddenly factors like location and connectivity matter deeply.

But where do you start? Defining what makes a successful user experience is still key.

The UX of ‘invisible’

In the words of former Apple exec and BeOS founder Jean-Louis Gassée, “Simple is hard. Easy is harder. Invisible is hardest.”

A well-designed connected experience should appear seamless and completely invisible to the user. And predictably, the attribute that creates the most value is the most difficult to pull off. To illustrate, we need look no further than an experience so essential to the digital world that it’s become a verb:

Google search homepage

Google’s search engine is driven by some of the most sophisticated technology and advanced engineering in the world. The product has revolutionized how businesses present themselves online and how we, as consumers, discover information, goods, and services. Yet this interface presents a simple search field, which captures roughly 3.5 billion daily searches submitted by 1.2 billion users.

This is the ultimate goal of designing for IoT: hiding immense complexity behind a simple, seamless experience. But the technical landscape upon which we imagine this experience is very different, requiring immense coordination of backend infrastructure and front-end design.

The art of system-design thinking

Before your design team can start putting together journey maps and flows, this larger ecosystem must be designed to take certain technical considerations into account. This is because in IoT, the user interactions are intrinsically tied to how the connected product works.

As such, IoT shifts designers to think in terms of context and connected worlds, and turns hardware and software engineers into designers themselves. User experience grows beyond a one-to-one relationship to become a web of touchpoints and conversations. All technical components must remain as invisible as possible – as does the burden of transporting, processing, storing, and analyzing data. And your product must do all of this without noticeable lag or requiring too much user participation.

A tale of two layers

Your multidisciplinary team must design these technical considerations to seamlessly communicate across two distinct layers.


Unfamiliar with the edge? We break down IoT’s many technical considerations in The New Tech Stack. Read more.

Edge Layer

This is the experience layer, and how your users interact with your IoT product. It’s important to keep in mind that this layer may be comprised of many touchpoints. A user may interact with, for example, a smart home speaker, a companion app, the physical sensor itself, an email app, and push notifications – all for a single device. Because of the distributed nature of an IoT product’s potential touchpoints, the user experience must be mapped out across multiple devices while promoting continuity of design between them so as to appear seamless.

Users and Edge Layer for digital and physical touchpoints

Infrastructure (platform) layer

This is the underlying layer that powers the user experience – it’s comprised of the platform, tools, services, and underlying product framework. It’s where architecture, hardware engineering, advanced software engineering, service design, and manufacturing considerations such as BOM (bill of materials) cost all come into play. 

Enterprise architecture layer

Success requires tension between infrastructure and edge layers

The cost of mistakes get higher and higher as the product gets closer to its launch – thanks largely to hardware components and manufacturing considerations – it’s important to aggressively manage all trade-offs proactively. The ideal system design must be tested against the needs and expectations of all team members early and often to ensure that these trade-offs do not negatively affect the user.

This list is merely a sample of the considerations your team must make when designing or tweaking the experience provided by any physical product:


Interested in how this all comes together? Read about lean product development for IoT.

  • Systems blueprint: Should a specific feature appear on the mobile app or a connected device? Implementation considerations must be a part of the design process, and require a careful mapping between each human touchpoint, and engineering capabilities – certain features may be handled by firmware, and some by hardware. The pros and cons must be thoroughly assessed for each.
  • Behavior flow: Your user experience must be mapped out to match your systems blueprint. The technical considerations therein will determine what edge devices a user interacts with, how, and when.
  • Edge cases: With so many potential moving parts, the number of edge cases your user may face increases – loss of connectivity, lack of interoperability, third-party integrations, empty states, complex tutorials, and more must all be considered when creating IoT interfaces.
  • Actionable insights: If you intend to use any of your data collected to gather insights on product use, internal processes, or manufacturing processes (and you should), you will need a way to analyze and view potentially disparate data types, and ensure that data delivered to the right people at the right time.
  • Costs: If the BOM costs make a product prohibitively expensive for prospective customers, the selected materials may need to be reassessed, or the revenue model may require changes.
  • Maintenance and support: The total cost of DevOps teams and any additional support or maintenance needed may drive up costs, or prove too massive for a product to be viable.
  • Scalability: Where do you see your MVP in one year? In five? Ensuring your design system and technical ecosystem are both scalable will better ensure future success as your product and audience grow.

Never design in isolation

Each of these considerations are equally important, so all are integral to designing a connected solution that successfully crosses the chasm. For that reason, designers must work in tandem with software architects and hardware specialists to ensure feasibility from technical, financial, and organizational standpoints.

Organizations can’t look to partners capable of only delivering on one aspect of the solution, because each is a major driver of the solution’s success. The ideal partner is one that is multidisciplinary, one that can see the whole picture, and deliver a truly connected solution.

Share this article

Give us your hard problems

Build a reputation for innovation, and embrace the full power of your future with Rocket Wagon.

Let's Talk