A team insists they need to use an inaccessible design pattern and justify it by saying, “Well, if Apple and Google do it, then it must be accessible.”
When imitation is helpful
Emulating a design isn’t necessarily a bad thing. When it solves a problem your enterprise actually has, this can be a way to save time and money without performing the original research.
Additionally, trying out a pattern as part of a multivariate testing experiment can quickly surface new successful approaches.
When imitation goes awry
Assuming a top performing company is also executing accessible experiences is very risky. It’s not difficult to find sub-par or inaccessible experiences on any FAANG company (Facebook, Apple, Amazon, Netflix, and Google).
Emulation will never lead to innovation, only to a leveling up after others.
Going all in on emulating a pattern on the speculation it’s correct can lead to sub par performance and lead to overly complex UI patterns for the customer.
Why teams do this
This kind of behavior often seeks to uncritically emulate a high performer or competitor, trying to mimic their moves.
Fear and safety
It’s said, “Nobody gets fired for buying Microsoft” because it’s considered a safe industrial standard. In today’s UX and product space, nobody gets fired for imitating popular FAANG companies.
Emulating a well known company feels comfortable because they believe it can’t be a complete mistake. And should it turn out to be sub-optimal, they can simply say they were following a top company.
It looks cool
Often high performing companies employ high caliber design teams delivering great work. Their products have a natural cohesion that’s attractive to mimic.
Taking a shortcut
Copying can save time and money, until it doesn’t.
Let’s be honest: Apple, Google, Facebook or any other high performing tech company didn’t make their billions from accessible UI development.
They did so by building systems suited to their business model. Without understanding those underlying business strategies, simply copying their work risks under-performing on your own objectives.
Find out what’s important to them
Assuming the team is open to discussion, walking through the team’s goals and priorities can help re-align with accessible practices.
- Customer experience
- Safety from criticism
- Reducing costs
- Looking like everyone else
- Looking different than everyone else
Other discussion questions
- How will you measure the success of this pattern compared to more accessible and cheaper to build designs?
- Have you tested this pattern?
- Have you tested this pattern manually or with any automated tools?
- Have you tested this pattern among people with disabilities?
- If we test this pattern and it’s not accessible, are you open to other patterns?
- If we build this elaborate pattern, are we budgeting for consistently maintaining any complexities that make it accessible?
If this doesn’t work
As always, don’t be the police.
If a team continues to carelessly imitate patterns that aren’t accessible, follow your team’s escalation procedures and leverage leadership to define priorities.