Like Houdini, any UX designer deployed to a connected product development program starts their performance in a trap. Unlike Houdini, you, as a UX designer, are straitjacketed by conflicted, changing, torturous ambiguities: user needs, customer needs, hardware needs, software needs, and of course, what “the business” needs from your connected product experience design.

The business side, where I live, seems least able to articulate what, exactly, they need from your participation and work product. We’re also the likeliest to undervalue user experience design and downgrade it into a performative checkbox activity, despite the woefully ironic self-harm inflected by that unwitting belittlement.

I’m going to fix that today. In this article, I describe precisely how UX for connected products differs from traditional web and mobile UX design, then unpack the specific tasks you can undertake and critical impacts you can make on connected product strategy, ground-up implementation, and post-launch iterative improvement. And I’ll do so in nauseating detail.

You're unlikely to do everything here on any one connected product development effort. What you will do will prove eminently useful. It doesn't matter what kind of UXer you are: researcher, pure design, data nerd, whatever. Get stuck in, there's plenty to do.

Connected products need designed experiences

From the outside, UX design appears to be undergoing a catabolic moment where its grandiose, complex, taken-as-gospel concepts are beginning to get broken down into smaller, simple ones. It’s not the end.

UX, get back up

Those of us observing the UX discipline from the periphery have indeed witnessed UX’s recent self-declared implosion and resultant gratuitous handwringing (and cynical dogpiling) about your discipline’s decline. The end is nigh: employment’s crashing, the golden age is over, research isn’t valuable, etc. The business side doesn’t see your utility, pixel pusher, so you can pack your Post-it notes into your designer messenger bag and leave. Summer's children have finally met winter.

Wrong. Completely wrong! I know that’s how it feels, but that’s now how it is.

Those of us in engineering, operations, and other disciplines do not see you that way. From all of us developing connected devices and other IoT-powered offerings: UXers, we need you to succeed. We know you well enough now to understand that the same innate talent fueling your creativity also powers your intense navel-gazing.

We need you to make unique, insightful contributions to the connected product development process. Your job isn't to replicate work, jockey Figma, tart up pictures, become a servile documentarian, or accept ignorant rationales about "business decisions" or reductive whinging about finances or the C-suite. If you must step into a financial argument, then yes, your job is to help the business make money, not by becoming a walking cost-benefit analysis, but by making your company’s old stuff good and by making your company good new stuff.

UX from the connected product owner’s seat

Given the sheer size of a product development program budget, the stakes are automatically high in connected product development. Not just for bad design, but also for mediocre design.

Pretend I’m the product owner. If you, my UX design team, don't succeed in designing a value-adding digital experience, one that offers a dignified solution to a painful customer need, then I, and our entire team, failed to make the connected version of our product worthwhile. We may have class-leading hardware, but if the digital component’s mediocre and we’ve simply made an app-based remote control, it wasn’t worth the premium I charged over the non-connected version. We've added negative value if it sucks. It certainly wasn’t worth the marketing and software development expenditures I approved.

If I bypass insights-generating research and rush to production, we can only ever build the obvious. We’ll launch with lowest-common-denominator digital—a product made by taping together other people's commodity tech with our name, yours and mine (plus a year of our lives), plastered to the side. We certainly haven’t created a barrier to entry.

We go to market with a flimsy excuse to get our app on someone’s phone in the vain hope that our amalgamated mediocrity is good enough to grab share from some competitor. That is, before our whole segment fails because we were all guilty of slapping anodyne IoT tech onto our hardware offering and crossing our fingers. Your design capability will help us succeed where hope fails.

Distinguish connected experience design from UX

The curse of being a professional is that it’s easy to slip into autopilot, rely on your expertise, and ignore relevant context (just ask your doctor). In our experience, most UX practitioners have the requisite skills, but need some new perspective in order to succeed in designing for IoT and connected products:

1. Connected experience design happens inside a greater product development plan

In traditional UX, designers, engineers, and support disciplines (QA, BA, etc.) craft digital experiences for users and they deploy to some digital location. It’s not so simple when you’re making a connected product.

