UX Design for Compliance-Heavy Applications
Questions from designers are regularly submitted to the UXmatters editors, who ask various people including me if we have a useful response. These are combined into multiple-viewpoint answers.
This month in Ask UXmatters, there was a question on design for compliance-heavy industries. There’s lots of good stuff in the responses, but I got quoted at length, in one big block, so submit for you my answer here which is basically:
Everything is regulated. If you don’t know the regulations, better learn them right away.
Regulation is generally for good, so we all have a level playing field, and consumers are protected and have an equal say in how businesses perform and use their information.
Design is not art, and the difference is constraints. Technical, and business ones we are used to, so adding regulatory just isn’t that hard once you accept that constraint is the order of the day.
Here’s the rest of my answer in full:
“I have spent essentially my entire career designing products that must meet regulations. In addition to lots of work on telecoms, banking, and healthcare, almost every industry has some regulatory oversight. You really must understand that.
“Most regulation is for good—either the good of individual consumers or society as a whole. It protects their privacy, security, and often their actual physical safety. Regulation is just an extension of the will of the people in an organized society, so is a codified extension of ethical design. Off the top of my head, I can’t think of a time when I sighed and reluctantly worked toward satisfying or getting around some regulation. But I’ve often had to bring up the details from a regulatory body with teams.
“I’m not sure how to answer this question directly because I’ve never felt even a tiny bit more constrained regarding innovation in highly regulated versus less-regulated industries. Regulations are just another input or constraint—and technical systems are full of constraints anyway. We design to constraints all the time—cost, complexity, time, feasibility, secrecy, and a lot more. When teams write up the requirements for regulated products, around 95% of these requirements are from Marketing or Product Development, not on the regulatory or compliance side. We design innovative solutions that embrace or transcend such constraints every day.
“Regulatory requirements are a great example of how understanding broadly and designing early can lead to great work, while leaving design to the end of the development process results in disaster.
“Long ago, there was something called the pretexting scandal (one big part). One result was the FCC’s adding new requirements for mobile telecoms to secure user data better. Except that they really had no detailed requirements, just the high-level outcome of improving security. However, by working to realize that outcome, my UX Design team was able to create a design solution that achieved that goal. We then worked with the compliance lawyers at the company to negotiate with the FCC. Thus, we more or less created much of the final regulation. Plus, we were the only telecom to launch a new security system on the deadline date.
“Now, in most cases, you won’t get to do this and must simply meet existing regulations. Your organization’s lawyers will demand that you add something to the Web site or app, but they often fail to understand what a specific regulation means. Don’t just trust them. Do your own research as well. For example, there’s no regulation that says disclaimers have to be in all caps. Read the regulations, talk to your legal and compliance teams—they’re probably different groups—and learn what is actually necessary. Design to actual requirements, and you will end up creating better products, achieve better compliance in the end, and have happier users.”