If I showed you a design, and asked you how difficult it would be to implement, could you give me a coherent response?

When non-tech people ask me about my job, I often use the metaphor of the architect of a building, and the lead developer is the civil engineer. I remember hearing jokes from college architecture students, that the architect envisions craziness, and it’s the job of the civil engineer to tell them that it’s structurally impossible.

I’ve never designed a real building (sue me) but if this were true, you can't deny it would decrease the productivity of the team. Architects need a basic foundation in structural integrity, so that they don't get into arguments about basic physics with civil engineers.

This is why it's surprising how many designers lack a fundamental understanding of app development. All designs in Figma will eventually become code, so why not become a little proficient in that process and principles that turn designs into reality?

Having a background in computer science and experience in coding has made collaboration with developers smoother for me. I hope I can give a small set of concepts I use in my design process to get you started.

Different programs work in different ways. For this post, I'm going to focus on single page web applications or mobile applications.

We'll explore this with a hypothetical rating app for music venues.

The 3 Numbers of Computer Science

0, 1, and N.

Computer programs don't care about the number you give them. The numbers 3, 4, 10, and 100 do not matter to a computer program. They all fall under n. A page can have n venues. An artist can have n reviews.  I have seen developers be asked how difficult would it be to support 20 items on a page instead of 10, and I can see them roll their eyes in their own minds. It can support 999,999 items if you like, the number doesn’t matter.

The best way to empathize is to watch ALI G ask “techmologists” some hard hitting questions:‍

When deciding limits for n, it’s never about the technical constraint, it’s about the limits and understand for the user. On Google, it’s worth paginating to 10 items, for the sake of speed. On instagram, we want users addicted for ever and ever to fill their brains with ads, so the feed is an infinite hole.

Think Complexity not Quantity

In the real world, making 3 products is more expensive than making 2 products, so it's hard to understand how in the digital world it's not the case. A good way to visualize this is with a single file on your computer. Making a copy of the file, is no problem, and you could do it 100 times. However making the file more or less complex is where the real work happens.

Questions to ask:

• Am I merely changing the value of n, or am I adding another n to the design?
• Does copy require computation (n), or is it never going to change (1)?
• What does my design do when n=0?
• What values of n fit neatly into user's minds?

Databases

If you are working on a network app, or any app, chances are you are using a database, this is the furthest back part of the app stack, and anything you design will need to be represented in the database. I have seen many noob designers thoughtlessly add a new feature, thinking it would be easy, only to have a developer explain to them it would add too much complexity to the bewilderment of the designer. Generally speaking, this is because modifying the database risks perverting user data, and must be done with great care.

If you understand the database, and what is represented by it, you can take any design, and ask yourself if your developers will need to modify the database in order to make your design a reality, or if you can improve the app using the existing reality.

A database schema is a blueprint that defines the structure of a database. It specifies the tables, columns, and relationships between them. The schema is essential for ensuring that the data in the database is organized and consistent. You’ll hear talk of tables and columns, think of them as spreadsheets, except each row has an ID which you can reference in another row:

UI is nothing more than a communication tool for data.

One-to-One Relationships (1-1)

A 1-1 relationship is a relationship between two tables where each row in one table is associated with at most one row in the other table. A relationship in our example could be the relationships between a venue and it's address. Each venue has exactly one address, and each address corresponds to only one venue.

One-to-Many Relationships (1-N)

A 1-N relationship is a relationship between two tables where each row in one table is associated with one or more rows in the other table. In our example, each venue could be associated with many reviews, but a review can't have multiple venues.

‍

Many-to-Many Relationships (N-N)

An N-N relationship is a relationship between two tables where each row in one table can be associated with multiple rows in the other table, and vice versa. For example, in a music venue rating app, each venue could be associated with many artists, and each artist could be associated with many venues.

When I am trying to understand the idea of a client, I’ll usually make a rough sketch of the database schema, so I can visualize the data my app intends to express. You can leave the details to the real developer, but it helps to have a basic breakdown. Let's look back at our venue rating app:

