I’ve been approached recently by students on the precipice of earning an advanced human factors degree as well as by UX professionals contemplating a domain change, each with burning questions about facilitating a smooth transition to industry (in my case, medical devices). I sense a bit of trepidation in the asking, a primordial dread of receiving an old-school fire and brimstone sermon meant to reduce them to a smoldering pile of ash. Actually, it’s a pretty damned good question with an equally damned good answer.
As you probably suspected, there actually is a subset of knowledge that tends to serve UX professionals well in any regulated industry. You didn’t acquire it in grad school because the faculty was (rightly) preoccupied with teaching requisite human factors stuff instead. I’m talking about regulatory standards. Yes, those things. Like apparitions from a campfire ghost story, you’ve probably heard shadowy whisperings about the ISO spirit from others but were never able to catch more than a fleeting glimpse of it yourself. Formal, expert-consensus, government-endorsed documents detailing “requirements, specifications, guidelines or characteristics that can be used consistently to ensure that materials, products, processes and services are fit for their purpose,” according to the International Organization for Standardization (a.k.a. ISO). Industry is the house that ISO officially haunts. Watch your step when entering.
Now, if you’re thinking you’ll just keep your head down and focus on UX stuff while the company’s leadership worries about sorting out regulatory compliance (hell, there’s probably even an entire department dedicated to regulatory issues), you’re in for your first fright. It comes without warning…disembodied voices emanating from dark corners of your corporate office, chanting:
(If you’re so inclined…read the following in an eerie, ethereal voice)
1. “UX isn’t required”
2. “UX is redundant, other processes already do this”
3. “We don’t have time to do UX”
4. “UX will result in extra work for everyone else, sinking product deadlines”
5. “We can’t make any product changes at this point anyway”
Steel your nerves, all is not lost. You personally need to know what’s in the regulatory standards because they’re the ultimate authority on what’s required (translation: will be done) and what’s merely recommended (translation: will not be done) when it comes to usability engineering in industry. As a UX professional, you’re hardwired to tackle any and all pressing usability and user experience questions leveraging an impressive array of validated methodologies to help craft successful, safe and enjoyable user-device interactions. To many in industry, this makes you look like a guaranteed drain on extremely limited resources and a potential source of friction throughout the existing product development process. To battle this misconception, you need to fine-tune your own UX knowledge, skills and messaging to align with your industry-specific mandates. Here’s why.
Medical device manufacturing (like any regulated industry) demands that organizations maintain a delicate balance between complex, measured quality management systems and the lightning-fast pacing of innovating a crowded, competitive market. International and domestic standards drive everything from initial product design inputs to post-market release performance surveillance. This includes the international standard for usability engineering in medical devices (e.g., ANSI/AAMI/IEC 62366–1:2015; 62366–2:2016), with which numerous domestic variants from around the world are harmonized (including FDA and EU requirements).
There are additional standards for risk management, quality management, and so on that feed directly into and out of usability engineering, the nuances of which must also be understood to avoid regulatory noncompliance and/or duplicative effort (equally disastrous in industry). Remember, required (per regulatory standards) means “will be done” whereas recommended means “will very likely not be done.” Note: it isn’t a requirement that devices be user-friendly or intuitive; only that they’re relatively safe to use. This doesn’t mean that you simply turn a blind eye to the former, but evaluating and issuing recommendations relating to non-required UX elements involves an elevated degree of creativity and finesse (beyond the scope of this article). Once you understand what’s actually required of UX, you’re ready for what comes next.
From an organization’s standpoint, every aspect of development from ideation to product retirement is carefully prescribed in a horde of internal documents called standard operating procedures (SOPs), which themselves exist in a perpetual state of alignment and realignment with other SOPs, current regulatory standards, and recognized best practices. Whereas regulatory standards dictate that which must be adhered to by organizations at the general or strategic level, SOPs are the organization’s blueprints for detailing precisely how processes are executed tactically. Numerous departments (e.g., Marketing, Software, Hardware, R&D, Risk Management, etc.) assume key leadership roles in crafting and enforcing SOPs, ensuring both organizational and regulatory alignment across the board.
During regulatory audits, SOPs and supporting documents are interrogated vigorously and evidence of compliance with current standards must be provided to auditors on demand. Non-conformances (actual or perceived) will result in anything from corrective action orders (best case, often a first offense) to the halting of sales or production for more severe (or unaddressed prior) non-conformances. Once you’re officially on the job, you’ll need to review your company’s product development SOPs to learn how things actually work at your company (i.e., open the closets, find the skeletons). There are a lot of moving parts here, which can seem kind of scary. Still, we’re not quite out of the woods yet…the biggest fright is yet to come.
With federal regulations, international and domestic standards and organizational SOPs all seemingly in agreement that usability engineering must be demonstrably well-integrated, you might expect things to be rather unexciting from this point forward. Unfortunately, all is not as it appears. Most organizations struggle mightily to get UX integration right, and many don’t even come close. The reason lies partially in the notion of “harmonized yet distinct” processes, whereby some mistakenly believe -and often vehemently proclaim- that a company’s usability engineering obligations are being met as a byproduct of conformance with other interrelated (and often more familiar) process standards and efforts. Here are some examples:
Example 1: Risk Management might already include potential “user risks” and mitigations, based on simple anticipated use deviations, in its product FMEA documentation per ANSI/AAMI/IEC 14971:2007 (risk management standard); but it isn’t equipped to consider the impact of user characteristics (e.g., perceptual, cognitive, and/or physical capabilities and limitations; education and experience, etc.), use environments (e.g., extreme noise, lighting, temperatures), or workflow complexity (motivation to find workarounds, efficiencies, etc.) in contributing to a great many additional use risks.
Example 2: Marketing routinely surveys customers for feedback on product functionality and features; however, these inputs are generally reflective of the customer (i.e., people who buy the products — executives, managers, etc.) rather than the actual end user.
Example 3: Various departments conduct product V&V activities; but the focus is on verifying and validating system technical functionality rather than on safe and effective user interactions.
The list goes on. Because usability engineering often evokes other interrelated engineering processes (which is perfectly natural, provided its evolutionary history), those who don’t really understand UX or its absolute user-centric focus tend to misidentify it when viewing it in the presence of its doppelgangers. It’s a fanciful argument to make, whatever the reason, that UX requirements are more or less met as a byproduct of other processes. Auditors certainly don’t buy it. This is why it’s so important for UX professionals to expertly control the UX conversation; not only do we have a professional obligation to understand and advocate our own regulatory standards, but also to ensure that UX isn’t marginalized to the detriment of our end users.
In conclusion, a basic survival guide (if such a thing truly exists) for UX professionals working in regulated industry might look something like this:
1. Master the usability engineering standard(s) specific to your industry (ANSI/AAMI/IEC 62366–1:2015; 62366–2:2016 is the starting point for the medical devices domain)
2. Note interrelated (one-off) standards referenced throughout the usability engineering standard, and master those as well (but beware of scope creep — don’t worry about chasing down every additional standard referenced by the one-off standards)
3. As soon as possible after joining a company, dig into their product development SOPs to better understand how things actually work there
4. Scrutinize existing processes, looking for daylight between what’s required and what’s actually being done; answer the following questions and be prepared to articulate your answers to a broader audience:
a. What, specifically, is required of UX (per regulatory standards)?
b. Are we currently meeting each of these requirements, or do we only think/say that we’re meeting them?
c. If we aren’t actually meeting them, where are the gaps and how/when do we close them? How will this impact others’ processes and/or timelines?
5. As UX becomes more fully integrated as a result of your efforts, anticipate periods of extreme high workload (at least at first) as new process components are “field tested;” be prepared to deliver consistent, timely results when demand is at its highest or risk losing all your hard-won momentum.
UX in regulated industries: how to survive the night was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.