Databases for Designers
*Gasp* this is not an article about learning to code. Disclaimer: I still think designers should learn to code, but I’m more convinced that databases should become a core part of a designer’s education even before code. I get that in design programs you can’t learn everything, but if you want to be next-level, this is up there in my opinion.
Why learn about databases?
I did not start out my career or my education as a designer — I got a computer science degree, a major part of which is learning about data and databases. When I became a designer, I didn’t even think twice about how data affected my designs; it was naturally part of how I designed.
As I started running an intern program, I found a consistent theme that they had never been taught about content management systems or databases. This resulted in work that usually had to be reworked not because they were bad designers, but they didn’t understand how data and databases undergird a lot of design.
It turns out that understanding data and databases is a major part of creating feasible designs.
One lesson on content, content management systems, data, and fields drastically improved how feasible their designs were. By making that part of my orientation I could cut out critique sessions that were just me repeating, “We can’t do that, it’s not part of the database” in different ways.
Demystifying Databases
There are different types of databases, but the ones I’ve run into most often rely on 3 core concepts: objects, fields, and records.
Objects
An object is…a thing😅 For example, let’s take a book. A book has a title, publisher, copyright year — these are all pieces of data about the object, our book.
Fields
Fields are the pieces I just described — the title, publisher, the copyright year, etc. that make up the object.
A field also has a type so that you know what kind of data is in the field.
Text
Long text
Dropdown (set options)
Date
Number
Email
Phone
and there’s a lot more
So let’s take our Book and make it into a database object!
(I’ll get to the blank space shortly!)
In the picture above, we have a box with the title of our object, then each field with its field type.
Record
We don’t want just abstract books, we want data about real books. So let’s fill it in a little bit.
Book
Title: The Design of Everyday Things — Revised
Subtitle: NULL
Publisher: Basic Books
Copyright year: 2013
Genre: Educational
When I fill in the fields, I have a record, otherwise known as an instance of an object. Also — fun fact, if you don’t have a piece of data, NULL is how you describe it being empty.
Now we’re getting somewhere. But what if there are multiple books called The Design of Everyday Things? We need a way to make sure each record is unique, which we do with a primary key.
Most often the primary key is a number, but not always, for example in user data we might use email as our primary key. You can also combine fields together to make a primary key.
Bonus: Related objects
You may have noticed that I didn’t include author. The reason for that is a book may have multiple authors! An author may have authored multiple books! We may not know how many authors there, and so we don’t want to limit ourselves with fields like: Author 1, Author 2, etc. And furthermore, we may want more information about an author, such as their email, phone number, etc.
If that sounds like another object to you — then you would be correct! Let’s put together a quick Author object.
Now, how do we connect a book to its author? We use what’s called a “relation”–a specific type of object that contains information from both the Book object AND the Author object.
It’ll need an ID and Primary Key as usual, and we’ll add in a piece of data from the Book and the Author as foreign keys. Typically, you use their IDs since you know that is unique.
Now let’s show the connection between our objects
BookAuthor:
BookID: 13413
AuthorID: 1
BookID: 13413
AuthorID: 8375
Because the BookIDs match, I can see that there are 2 authors for the book, and take the 2 author IDs and go look up in the Author table which two authors it is.
This record below shows me that Author #8375 has also written another book.
BookID: 1333
AuthorID: 8375
Putting this in action
Design
So, if we were to design a page to display our books, we have to make sure that what we’re referencing is part of the database! Below I’ve got our title, author name (because of the relational object!), genre, publisher, publish year, and…that’s it, because that’s what our database has.
But, what if I want something that’s not there?
You may have noticed I have no images! That’s because as is, our database has no images for books. If you decide you need data that is not there, you’ll likely hear questions like:
What kind of data is it?
Where do we get that data from?
Who will get it?
How will it stay maintained?
How will we validate it?
What if we can’t get that data for every record?
You’ll need answers for these or have to work with others to get them, or, design without it.
When will I run into this?
Databases often pop up in cases like:
Blog posts
User profiles
Reviews
Any kind of listings — jobs, apartments, people, you name it.
Essentially, any kind of content that is repeatable and might show up in a list is probably coming from a database!
Try it yourself!
The best way to learn is to try it. If you can poke around in the database or get a list of the fields and how they relate from your engineer before starting, you’ll be set. Ask for an Entity Relationship Diagram (the fancy name for the boxes I’ve been making above) and learn more about how to read it. I highly recommend Airtable as a way to play with a database, and you can see my Book database here.