1. Acknowledge every stakeholder. When physical product development and digital design intersect, the stakeholder list expands. Industrial designers, mechanical, electrical, marketing, quality, manufacturing, legal, and senior management all rely on digital design work and work product to succeed in their roles.
2. Understand the master schedule. In product development, connected experience design phases live inside a master schedule driving the whole product's creation from conception to retail distribution. UX is but a piece of a much larger puzzle.
3. Tone down Agile. Agile methodology and connected product development can mix, but not well, and not in large doses. Agile works inside development and iteration phases, but physical product engineering requires a defined endpoint prior to manufacturing. While the digital piece of a connected product doesn’t technically require the same stopping points and distinct phases, you’ll still have to create them because your digital design effort is now part of a much larger movement.
4. Consider the cascade. Problems in experience design production or implementation ripple throughout the whole master schedule. When experience design is complete, that represents at most 5–10% of the work between the idea and the store shelf. Even before launch, experience design implications may introduce hardware concerns that push back upstream, impacting people who thought they were done.

Stop for a moment and understand that in past decades, digital properties were abstract from core business operations and existed entirely within a managed construct like a browser or a machine-specific HMI. Connected products and services extend your business’s offering, integrating digital design into its day-to-day operations and value proposition.

2. Accept that design and engineering are intertwined and use this entanglement

“But design should…! And engineering should…!” Yes, we know. But users don’t, and they really don’t care about your business’s self-imposed boundaries. Reset yourselves, and establish the following system-wide standards and expectations before setting off:

1. Review your design intent __with system-level implementers before committing too much.
2. Set performance standards. Acceptable system performance might mean collecting, analyzing, and sensing less than hoped for.
3. Draft an error handling plan alongside your performance standards.
4. Embrace engineering solutions to UX problems. For example, if machine learning eliminates user tedium, use it. If backgrounding tasks minimizes pain, use it. Don't waste time (yours or users’) designing better garbage.
5. Hold your nose and tolerate UX solutions to engineering problems. Design can paper over unfixable technical problems in small doses. It’s OK. Be clear about what you and the company are signing up for, though.
6. Know your capture architecture: IoT implies that data is coming from a device. Designers need to understand that data and any corresponding gaps or utility.
7. Know your compute architecture: where will each core compute function occur?
8. Understand data sequencing. Will you store and forward? Do users just reconnect and go from there? Do you save anything? When is data available (and unavailable)?

Connected experience design is more technical than most experience design, and more design-y than most software engineering. You’ll need that hybrid mindset to succeed in designing for an experience that integrates physical and digital and hard and soft.

3. Separate design for innovation from design for production

Connected experience design exists in two distinct places: design for innovation (DfI) and design for production (DfP). Whereas DfI must happen before any agreement to proceed to manufacturing, DfP must be complete before softer commitments nearer to launch (warehouse firmware flashes, production cloud deployment, marketing announcements, beta testing, etc.) Not all UXers are suited for both types of design.

Design for innovation occurs during product planning and advanced development. DfI combines user research with rapid prototype design to test and inform direction, layering both value and constraints into pre-engineering and production phases:

1. Conduct exploratory research to reveal new avenues of customer or business value.
2. Focus new ideas into prototypes that enable value-oriented testing.
3. Inform requirements needed for system engineering.
4. Set up production design with business- and customer-relevant work.
5. Facilitate engineering with comprehensible prototypes.
6. Hasten handoffs by reducing design ambiguity early.
7. Hold downstream teams accountable to a documented, business-approved vision.

DfI becomes a cycle of research/testing and prototype design, an engine always driving improvement. Don’t try to do it all—this isn’t rote doctrine—just do the parts that destroy the barriers blocking progress. This is the work.

Design for production (DfP) defines how implementation teams can make a proven design concept work inside or alongside established technical constraints or as part of a pre-existing experience, then delivers the artifacts required for implementation to specification:

1. Design the end-to-end product experience in any formats necessary.
2. Cover gaps missing from the work to date.
3. Solve sticky, constrained design challenges not seen early in the process.
4. Collect input, iterate, test, and refine throughout software development as scheduling constraints allow.
5. Curate a comprehensive design system to accelerate designer onboarding and future prototype design (if this project has a future).

Design for production equips implementers, marketers, and patent teams with the tools required for a class-leading outcome. This is the work product.

When you participate in project planning, request time for both functions and define precisely what you’d like to deliver from each. “Do X, get Y, Y helps teams 1, 2, and 3 do Z.”

Don’t skip strategy but don’t overdo it

It’s the overdoing bit that taints UX’s credibility most. To prevent that, focus on a handful of gating strategic issues, hit the critical questions like “why would people use this?” and let the rest burn (for now).

4. Define and communicate critical context

UX lays part of the foundation for the connected product development team’s collective understanding of the user’s and customer’s experiences. Insights here set baselines and erect fences around the design space.

