I keep thinking about this blog post I linked to last week by Jacob Kaplan-Moss. It’s called Quality Is Systemic:
Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.
I think he’s on to something. I also think this applies to design just as much as development. Maybe more so. In design, there’s maybe too much emphasis placed on the talent and skill of individual designers and not enough emphasis placed on creating and nurturing a healthy environment where anyone can contribute to the design process.
Jacob also ties this into hiring:
Instead of spending tons of time and effort on hiring because you believe that you can “only hire the best”, direct some of that effort towards building a system that produces great results out of a wider spectrum of individual performance.
I couldn’t agree more! It just one of the reasons why the smart long-term strategy can be to concentrate on nurturing junior designers and developers rather than head-hunting rockstars.
As an aside, if you think that the process of nurturing junior designers and developers is trickier now that we’re working remotely, I highly recommend reading Mandy’s post, Official myths:
Supporting junior staff is work. It’s work whether you’re in an office some or all of the time, and it’s work if Slack is the only office you know. Hauling staff back to the office doesn’t make supporting junior staff easier or even more likely.
Hiring highly experienced designers and developers makes total sense, at least in the short term. But I think the better long-term solution—as outlined by Jacob—is to create (and care for) a system where even inexperienced practitioners will be able to do good work by having the support and access to knowledge that they need.
I was thinking about this last week when Irina very kindly agreed to present a lunch’n’learn for Clearleft all about inclusive design.
She answered a question that had been at the front of my mind: what’s the difference between inclusive design and accessibility?
The way Irina put it, accessibility is focused on implementation. To make a website accessible, you need people with the necessary skills, knowledge and experience.
But inclusive design is about the process and the system that leads to that implementation.
To use that cliché of the double diamond, maybe inclusive design is about “building the right thing” and accessibility is about “building the thing right.”
Or to put it another way, maybe accessibility is about outputs, whereas inclusive design is about inputs. You need both, but maybe we put too much emphasis on the outputs and not enough emphasis on the inputs.
This is what made me think of Jacob’s assertion that quality is systemic.
Imagine someone who’s an expert at accessibility: they know all the details of WCAG and ARIA. Now put that person into an organisation that doesn’t prioritise accessibility. They’re going to have a hard time and they probably won’t be able to be very effective despite all their skills.
Now imagine an organisation that priorities inclusivity. Even if their staff don’t (yet) have the skills and knowledge of an accessibility expert, just having the processes and priorities in place from the start will make it easier for everyone to contribute to a more accessible experience.
It’s possible to make something accessible in the absence of a system that prioritises inclusive design but it will be hard work. Whereas making sure inclusive design is prioritised at an organisational level makes it much more likely that the outputs will be accessible.