Pylimitics

Among other pursuits, I’ve been a software interaction designer. That’s basically a user interface designer without doing the graphics. When I was doing interaction design, I always started from user research. In order to design something that works for users who are not like you, it’s critically important to learn about them. You start by identifying your target audience. Your design is for these people, not those people. In that way, design can be inherently divisive.

But user research can only tell you so much about users. The research scenario, which is usually observing people and asking them questions, puts constraints around what you can discover. People always know more than they can express. And what they know on the day you encounter them will not be the same as what they know two weeks later, especially if that “research day” involves showing them some potential new product or service they’ve never seen before.

For example, all internal-combustion cars made in the past few (or more) years have, right on the fuel gauge, a little arrow pointing to the side of the car where the fuel filler is located. If you were to do some user research, years ago, on a new car that included that little feature among a lot of others, chances are it would go unnoticed. Partly because your research intervention would be unlikely to last long enough for the user to run the car out of gas. And partly because, well, it’s a tiny little arrow, and a lot of people who actually own the cars have never noticed it either (there are YouTube videos revealing that it’s there and they’re “I bet you didn’t know this!” shows).

Nevertheless, you can learn a lot from user research, and product design teams rely on it, rightfully so. There is another way, though. Almost all organizations building products and services start with “a thing people do.” Maybe vacuuming their floors, maybe setting up security policies for corporate firewalls. Could be anything. The point is where the first notion comes from: a specific thing people need or want to do. From there, you research how they might do it now, or how they’d prefer to do it in the future, and you set about addressing that.

Some things, though, are different; they’re tools people can use to do things the design teams never thought of. Couldn’t think of, because research only goes so far. If you’re a designer, your users know more than you do; know more than you can ever find via research.

Decades ago, Apple Computer (as it was called at the time) released HyperCard, and didn’t know the things people would use it for. Whoever invented duct tape (lineage can be traced back more than a century!) had no idea that it would someday be used to make wallets, a bridge, a chess set, boats…just check out Mythbusters duct tape episodes. Notch and Jeb didn’t build Minecraft so players could create a realistic map of the United Kingdom.

Some “made things” are products that enable you to do a thing the designers thought of. “Made things” that are tools, though, enable you to do things you think of. I’ve designed software products and software tools. Tools take longer, are much more difficult, and better. They’re more difficult to design because you’re not really using the use case approach that’s the default in today’s design process. It’s more abstract than that. And while I have still done research, the research doesn’t follow the standard approach either, even down to identifying your “target audience.” If you’re trying to create a really empowering tool, your target audience becomes huge, with more variation than you can cope with.

When you’re trying to create tools, sometimes you have to build them for yourself. Then you find out that you may have made something that works for users who are not like you… except in some really important ways, they are like you. In that way, design can be inherently inclusive.