More Than IoT: Building a Connected Experience
Devin Moore, Big Bang
kHUB post date: March 14, 2020
Originally presented: November 5, 2019 (PDMA 2019 Annual Conference)
Read time: 7 minutes
Download the Handout
Consider the electronic device closest to you, probably your phone. Take some time to consider it and the parts intended for interaction. Connected products typically have a physical and digital presence, embedded with processors, sensors, software and connectivity, and are also referred to as integrated, IoT, or smart. These products that are at the intersection of physical and digital are more than the sum of their parts, and because of the wicked complexity of integrated products and services, it has become necessary to rethink the way we develop these devices. How do we ensure that the developers from such varying backgrounds and perspectives work together to optimize the intended customer experience with the product?
Typically there are four primary facets of an integrated (or connected, or IoT) product: 1) the visual composition (industrial/graphic design), 2) interaction (UI/UX), 3) mechanical and electrical components (the hardware) and 4) the firmware and the software (the digital). Managing a connected device project requires guiding different teams that can have very different timelines and processes while trying to avoid the siloing of resources and activities, and maintaining or thoughtfully adjusting the user storyline.
And to state the obvious, software and hardware are different from each other. In general software is built and can be distributed in an iterative process to fix any bugs or design flaws, improve performance, or add new features. Hardware is static and far less agile; any flaws to the hardware will stay with the device until it undergoes a full redesign and new production run. Upgrading is impossible, unless anticipated early in the hardware’s development. Even ten years ago, the overlap between physical and digital design was minor compared to today; now the overlap is so inescapable that our development teams are having to completely rethink the development process.
I’ll give an example of a fairly simple device developed for Bard Medical, now Beck And Dickenson, when I was at Big Bang, a product development consultancy I founded. It is a sales tool that measures and displays the force of catheter insertion. The experience consists of a series of infographics displayed on a mobile app which runs on a tablet, and a wirelessly connected hardware device. When a user inserts a catheter in the clear ‘sled’ attached to the device, a custom built load cell transmits data via a microcontroller with custom firmware to the tablet and mobile app. Industrial design, digital interaction and visual design, IOS mobile development, firmware programming, electrical and mechanical engineering made up the project team resources. It can be surprising the resources needed to build connected devices, even the simple ones.
We can no longer expect hardware and software teams working in silos to produce comprehensive, cohesive, and engaging device experiences. In addition, companies are not just competing with their competitors – today’s devices are competing with the experience of EVERY product and service that our users meet!
“The last best experience that you have anywhere suddenly becomes the minimum expectation for the experience you want everywhere.” Matt Candy, General Manager & Global Leader, IBM
It has become increasingly important to create guide rails to help with, what I call, "code sharing" across the disciplines to better design in the increasingly complex and networked systems on which we find ourselves working. We have found two tools that work well together: 1) Storytelling and 2) Swim Lanes.
Tool 1: Storytelling
It isn’t about ‘designing an experience’, it’s about telling a story that unfolds with interaction.
Stories make sense of our world and help to share that understanding with others, and good stories are engaging and immersive. Everyone can relate to stories, and they can bind us to a common experience and goal.
Developing a shared narrative around how users will interact with an envisioned product can be one of the most powerful and often overlooked processes a product development team can use to produce the best work. A story can bring experiences to life, allowing us to anticipate how users will interact with a product at every sensory level. We can begin to familiarize ourselves with the environment, the five senses, and motivations (the “why”).
In the beginning, it helps to explore the possibilities and frameworks of the idea, and can then be revisited and revised as the project progresses to ensure a shared understanding. Along the development path the narrative can be used to monitor progress, and can be used to evaluate whether our experience resembles the initial vision.
When it comes to developing the type and format of a narrative for guiding the development team, keep in mind that one size does not fit all. There is plenty of information about story techniques online. But in any story you want to capture the who, what, and why of a product experience. Over time, we’ve learned to vary the scale of our stories, based on the client's personality, budgets, team size, etc. Our stories take a variety of formats, including quick videos, value propositions (which are simulated sales sheets that highlight features and benefits from a product management viewpoint), to the simplest format, User Stories, which we get from our software teams.
Tool 2: Swim lanes: crafting the experience
The development of a connected device requires a dedicated team with diverse skill sets, from electrical engineers and chemists to designers and developers, to work cohesively and effectively. It is more important than ever for the entire development team to have a common understanding of the intended finished user experience. Building and referencing an experience driven Swim Lane diagram produces a clear understanding of the essential actions needed to create the ideal end user experience.
Generally, swim lanes are a flowchart that divides information into visual categories. We use this basic idea to visually divide user flows and device processes into categories to help distinguish each team or team member’s specific contribution towards the design. The swim lane building exercise allows our team to access and organize more input from key players, and keep everyone working towards the same end vision, which results in a better user experience in the end. And while this is secondary, the activity of building swim lanes can also be a terrific early team building experience.
With the product vision in hand and a deep understanding of the user, the starting point is developing User Stories, a tool used in Agile software development. Typically following the format “As a _____ I want to ____ so that I can _____,” User Stories describe the user, the task, and the motivation, and can help developers envision a feature or experience from a user point of view. We produce user stories around scenarios that will be useful guides throughout the development process. For example, we might focus on a collection of stories for the device: start-up, the device’s primary task, the out-of-box-experience, etc. We rely on product team discussion and our intuition to tell us which stories, and how many stories, are essential to capture the true product experience.
We then gather the User Stories and project team members and create our initial swim lanes using large sheets of paper and post-its. We organize our horizontal lanes into areas of responsibility (industrial design, user interaction, mechanical engineering) under a user flow lane (think of this as the starting platform during an actual swim race.) Depending on the desired specificity, or the team composition necessary to develop the device, we can divide these further (ME vs EE, software vs. firmware, etc.).
We attach post-its for the actions/activities (problems to solve) in the respective areas of responsibility, organized in columns under the user experience steps. The user experience flow (how the user will operate the final device) is our guide. Individual elements are then connected via lines and symbols, just like in a typical flow chart, to represent relationships, actions, and flow.
The diagrams are then transferred to an online digital tool, such as Lucidchart, Draw.io or Creatly and are updated as needed. As projects move along, new elements can be easily added and subtracted. The structure of the document as a flow permits development teams to rapidly understand how their lanes will be affected by changes without frequent meetings, and keeps the targeted experience cohesive.
In developing connected devices we’ve learned that it’s not just the users that are looking for compelling experiences and connections. The people developing the experiences have the same wish, and using tools that help the variety of disciplines and personalities “code share” with each other, around a shared vision, makes for better solutions and products that create those experiences that connect with users.
It is critical that a multi-disciplinary connected device development team shares a common vision for the customer experience that is maintained and developed throughout the development lifecycle. Experiences create connections. Connections can engage, inspire, and build customer loyalty. And customer loyalty ensures a successful product and strengthens the brand.
About the Author
Devin Moore is the founder and former president and creative director of Big Bang. He is an innovator and designer at the intersection of physical and digital, helping companies develop products that people love.