In previous posts, I presented a viewpoint about how to organize teams for collaboration. In a way, the previously shown organization methods describe ways to promote inclusive design.

What exactly do I mean when I say “inclusive design”? Inclusive design is the process where a diverse set of folks provide feedback and share in the design process from the start. When I say diverse above, I don’t only mean others that don’t look like you or have the same characteristics as you; I also mean different disciplines.

Hearing the perspectives of various people during the design process sounds very obvious. However, in practice, teams often do not seek this sort of inclusive design culture. For the most part, there isn’t a deliberate statement to exclude someone. What ends up happening, though, is that there are several assumptions made about the problem or environment where the end product will be operating. Oh, and add on top of that a deadline that’s coming up quickly or is already past due.

Let’s reflect on an example. A developer must deliver new functionality on a website that allows configuring a unique setting that previously was immutable. This task sounds very simple. An initial approach the developer considers is merely adding a textbox under the application settings, restrict the textbox to the type of input expected (after all, they have heard about input sanitization), and write it to the database that already exists. Their immediate team reviews the design, the developer codes it up and submits the pull request, only to find that a subset of the tests broke and the git automation for secret management pages the whole team. What happened here? This “simple feature” didn’t turn out to be so “simple.” Were the folks specializing in testing consulted on how adding the textbox would affect automation? How about understanding the access patterns to the database? Were the designers asked to evaluate the usability of the configurability of the application? How about the accessibility of this new setting or handling input in different locales?

Perhaps the example is a bit contrived with some very cooked up cases. However, many reading this will relate to a problem that suffered because inclusive design principles weren’t applied initially. (In all fairness, though, the example isn’t all that contrived. I’ve seen each of those happen on separate instances!)

Here’s a call to action!

The next time that a design task lands with you and you think the design is complete, ask yourself whether you were genuinely inclusive in the design process. Did you leave your desk early in the design phase to talk to others across the team? Did you seek out those with testing, infrastructure, security, or user design experience? Did you try to understand the bigger picture of this task? Let’s make it easier for our software to use and operate. We owe it to our future selves.