Design, Context, and Intent: Building a More Inclusive Future
By: Sarah Goldschmidt
Tags: Diversity And Inclusion, Product Management, Inclusive Design, Product Design, UX Research

Design is often described as the solving of problems within constraints, or if you’re into formal definitions, the act of creating or executing something according to a plan. I like to use the latter description when talking about design. It better reflects the uniqueness of the act; it’s intent. Intent is a funny thing because it’s focused on an outcome we imagine, but as anyone who’s uttered a poorly timed joke can tell you, good intent doesn’t always amount to a desired outcome.

In the building of the world — the designing of all.the.things — the gap between intent and outcome should be taken seriously. It’s consequences can be far-reaching and equally devastating. That, my friends, is what we’re going to dive into today: how design creates impact far beyond its intent and how stronger contextual framing can help us make better, fairer, kinder designs.

Designing with context in mind

Unless you’ve been living under a rock, 2020 is the year that should wake up every business leader, every designer, heck — every person — to the reality that much of the world we’ve designed isn’t working and hasn’t been working for many people and environments since the beginning. We’re seeing the failure of both objects and systems and the ripple effect of decisions made both intentionally and unintentionally.

That ripple effect is very real and ranges widely from small, local annoyance (why do airplane seats only have arm rests for two of the three people in the row?) to global change. Case in point: the simple interaction pattern for infinite scrolling has made its mark far beyond local ease of use and has rewired how we spend the hours of our day.

Introducing design to the world can be like throwing a basketball into a city intersection — if you’re only looking below the lights, you’re likely to miss much of the impact. That impact is real and often unequally distributed. So what’s a designer to do? Take a look at how design decisions get made and who’s involved in that process.

The difference between constraints and context

The problem begins when we narrowly define what we’re solving. The constraints we design with, at least in the field of digital product design, come to us in a document of requirements directly related to the activity our design is facilitating. Constraints, however, do not describe context. Context includes the human, physical, digital, historical, and societal particulars that, whether we like it or not, shape and are shaped by our design work.

This is the point in which we pause to understand that business requirements and design requirements default to what the business is immediately concerned with — it’s own constituents, customers, users, materials, etc. It’s time for us to broaden what we consider our context so that we may include, impact, and otherwise take responsibility for, our work in the world.

Finding context through questions

Begin with questions. Just as a writer should read more than she writes, a designer should spend more time asking questions than providing answers. Start with what you know: the basics of who, what, where, when, and how — and then follow each one of these lines of questions with WHY.

If you’re designing a mobile ticketing app for the local bus system, start by understanding who rides the bus and why, who doesn’t ride the bus and why, how the traffic route was planned, how ticket pricing works. Who staffs the buses? Who cleans them? Which city offices have ownership of the system? (Side note: it’s never one city office.) Who doesn’t have a mobile phone? Who carries pocket change to pay for their ticket? What happened last time ticket prices were changed? Etc. Pull at the threads you find until you have a broad, thick description of the surroundings of your design, it’s use, and it’s potential impact. At this point your questions should have served the purpose of uncovering not just what you need to know, but who to include and where to test your work.