No. 19
Nothing About Us Without Us: Why Communities Should Design Their Own Technology
Participatory design means the people who will live with a technology help shape it from the start. Here's what it looks like in practice, why it produces better data and better tools, and how to run a community session that actually changes decisions.
The Tea the short version
- Participatory design means the people affected by a technology help design it, not just react to it.
- It isn't a survey at the end. It starts before anyone picks a solution.
- It produces better data, because people define themselves and their needs in their own words.
- The test: can participants point to a decision that changed because of them?
There's a phrase from the disability rights movement that I carry into every project: "Nothing about us without us."
It's simple. If a decision is about a community, that community should be part of making it.
Technology breaks this rule constantly. A city picks a new app for benefits. A company builds a tool for "underserved users." A nonprofit buys software for clients. And the people who'll actually use it, or be affected by it, see it for the first time on launch day.
Then everyone's surprised when it doesn't work.
What participatory design actually means
Participatory design is an approach where the people who will live with a system help shape it from the very beginning: defining the problem, setting priorities, testing ideas and judging whether it worked.
It's different from things that look similar:
| This is not participatory design | Why |
|---|---|
| A survey after the decision is made | You're asking for reactions, not input |
| A focus group to "validate" a design | The answer was already chosen |
| A community meeting where the agenda is set in advance | Residents didn't set the priorities |
| Inviting one "community representative" to a committee | One person can't speak for a whole community |
The real version starts before anyone picks a solution.
Why it produces better technology
I'm a data person, so let me make the practical case, not just the moral one.
Better problem definitions. Outsiders often solve the wrong problem. When we started planning the Digital Bridge Lab at the McKinney Center in Seattle's Central District, it began with a community conversation, CD Connected, about AI and digital equity. What residents asked for shaped the four pillars: access, navigation, literacy and community conversation. A lab designed only by outsiders might have been all devices and no navigation. That would've missed the point.
Better data. When people define themselves in the data, in their own categories and their own words, the data gets more accurate. Standard demographic boxes often flatten real communities. Asking "how do you describe yourself?" before assigning categories catches what the boxes miss.
Better adoption. People use what they helped build. They trust it, they recommend it, they defend it.
Earlier warnings. Communities spot harms that designers miss. Seattle wrote this into law with its Community Surveillance Working Group, where most members must represent communities historically subject to disproportionate surveillance. I wrote about that in Who Watches the Watchers?
How to run a session that actually changes decisions
Here's the format I use, refined over years of community meetings, advisory boards and workshops.
Before
- Decide what's actually on the table. If the decision is already made, don't pretend it isn't. Tell people what they can influence and what they can't. Honesty builds trust faster than anything.
- Go where people are. Not city hall at 2 p.m. on a Tuesday. Community centers, churches, libraries, evenings, weekends.
- Remove barriers. Food, childcare, interpretation, accessible rooms, and payment for people's time when you can. Expertise deserves compensation, and lived experience is expertise.
During
- Start with stories, not solutions. "Tell me about the last time technology made something harder for you." The patterns that emerge are your real requirements.
- Let people set priorities. Give everyone dots to vote on what matters most. Count them in front of the room.
- Make it concrete. Paper sketches beat slide decks. People can draw on paper. They can't argue with a polished mockup.
- Name the trade-offs. Real design has limits. Share them and let people help decide.
After
- Report back. This is where most engagement fails. Tell people what you heard, what you're doing with it, and what you're not doing and why.
- Show the change. Point to the specific decision that changed because of their input. That's the test of whether it was real.
- Come back. Engagement is a relationship, not an event.
Measuring whether it worked
If you fund or run community engagement, here are the questions I'd ask:
- Did participants help define the problem, or only react to solutions?
- Can participants point to at least one decision that changed because of them?
- Did the people who showed up reflect the people most affected?
- Did we report back within a reasonable time?
- Would participants come back next time?
If the answer to most of these is no, it was a meeting, not participatory design.
The bigger picture
Technology is shaping housing, health care, jobs, policing and how we get public benefits. The communities with the least power are usually the most affected and the least consulted.
Participatory design is how we flip that. It's slower at the start. It's faster in the end, because you build the right thing the first time.
Pour me another: Have you ever been part of a design process that actually listened? What made it work? Tell me through the contact form.
Sip slow, stay curious.D
I am not a lawyer, and nothing here is legal advice. Facts were current when this was written, and every claim links to its source. Spot something that has changed? Tell me and I’ll update it.