1. Anchor the user journey in value delivery (“customers find X valuable because Y”). Anchors exist in the brand or business’s key value, so nail your experience to them. You’ll know you’re right when your journey’s accurate, realistic, representative, situation-aware, and a touch aspirational. Anchors also help externalize the cause of your product development program—this thing is for someone else who isn’t you.
2. Define physical context. Industrial hardware takes us outdoors, supply chains put you in trucks, medical devices take users places without WiFi or cellular, etc.
3. Map the physical product experience __itself. How would (or should) a user interact with this device if it wasn’t a connected product?
4. Create an attention architecture. Your user isn't just focused on their phone. Where will their attention be? Where are the distractions? Knowing when you might lose attention (and how to get it back appropriately) will prove critical to viability.
5. Guessing sucks, go learn. Knowledge gaps (especially unspoken knowledge gaps) tank projects every day. When a gap in knowledge makes designers, engineers, and product owners uncomfortable, it’s time for a short research mission.

Context informs direction, so simple maneuvers like value anchors, product experience one-pagers, quickie interviews, and informal usability tests work better than multi-week research programs not because they’re “agile”, but because the specificity of their questions and clarity in their results removes bad options from the strategic menu instead of polishing nearsighted details. Aim for “is good/is bad” instead of “X% gain in efficiency”. Bonus points for opportunism!

5. Ground product strategy in reality

Fantasy runs roughshod over connected product strategy. Here’s how to keep it under control:

1. Everyone in the value chain must win. Ignoring, forgetting, or failing to add value to any player in a given connected offering's primary value chain is usually fatal. Oftentimes, the connected portion of a connected product entails more work for somebody.
2. Separate your product from your offering. A classic product development trope, but digital makes this distinction clearer and more important. They’ll come together in practice, but it’ll help to distinguish the two in development.
3. Demonstrate independent and complementary value. Think of your connected product experience as the physical component alone, the digital component alone, and the combined experience. The digital portion of any combined hardware/software offering must offer its own value and offer complementary value to the physical product experience. Most often, hardware and software combine in a connected experience to address an internal problem (like an anxiety, uncertainty, or management/attention issue) in a way that wasn't possible without the smarts of digital.
4. If you’re part of value proposition design or business modeling, help your marketers find savings, then differentiation, then defense, then revenue from this connected product offering, in that order. When designing a connected offering value proposition, everybody jumps straight to hypothetical revenue streams. For most, that's not how making money with IoT actually works. Costs saved have a greater impact on financial performance than revenue from volume. Yes, price is king, but your market may not be ready or willing to pay new money for an unproven digital enhancement.
5. Avoid overcapture. By far the most common failure mode in connected product development goes like this: 1. Put sensors on our thing 2. Collect data 3... 4. Profit! 80% of what you learn from unplanned data analysis could be easily understood through observation, and the other 20% is correlation that doesn't reveal "why". Additionally, although data storage may be cheap, data transmission costs real money.

Your goal is to unearth and pressure test assumptions that risk turning the entire product development effort into waste, but do so with reason and evidence without becoming a whiny doomsayer. Your team should hear your customer’s “no”s, not your own.

6. Stress the basics

Every product strategy needs rules to keep its implementation out of the ditch:

1. Articulate user value created. Define in writing (or design) how each interaction creates value for the end user. If something doesn’t, think hard about its necessity. If it adds value for you and not your users, ensure it never interferes with their experience.
2. Justify each feature. Whether it’s an interface feature, device, cloud, edge, or whatever, if it exists, it needs a stated justification.
3. Explore the value of omitting a feature. It feels like heresy, but sacrificing functionality at the altar of convenience can improve the aggregate experience.
4. Never forget the deal. Your customer or user is allowing you to collect data either about them or their machine. The presumption underlying a connected product is that you, the product maker, need this data to unburden me, the customer. Don’t make me work.

Well-intentioned, under-informed pivots always balloon costs, so check your product strategy regularly for digressions. Fundamentals win fights!

Implement to reality

Connected user experience designers make the chaotic realities of connected device usage into positive experiences by taming their complexity. When user information, behavioral findings, and intentional design combine with preferential testing and data from a CI team, results will sometimes literally speak for themselves.

7. Plot the unhappy path

Too often, UX designers believe the inverse of the designed experience is no experience. The true inverse of the designed experience is the unmanaged experience.

