The abstraction trap

Abstraction - the generalization of a single instance into a repeatable, sometimes parametrizable pattern that can be reasoned about - is the bread and butter of the technical world. Think for a second about the levels of abstraction that needed to be climbed for you to read these words! Every computer in the world fundamentally only does one thing - binary math! That's it. But we use abstraction to turn that math into letters stored in a database, bits of an internet packet sent to a server and encoded on a magnetic medium somewhere, finally even small colored dots on a screen that look like the letters we want.?

You read that paragraph and probably thought "duh!" right? It is pretty obvious...to us. And that's really the point of this letter. If you've selected into and been successful in the tech industry at all, and most particularly if you work closely with software, you have a very above-average ability to consume, internalize and use abstraction. You're likely very comfortable with it.?

But most people aren't. How often have you heard someone say, "oh I just don't get computers at all" and you laugh a bit at them because it just doesn't seem that hard to you? We've all had moments where we don't really understand why something is so hard for someone to understand - almost always, it's about some kind of abstraction that's hard to handle.?

This can leak over into our design of software very easily, and it's related to the "programmer trap" we discussed earlier. It's very much not enough to test software on people in the industry who not only have this ability to parse abstraction but who also are insiders who understand common design patterns (and IT professionals are "in the industry"). Often, when I get stuck with a piece of software, I can think "ok, what was the programmer probably thinking when they built this" and it can help understand. Most people outside of the industry can't do that - they need something that has a more familiar narrative flow, that asks less of them in terms of complex mental models.?

if you like, you could think of this as a form of accessibility design. If we were, for instance, designing software that was very difficult to use if you were colorblind (which we sometimes do inadvertently), the correct response wouldn't be "learn color" any more than the correct response here is "learn abstraction".?

The right answer is always to go to where the user is and to solve their needs. This is easy to do when we can understand and feel those needs ourselves. It's much harder when we have our own biases and blind spots that are more common in the industry - and in that case, we have to take extra care to design for people who are less comfortable with abstraction than we happen to be. This means lots of user feedback, UXR, constant revising of rough edges, good telemetry to see where people get lost, all the usual suspects.?