We’ve done an inordinate amount of UX consulting in IoT at Next Mile, and if there’s one thing we’ve noticed about UX teams contributing to connected product development efforts, it’s that they end up isolated and undersupported, even when they’re well-funded. In this article, we describe how traditional product development support disciplines should integrate and enable the digital UX design effort.

UX design may be common in software development, but that’s not the case in connected product development. Here, UX design coexists in the same master schedule alongside industrial design, firmware development, mechanical engineering, electrical engineering, product management, and many other teams. And while software developers are used to UXer’s particular talents, no one else in this process fully grasps what UX is, does, what to expect from it, or how they can help it.

When IoT met UX

In IoT and connected product development, user experience design (UX) often takes a backseat to hardware and infrastructure…that is until customers can’t use the thing.

Sadly, UX usually gets introduced to connected product development in a moment of panic: there’s a problem, and the ins and outs of the UX design process-as-a-solution sound borderline medicinal. “Yes, just the thing we need to square things up and unblock a certain success!” Hired-gun designers then sprinkle some UX on it, get the digital experience up to some standard, and quell the crisis. “We’ll never be without UX again,” leaders say assuredly. They add UX designers to the product development team and it’s job well done.

UX must not become isolated

Trouble is, adding and integrating aren’t the same thing. Connected product development processes need to be refactored to account for two distinct UX design sequences (a topic for a separate article) but never are.

In the most common best case, newly-introduced UX gets some time to “design the app” and/or contribute work product (with a dash of professional opinion) as a passenger in an ongoing Agile process, and UX practitioners make the best of it, designing without sufficient support or field intelligence.

Over time, intense product development schedules stack on pressure, and the alienness of UX to hardware and firmware teams builds new barriers to circumvent. Any design delays invite scrutiny, even those traceable back to uncertain product or technical ownership.

Then, with delivery problems overcome, UX finds itself an island in the greater process. Once testing begins, all end user problems accumulate here like flotsam washing ashore (even technical problems). Poor reviews, customer service calls, debate about features, and internal politicking increase consternation with the UX design process, expense, and outcomes.

“Why did we spend $X on UX only to still have these problems?”

At that point, connected product programs find themselves one crisis away from a conflagration and a resultant total UX reset.

UX-plode

No customer or end user will ever care which team’s or individual’s fault things were. They only care that using the gizmo they just bought sucks, and that’s your company’s fault.

“What's going to be different this time?”

Your connected product interface experience’s success can no longer hinge solely on your design team’s or partner's competence, clairvoyance, and luck. You can both prevent isolation and help ensure UX’s success by adjusting the objectives and outcomes of three existing product development support disciplines: requirements, QA, and CI (if you have it).

1. Requirements for UX

Moment of impact: pre-design

Traditionally, UX designers work with requirements written for software developers. That won't do going forward.

What requirements really do in IoT

We’ve seen it a million times—everyone wants their BA’s documentation to centralize understanding for the entire project lifecycle. A business analyst’s PRDs, MRDs, detailed specifications, PowerPoints, etc. will do that for a time, but as the product takes form, this pre-birth documentation matters less.

Requirements don’t establish hardline boundaries or become a permanent touchstone so much as they pass their genes on down to the designs, schematics, code, and tests that make your product what it is. If you want your product to inherit good traits, your early documentation demands careful attention.

Proper UX requirements

In a complex IoT system like a connected product, requirements must also address design and QA in addition to engineering and software development. We recommend that your requirements incorporate and address your interface:

• Standards

  • Performance criteria (responsiveness)
  • Acceptance and rejection criteria
  • Engineering and design interplay

• States

  • Device/app connectivity level
  • Connectivity state changes—fail up/fail down
  • Error handling and prompting

• Contexts

  • Defined user scenario and expected user value—create empathy
  • Prerequisite conditions
  • Clearly articulated user value defined as a testable objective

These, along with standard interface definitions, provide guardrails for effective design. Like all requirements, elements of these documents will need upkeep, and they’ll help manage engineering change over the long haul.

2. QA for UX

Moment of impact: pre- and post-design sprint

“QA” by our definition here is a tad loose: we mean “quality assurance” as a practice, not just “the QA team”.

Pre-design QA for UX

Judicious, targeted effort from pedigreed internal and external experts behaves like “pre-QA” because it sets standards for a given experience. Examples include:

• A north star focused on target behaviors
• Interface design principles
• UX for IoT company or brand principles
• UX for IoT project principles
• UX for IoT industry-specific consumer guideposts
• Research-based, feature-specific design principles
• Past quality standards that worked

Post-design QA for UX

The keepers of quality at your organization help UX the most by being the fairest judges of what will and will not work in implementation. Developers will know whether something’s feasible, but QA can detect problems before they manifest. Use their power inside the design process and against UX prototypes:

• Feature sprint contributions
• Design critique/revision sessions
• UX prototype audits
• Prototype testing if applicable
• Test plan simulations/test plan testing

In the rush to get things done, this quality cycle will keep UX and all of product development true to your goals and honest with your users.

3. CI for UX

Moment of impact: post-design

While research in UX revolves around customer behavior, consumer insights (CI) teams primarily deal in customer preference (color, shape, price, etc.) assessed through surveys, interviews, focus groups and more. We recommend you keep the line between UX and CI testing intact.

CI should test design claims

To the extent prototypes (and even builds) get released, CI should validate designs with prospective consumers. Testing can take several forms, but with requirements in one hand and a prototype in the other, CI can test claims in addition to general satisfaction. Design claim-focused questions may include:

• “Will people use feature X?”
• "Does feature X really deliver value Y?"
• “Does feature X differentiate our product as perceived by the customer?”
• “Do customers prefer the new design to the old one?”

UX research and design can and does alter user behavior, but CI can validate whether or not that behavior change matters.

Going further with CI

To help CI help UX even more, you could:

• Run the same usability and satisfaction tests on competing systems and apply learnings.
• If analytics is owned by CI, draft the instrumentation plan to capture UX leading indicators (event success ratios, for example).
• Help QA with defining UX metrics as pass/fail criteria for each feature in the test plan.
• Develop end-to-end CI performance criteria that CI can use to measure the combined impact of UX and software engineering.

At Next Mile we’ve initiated, shaped, led, and rescued many connected product and IoT UX programs. Contact us to bring deep IoT UX expertise to bear on your connected product effort.