Data Design

(This was originally published in For 100 of Our Closest Friends, Volume One.)

When designers talk about their process, they often talk about things like sketching and wireframing and usability tests. But it has recently occurred to me that this is not what I usually start out with. The first thing I typically design is the application’s data model.

What kinds of things are there in the application? What properties do the things have? How are they related to each other? Can we normalize this structure, make it simpler?

If the application grows, can this model accommodate the changes?

Recently, I had a very preliminary design meeting about a website that would help people organize soccer matches. This seems like a simple kind of application. You probably have users and teams and matches. Users belong to teams, and teams participate in matches. Well, you probably also need to have events, if there are several matches at the same event.

But wait, if you have events, doesn’t that mean that you might not know all of an event’s matches beforehand? Maybe the event has some kind of run-off system where the winners of a set of matches play against each other, so the participants of that match aren’t known in advance. Okay, let’s drop that for now, but still try to design the system so that we might be able to support something like this at a later date.

So a typical use case would be for an organizer of an event to create a new event, add some matches, add teams to the matches, and add players to the teams. But some teams probably already exist in the system; perhaps the teams recreated their own teams in-system. Wait, we probably need to let players create their own accounts. But if they do that, can they choose which teams they want to belong to?

Or can only team creators invite players to teams? What if a player isn’t yet in the system, but the person who created a team added the player to the team anyway... we need to support something like this, but can the player then claim the spot in the team? What if different people added the same person to different teams, each creating their own player; can the person then consolidate these things into their canonical account?

All of these questions come down to model design. What are the basic entities in the system? How do they relate to each other?

This is often the first thing I think about when designing an application. You might think that it’s not really a designer’s job to do that; let the programmers deal with that stuff. You’d be wrong. The model fundamentally defines how an application behaves, what kinds of features it can support. If your model is an afterthought, if it’s inconsistent with the user interface, your application will never work right.

Start out with the model, and keep it in sight during the whole design process. Don’t let programmers take it over. It’s part of your job.

Further Reading

Nick Disabato:

There are a million small experiential ramifications for your data model, and it’s the death of a thousand cuts if you aren’t thinking of them from day zero.

Johannes Thones:

By looking at the UI, you should not be able to see already the data structure. The UI should be solely tailored to be easy to perceive and understand by the user. Users don’t think in data structures typically – don’t make them. (...) With the former rule at hand, some of us engineers tend to go out, design a view and make the data structure look exactly the same. This it not how it is supposed to be. We have layers in all of our applications to abstract away the data structure, for example in the database, from the user interface. So we should do it. Design the data structure to be efficient and elegant for storing. Not like in the user interface.

I think this is true for systems where you have no control over the data model; in those cases, you need to be careful not to fall into the trap of letting the existing data model dictate the user interface.¹

But the simple fact is that the data model does govern what the UI can do. If we're coming at this from the point of view of a frontend designer who has to turn a poorly designed backend into a human-friendly user experience, we're already starting out on the losing side.

I think the conclusion we should draw from this is the following: having a backend engineer design the data model, and then trying to build a UI on top of it, is backwards. It should be the other way around. We need to design our data structures such that they support the kinds of UIs we want to provide, and such that they are flexible enough to support different kinds of UIs in the future.

This doesn't mean that we should always store data denormalized, or store it exactly in the way it's shown in the UI. It mustn't even mean that UX designers need to become data model experts, and spend their time attending database design classes (although that might be helpful). Instead, it can simply mean that we should do at least some basic UX design work first, and derive data model requirements from that.