With connected products, failures happen regularly within the intended, designed experience. Herein lies the key challenge with connected products: how should it work when it doesn’t work?

1. Plan to fail…elegantly! Each action should have a defined timeout, and if an action exceeds that threshold, return the user to where they initiated their action, and note what they should do next. “X failed, check device power and try again”. Repeated failures warrant different suggestions, and well-coded errors help a ton here.
2. Identify and design the resolutions users should undertake to overcome a given error. Be judicious about the effort level here, sometimes error code verbosity is plenty.
3. Identify the onramps back onto the happy path. Resolution alone might not be good enough—where should a user end up? How will you get them there?
4. Prioritize self-service with clear guidance. Every deviation from your experience’s ideal state and happy path requires solid guidance back to the ideal workflow.
5. Enable customer service with the aforementioned distinct error codes and strong verbosity. Self-service covers a lot, but never everything. Meaningful errors help CS reps diagnose and resolve customer issues faster than a troubleshooting protocol, turning negative incidents into positive brand interactions.
6. Performance anxiety crushes satisfaction. Connected product interaction feels abstract, and “is it gonna work?” lives in everyone’s head. Inconsistent performance amplifies anxiety, so if you condition a “normal” web-like response early in the experience, then deviate from it, your connected experience will leave users uneasy.
7. Set expectations. “This step could take a while…” sure beats an animated ouroboros ring, but still isn’t as good as “this should take 2–3 minutes tops”. The user needs to know what’s normal.
8. Foster work independence. For any potentially slow operation, ensure your experience can complete its work without needing to stay foregrounded. Losing attention is not equal to failure in IoT. If the user returns after said task is complete, land them on the next screen. Have a plan if they return to a failure as well.

Ultimately, design and engineering collaborate to create cures and copes for a connected product’s inevitable issues. No amount of engineering heroism will cleanse an uncontrollable system of all problems, so it works best to acknowledge the opposing, unhappy experience and design for it, too.

8. Multiple interfaces

This one’s the gimme. Nearly all connected product and service solutions feature multiple ways to interact with the same data:

1. Web applications
2. Mobile applications
3. App Clips/Instant Apps
4. Connected product UIs and status indicators
5. Voice interfaces
6. Wearables
7. Single-function devices
8. Automotive interfaces
9. APIs
10. External integrations, applications, and management systems
11. Haptics, light, and other feedback mechanisms

Don’t confuse the potential number of interfaces with the correct selection of interfaces for your use case (more isn’t better). The number and type of interfaces is connected experience design’s first factor of multiplicity.

9. Discontinuous workflows

Most web and mobile application designs prescribe a linear workflow, often starting from a login screen. Connected experiences begin from multiple entry points and have multiple exits, our second factor of multiplicity.

1. Identify entry points. Users may enter your experience on each interface from multiple places: a scan, a login, a location, a permission level, a corresponding device state, and more. Find them! Don’t forget unintended users, either.
2. Determine expectations per entry point. After scanning an electric motor’s QR code sticker, a user likely expects something quite different than if they’d logged into the same app to view the day’s jobs.
3. Identify the key result per entry point. After scanning that QR code, should users see a status page? A maintenance record?
4. Call out leave off and pick up points. Discontinuity lives in time, too.
5. Minimize dependencies. Do I really need to sign in, confirm x, or complete y after scanning that QR code, or can you just deep link me to what I want?

Your interaction architecture won’t resemble a linear storyboard or even a branching hierarchy. It’s now a constellation chart of discrete but related engagement points.

10. Multiple experience states

The big bad revealed! If you’re going to fixate on a villain, focus on system and experience state and state transitions.

1. Create your technical state matrix. What modes can your device/cloud/interface system operate in? Unpack the user contexts, interfaces, device, and connectivity levels. There will be more system states than anyone’s comfortable with.
2. From there, define a design state matrix. This might be simple (a connected state vs. disconnected state), or there might be 4–5 depending on context or connectivity type. Detected technical states will trigger the interface design state experienced by the user.
3. Define your error state matrix and error handling __approach. Errors are no longer solely a programming task—your design must help users through the experience’s inevitable problems.
4. Define the state checking mechanism and its expected capabilities and outputs alongside your engineers. Focus on connectivity, performance, and design state.
5. Identify state changes and make corresponding plans for fail ups (disconnected→connected) and fail downs (internet connected→locally connected).

State is connected experience design’s third layer of multiplicity. Poor state handling creates the majority of negative experiences and drives significant hidden costs, particularly with consumer devices.