• A user can write many reviews, but a review can only be written by one user
• A venue can have many reviews written about it, but a review can't be about multiple venues
• A venue can have many shows, but a show can only be at one venue
• An artist can have many shows, and a show can have multiple artists

Questions to ask:

• Am I expressing the same data by making this change, or does my change require new data?
• If I'm changing the data that should be expressed, is it a new column in an existing table, or is it an entirely new table?
• Can X have many Y but Y can only have one X (1-N)?
• Can X have many Y and Y have many X (N-N)?

Network Requests

I’m stating the obvious here: very little information is stored on your device. Most data retrieval on your app looks like this:

To the average person, this is pure magic, but to the folks in a tech company, it helps to have a tiny little breakdown of how this happens.

The App Stack

If any devs are reading this, it's not the perfect break down of everything that happens in an app, but it is a rough breakdown of what any architecture in an app needs to accomplish.

Database (server)

This part of the app stores all the data pertaining to every user who has made an account. This is the source of truth for the data your designs express. Think of it as all the drawers in an archive.

API (server)

This stands for "Application Programming Interface", and is responsible for pulling information out of the data in a way that's consumable to the individuals. It's like the person working the desk at the archive, you tell them what you need, and then they go search it for you.

Repository (client)

This is the gateway for the app to interact with the API and any other information the device needs. If Spotify needs songs, it will send a signal to Spotify servers to get the right audio files. This is the person talking to the archivist. It can also be for accessing data from the device, like health information or permissions.

State (client)

State is the data that should be expressed by a particular screen, and the information needed by the screen to show the relevent aspects of the data to the user. For example in Spotify, it might be both the song, and the position of the playhead in the audio file.

UI (client)

This, ultimately is what designers design, and the only thing users should see. It's the paint job on the drywall. In most development frameworks, UI should basically be dumb. State is changed, and UI merely expresses that change in state.

Gauging Difficulty

The basic question you are asking yourself when making a design change, is how far up the app stack does this change go? Are we painting the walls a new color, or are we getting the sledgehammer and knocking out 2x4s?

• Changing the font size of a heading is just UI: negligibly easy.
• Making the content of the header dependent on the current venue requires accessing state. Still a joke, but a little more difficult than a font change.
• If we want a new view of shows for an artist, but shows are only shown in relation to shows, then we need a new API call. We're getting more involved here.
• If we want to give users the ability to comment on shows, we're going to need a new database table, and we're going all the way back to the database.

Loading States

Loading, that leap across the void from your device to the API and database, is often the longest part of the data retrieval process, and it's the only time you can expect users to wait. This is why it's crucial to take loading states seriously. By designing thoughtful loading experiences, you can manage user expectations and maintain engagement even during delays.

This is a popular method for improving loading states. By changing the loading screen to a skeleton rather than a spinning circle, we give users an expectation of what they are going to receive when the loading finishes, adding a bit of anticipation. We don't change the wait time, but we make the waiting more fun.

This is also the only real place technically where the value of N does matter, and images and video take the most data.

Error States

Because we live in an imperfect world, we have to assume that something could go wrong anywhere in the process. When designing error states, think about the different places on the stack where the things could go wrong.

The user could input bad data on the client, such as a poorly formatted email address, or they could type in a correct email address, only for the app to find out when pinging the server that the email does not exist.

The closer to the UI you catch errors in the stack, the smoother the user experience will be.

Questions to Ask

• What data is my UI expressing?
• How far up the app stack do we need to go to make this change?
• Is that data available on the device or on the server?
• If the data is only on the server, what happens while the data is being retreived?
• What happens if there is an error in the data retreival process?
• Do errors take place before or after the network request?

Bringing it together

Let's go back to our original prompt, how hard is it to implement that design change we talked about?

We want to add upcoming shows to the venue page.

Does the amount of shows on the venue page matter? Not from a technical perspective. But showing 3-5 shows is probably fine for the initial load. If they want more, they can view more on a seperate screen.

From the perspective of the database, the difficulty comes down to Does our app already have shows listed on another part of the app? If so then it's already in the database, otherwise we need a new table.

If we assume we already have shows for artists in the database, then we'll just need an api call to filter shows based on venue.

Happy Building!