Backfilling Design

I recently came onto a client project to design an interface to help their people make sense of the data they’ve been collecting. The system has a lot of other uses, and so far, data analysis hasn’t been a priority.

In a pattern I’m seeing repeatedly, they’re collecting everything into a data lake and (mis-) using off-the-shelf tools to help their subject matter experts make sense of the data, without much consideration for — or even knowledge of — what those people are trying to accomplish, or how (in-) effective the off-the-shelf tools at accomplishing those goals.

While investigating the topology and semantics of the existing system, I was told well, we haven’t done any design on this yet. I am a firm believer in the idea that design is how it works, and my off-the-cuff response stuck with me: You have a working system, therefore you have a design; you just didn’t create it intentionally.

Perhaps the only time you haven’t done any design work on a product is when it still lives entirely inside your head — when it’s still a fantasy in the realm of pure theory, when it hasn’t yet met the messy real world. When you’re figuring out how to make it work, how to make it real, how to balance the myriad of tradeoffs you’re going to need to make to realize the idea, that’s design work.

Places on a project where I’m invited to come in to do my work are often places where there wasn’t much initial importance placed — they weren’t the priority — but something was created anyway and what was created anyway has a design, it just doesn’t have an intentional one.

Let’s look at perhaps the smallest of relatable examples in interaction design: you have database records in a multiplayer system, and it’s possible that two people could attempt to update the same document at the same time. What happens if they do? Are you using CRDTs? Are you attempting to do conflict resolution? Are you doing optimistic locking with a version column, and the first update wins?

Unless you’ve thought about the problem, you’re probably doing the default thing, which for many database systems is the last update wins: Alice and Bob made conflicting edits to the same thing and Bob’s internet connection is slightly slower, so Bob’s update clobber’s Alice’s update, and no one is the wiser until Alice’s boss asked what happened to her update, and the context surrounding it is lost and, oh well.

This behavior may be a default, and it may have been chosen without intentionally. But the behavior is still how it works, and that’s still a design.