Designers can sometimes be made to feel as if they’re obsessing over trivialities. Where's the line between doing things right and being a blocker?
For the purpose of this blog post I’m going to create a fictional case study.
Here’s the situation
The client develops smartphone apps to support the delivery of virtual ward services in private sector healthcare.
They follow NHS design standards by default, to support integration with NHS products, and reassure users.
A team of designers is working with developers on a new feature in the app.
This feature will allow patients on virtual wards to send secure messages with photographs to named clinicians and track the progress of their queries.
App screens created by the design team are implemented by the developers, including an offshore team.
The designers then review the implementation of the designs to make sure they are correct and consistent.
On the most recent round of quality assurance, the content designer on the team noticed several deviations from the design:
- inconsistent capitalisation of the phrase ‘virtual ward’
- dates rendered in the format ‘09/11/2024’ rather than as ‘9 November 2024’
- a rewritten heading
- new intro text added to one screen
You might think this would be relatively straightforward, right? The design team flags these issues, the developers make the changes, job done.
But the content is not managed through a content management system (CMS) – it’s embedded in code.
There are no developers available to make the changes in the next project sprint.
And when the changes are made, that will retrigger the quality assurance process, which must be completed before anything is allowed to go live.
This will result in the release of the new feature being delayed by up to a month.
So, quite understandably, the product owner asks: “Can’t we just let this go? It’s only small details, and we can fix them in the next release.”
Why ‘letting it go’ might be a problem
There are a whole bunch of reasons why letting these small deviations go might be a problem.
Safety
First, in healthcare in particular, there’s the question of patient safety. You might look at the above and think, well, none of these seem likely to cause any harm.
But the question of date formatting, for one, would give me pause.
The way dates are written varies from country to country. What if someone misread 09/11/2024, the date of a home visit by a nurse, as 11 September rather than 9 November and so missed an important appointment?
There’s a reason the NHS Service Manual specifies the ‘9 November 2024’ format – because testing shows it’s the most widely understood, and most easily parsed.
Changes to header text could also be risky, if the original content was carefully designed for maximum legibility and to reduce ambiguity.
Properly designed content might not always seem elegant, and it might go against ‘common sense’, but there’s usually a good reason for those choices.
Reputation and user confidence
The UK National Cyber Security Centre (NCSC) advises people that one way to spot scams and phishing is to look out for “bad spelling or grammar” or “imagery or design that feels ‘off’”.
Its guidance also adds that, as they become more sophisticated, scammers are increasingly avoiding these easy tells.
What can we conclude from this? That in a very concrete sense, consistency and correctness matter.
They signal trustworthiness and quality to service users – even if only on a subconscious level.
Accessibility and inclusion
A lot of the choices designers make are intended to make products more accessible for people with disabilities, or more inclusive of people from specific social groups.
In most cases, those choices will have been driven by insight from user research, and validated through usability testing.
When we override those design choices, whether accidentally or through choice, we increase the likelihood of people being excluded from the service.
And in the case of healthcare, that could mean that they don’t receive the care they need, which loops us back to safety, above.
Blocking can be a problem, too
If all that sounds as if I’m saying “Let the designers have their way” well, not quite.
I spoke to my colleague Paul Bailey about this. He’s a hugely experienced senior designer and digital consultant with decades of experience walking the tightrope between idealism and pragmatism. He says:
“As designers we're passionate about the details, but we can get caught-up in them. It’s vital to communicate the value of attending to the details in a way your stakeholders can easily understand and care about. A question I often ask myself is, ‘What would be the impact or risk of letting this go?’’ Knowing when to be meticulous and when to push forward is a design superpower.”
To some extent, it’s about picking your battles.
If, as a designer, you only ever say “No” and always seem to be the cause of delays, you’ll find stakeholder relationships difficult to maintain.
On the flipside, if you can find opportunities to be pragmatic, you’ll earn credit with those stakeholders so that when something really is a deal-breaker, you’re more likely to be listened to.
It’s also worth considering the potential benefits of getting a new feature live even if in an imperfect state.
When it’s live, you can start to gather data and feedback from real users, informing future iterations.
And if it’s a truly useful feature, it might start to deliver real benefits to real users despite its flaws.
Whose fault is it anyway?
As well as tackling errors in the moment, it’s also worth taking time to reflect on why they’re occurring.
Is your design documentation clear enough, or sufficiently detailed?
Are the choices you’ve made explained in plain language, with reference to the evidence behind them?
This is especially important where those choices might feel counterintuitive.
If you’re only spotting problems at the quality assurance stage, that might suggest designers and developers aren’t working closely together, or connecting as often as they should.
Are there opportunities for co-design, with designer and developer side by side?
Or could there be more frequent check-ins during development of the pages or screens?
Focus on the user, find a way through
There’s no simple answer to any of this.
Complex products and services, in complex systems, are always going to require pragmatism, negotiation, compromise and, yes, conflict.
People will disagree with and challenge each other. But the push and pull need not be unhealthy, as I’ve written before.
As long as when we defend our respective positions we put the needs and safety of users first, it will generally work out for the best.
