Today I had a conversation with someone who cannot collect user feedback on their application. Through a combination of their industry standards, a post-acquisition NDA, and other factors they rely on design research and best practices as exhibited by other industries and third party’s.
Often, as a team builds digital products, they rely on established patterns like Google’s Material Design or ‘best-in-class’ competitors to establish a solid backbone built on best practices. While this approach can be a great shortcut, it can also lead teams to unintentionally give up ownership of their user experience. They assume the creators of these design systems have already done the necessary research to ensure optimal user experience and accessibility. However, this assumption is not always accurate; especially when a product is built for a niche market.
The Dangers of Relying Solely on Design Systems
Contextual misalignment: A large-scale design system is built to be broadly applicable, but it may not be optimized for a specific industry’s unique context, workflows, or user behaviors.
Abdicating responsibility: Using an off-the-shelf design system means a team is essentially handing over the responsibility for user testing and validation to a third party. This can be a risk, as a design elements that are developed for one product or context may not translate to yours.
Missing a deeper understanding: While design systems are helpful for getting a product to market quickly, they can prevent teams from digging into the complexities of their own user journey.
Lack of direct customer feedback: By relying on boilerplate solutions, teams might not feel the need to seek direct feedback from their own users. Over time, this can lead to a product that doesn’t meet the specific needs of its audience.
Taking ownership of user experience requires more than just implementing a rigorously tested design system. It means taking the time to understand the unique needs of your users and how they interact with your product. This is especially important for teams who have moved beyond the initial startup phase.
You may need a foolproof UX given the sensitive nature of your industry.
You may have so many simple, optimized features that your ecosystem requires bespoke solutions to compensate for the complexity.
The shortcut of relying on established patterns is tempting, but a truly successful product is born from a deep understanding of its users and a commitment to continuous improvement.
Great post, @EricZ. I haven’t thought about design systems in this way, but also, I think one of the big benefits is the fact that it removes you from having to think about it some of the time.
The catch is that you should always think about it. But the question is “how much”?
Totally! Third Party design systems carry a jump-start in value initially. But ‘abdicating’ responsibility is where the danger really lies, as no general design system can clearly communicate and carry the value promise of your specific product or service.
They’re hamstrung by legal requirements and NDAs. What’s stopping you?!?
Empathizing with designers caught in this difficult position highlights the freedom and potential to build your own advocacy program to learn from users.
Totally agree
Design systems are a great starting point, but they don’t replace actually understanding your users. What works for a big, general system might not work for your specific audience. I’ve seen teams rely on “best practices” and end up with experiences that don’t quite fit. The real magic happens when you use the system and talk to your users to shape it for your context.
@Helge I’m curious how this situation aligns with your experience in the healthcare industry?
“Today I had a conversation with someone who cannot collect user feedback on their application. Due to a combination of strict industry standards and a post-acquisition NDA, they rely on best practices and the rigor of third-party frameworks (Material Design, etc).”
There is a difference between countries (the US is very strict), and in most countries the pharmaceutical companies are not allowed to have direct interactions with patients (even user tests for websites or apps).
They usually get around this by hiring vendors to do the research / feedback for them.
These vendors know the position they are in making them very expensive and also conservative, milking a business model where they make the least amount of effort for the most conservative possible research (and the biggest possible margins).
In markets where there is no money to do research they usually don’t do any testing at all. Relying on the skills of their designers and agencies.
I think, in Healthcare especially, there is an assumption that rigorous research is happening all the way down, from drug trials to product performance. The drug trials get public reporting and attention, and the assumptions can trickle down.
I’m curious, in your experience, which industry actually leverages research and data best?
I’m not sure I can say which industry leverages research best. I would assume there are brilliant people everywhere (somewhere in the system), that outperform on research even in the dreariest of industries.
Personally I’m always in favor of people asking questions from the perspective of the subject. Very often we ask the subject to have an opinion on our own perspective. This means double trouble: a. because you are not trying to understand the subject, but have them rate you and b. because if you ask someone for their opinion they start lying to you.
Sensemaker suggests that you should ask people to retell experiences (not share opinions), and then since every analyst has a bias you also ask the subject to analyze their own response. This is a interesting approach
There is a lot we could get into here but perhaps as a starting point there is an important distinction to be made between using a design system in a regulated healthcare use case or an unregulated one.
The TLDR is pretty much using an off the shelf design system for healthcare products can be a starting point but unless it’s been make specifically for healthcare products and validated it’s going to need robust research and testing before it can used.
If it’s not covered by medical regulation then it’s pretty much the same as any other industry and some companies see research and testing as optional and may reach for an off the shelf design system thinking they will same time and money.
From my experience that is possible if they instead understand the problem and use cases/work flows the design system of being used to solve and know which patterns to employ.
The long form on the regulated health side starts with identifying when it’s going to be a regulated product or not. If it’s will be used in relation to the diagnosis, treatment of patients or management of health data some form of regulation likely applies that means it the product mist be based on evidenced user need, validated to mitigate risk and for usability under Software as a Medical Device(SaMD) or as a medical device under FDA(US), MDR(EU) or MHRA(UK) standards - usually an ISO or equivalent.
Effectively you have to have robust research to prove the need, evaluate design solutions and the end product is both ‘clinically safe’ and effective. You can’t make a marketing or clinical claim without evidence that has been reviewed by a regulatory body.
Human Factors(HF) as a profession exists as distinct from UX design pretty much because they have a higher threshold for evidencing risk, usability and safety needed to mirror the rigour of clinical studies and trials to prove efficacy.
@tim_banks Okay, wow, there’s a lot of clarity in the distinctions you’re making.
It sounds like it will be valuable to clarify when speaking in the health space whether we’re speaking about software on a medical device, software for commercial devices in a medical setting, etc…
The checkin software on a commercial tablet used in the waiting room would be an example of the latter. These generally are utilitarian, but have quite a few usability issues (CTA prominence, alignment issues, touch-point size etc…).
It makes sense that the software on a medical device would require rigorous testing before use. Thinking of the software to operate a heart monitor, CT scan, etc…