11. Keep your product out of its own way

Sometimes the happiest path is the clearest one. For those with an e-commerce or engagement-focused background, resisting the temptation to create extra interactions may prove difficult.

1. Device harmony creates trust. An interface and a device must reflect each other's state. This indicates that the connection works.
2. Brand __harmony creates further trust. An interface and a device need similar or complementary aesthetics.Think first use, tenth use, 100th use. Scale user help, guidance, and content to the user's present conditioning level. If help content stays static, you'll always underdo and overdo it.
3. Embrace set and forget. After initial use, device control and monitoring are utility functions, not gamifiable, emotion-activating functions.
4. Sign-ins are precious. Minimize the number of logins, password inputs, authentications, and verifications a user must endure. Must they even be signed in to do X?
5. Notifications are precious. Mixing promotional fluff with critical information frustrates users. Make every interaction valuable.
6. Design around wait time. If a user must wait on the system, background the task and engage them in something else.
7. Collect your garbage. Nobody intends for their device control app to have 65 screens, but after enough sprints, apps sometimes end up that way. Take out the trash periodically to remove tech debt, design debt, code weight, and obstacles to users’ immediacy.

There are opportunities to drive meaningful engagement inside a connected product interface, but they’re most available where device interaction is secondary to something else like content, recordkeeping, upkeep/consumable replacement, or similar.

Iterate intelligently

When you’re iterating on IoT software after launch, you can never tell which seemingly-minor sprint, release, or design decision would be the one to break the experience. Usually, things are fairly stable throughout the post-launch growth phase when you’re slapping on new features, but when you’ve got a million devices in the field and the slightest error wrecks things for thousands of people, quality iteration takes on new importance.

12. QA your UX

Experiences can and should be quality tested before implementation into digital, mechanical, electrical, or manufacturing reality. Once software engineers start laying down code, the program’s development cost multiplier increases expenses to another level, so creating a quality checkpoint prior to production coding makes sense.

Trouble is, to quality check a design, you must check it against something, and creating those somethings takes work:

1. Establish interface, design, and brand principles __if not already done. Your interface and device need common principles to maintain experiential integrity, and testers need to understand design’s intent to find deviance.
2. Research and establish feature principles. Also known as “what’s the point of this feature?” Principles focus on the core intent, the problem that feature solves or capability it enables. For example, a focus function would instruct a lawnmowing robot to concentrate on overgrown spots the user designates as unkempt, so the principle of activating this is to save time otherwise spent patrolling a geofenced area. Enter each feature sprint with lessons learned in mind.
3. Write principles into requirements. Designs aren’t requirements! Requirements are where principles get unpacked and applied in design and technology.
4. UX designers produce design options, not finals. Interpretation is part of the art of design, allow space for it.
5. Test options against principles. Now, we hold ourselves accountable. Do our design options really meet our principles?
6. Test best options against __users. Often the final verdict before development investment.
7. Maintain fleet and SKU integrity. Some changes impact subsets of users and devices—handle this gracefully for both the affected and unaffected.

While we understand the sprint cycle and the need for speed, the consequences of haste are harder to undo across a connected ecosystem. Nothing’s more permanent than a temporary solution.

13. Create a usage intelligence framework

Product teams typically tack analytics on to the architecture without further thought:

☑ Add Firebase

Getting analytics right earlier with a dash of experiment design can save a ton of agony later.

1. Plan for iteration. Connected experience design doesn't end once development gets going. The product always needs enhancements, and you can enable that now. Start by identifying the top three usage questions you'd like answers to.
2. Make data valuable. Raw values like user counts or time on page don't create meaning—the relationship between relevant data does. You'll know that an action, clicking x, should produce a result from the app or the device, giving you an action/result pair that developers can capture with your chosen analytics system.
3. Instrument the happy path. Identify critical happy path events, map them, then sample key event action/result pairs and subsequent ratio data. If you see the action/result rate fluctuate after, say, a new firmware rollout, you’ve got yourself a leading indicator before the 1-star reviews arrive.
4. Be judicious. Your application's happy path and its unhappy path(s) create events that can be tracked and analyzed. What's valuable? Most things aren’t. Our rule of thumb: track approximately 5 key success ratios.

Remember, the last thing you want is to learn of a usability issue from your call center team.

At Next Mile we can help audit, augment, or deliver any connected product user experience. Contact us to bring powerful IoT UX expertise to bear on your initiative.