In the world of software development, the role of design is often thought to belong solely to the realm of graphic designers and UX experts. 

But in truth, every software developer is a designer. And I'm not talking only about front-end developers. I'm talking about all of us.

Every code needs a design, even if it’s just the underlying structure and logic that powers the software. All developers are designers because they make choices about how the software will work and interact with users, as well as how it will function under the hood.

This is most obvious with front-end developers, who create user interfaces and work closely with designers to ensure that the design is implemented correctly. They have a huge impact on the user experience, and their choices can make or break the design. For example, a well-designed interface will be intuitive and easy to use, while a poorly designed one will be confusing and frustrating.

But every piece of software needs a design, not just the front-end. A well-designed API is easy to use, while a poorly designed one will be difficult and time-consuming to work with. I've worked with APIs that are great, that didn't even need documentation, and ones impossible to understand. 

This is why every developer needs to be a designer, as they must think carefully about the design and structure of their code to ensure that it is effective and efficient.

How design rules can make your code better

The problem for developers is that they usually don't know anything about the design. But don't worry; I've got a shortcut for you.

A great way to understand the importance of design in software development is to consider some of the principles of gestalt psychology. They are critical design rules for UX and UI designers. And I'll show how using them can make your code better and more intuitive. 

Principle of proximity

The principle of proximity states that objects that are close to each other are perceived as a group. This principle can be applied to software development by organizing code into logical units and keeping related code close to each other. 

You can use this principle to make your code way easier to follow and reduce the clutter in the codebase. A great example of using this principle is organizing code into modules or classes. Having related functions and variables together makes the code flow naturally and reduces the cognitive load of anyone reading the code.

A good rule of thumb on code proximity is:

Things that change together should live together.

If you notice that any change in your codebase requires edits in multiple files, your code is probably not following the principle of proximity.

The principle of proximity has its inverse effects too. The code that is not logically connected shouldn't be close. Instead, we should group it into different modules, files, or classes.

By using the principle of proximity, you can write better code that is easier to understand and maintain.

Principle of similarity

The principle of similarity states that objects that look similar are perceived as being related. This principle can be applied to software development by writing code that is consistent and easy to understand. 

You can take advantage of the principle of similarity by using consistent naming conventions. Naming functions, variables, and other elements of the code in a consistent way helps to reinforce the similarity between related elements and makes it easier to understand the code.

And, of course, different things should use different naming. For example, we usually use different naming conventions for functions and different kinds of variables:

• functions names have a verb in them, like getToken,

• booleans have “is” or “has” in them, like isAdmin or hasDependencies,

• arrays or other collections are plural, like users.

You can create your own naming conventions but remember to make them consistent.

Another way to adhere to the principle of similarity is to use similar structures for similar tasks. Try using the same methods or loops to perform similar tasks. Also, don't use multiple different libraries or components to solve these same problems. This will help to reinforce the similarity between elements of the code and make it easier to understand.

When you create your APIs, remember to make your endpoints similar in structure. It will make usage of these endpoints much easier because if the user learns to use some of the endpoints, it will allow them to use all of them.

By using the principle of similarity, you can write better code that is consistent and easy to understand. This results in higher-quality software that is less prone to bugs and more user-friendly.

Principle of continuity

The principle of continuity states that the human brain perceives objects as being continuous and connected rather than separate and disconnected. 

This principle can be applied to software development by writing code that is easy to follow. The most important part of continuity is writing code that follows a logical flow. Whenever possible, your code should follow the flow from top to bottom and don’t require many jumps between different files.

You can also enhance continuity by using clear and descriptive functions and variable names. Naming things is difficult, but if your names are descriptive, it makes the code way easier to follow.

You should also avoid abrupt changes in code style. Use consistent design patterns and follow your company style guide. It will help to reinforce the continuity of the code and makes it easier to understand what is happening.

Principle of organization and symmetry

The principles of organization and symmetry refer to the way that the human brain organizes and interprets sensory information and what it perceives as being balanced and harmonious.

These principles can be applied to make code well-structured and balanced. 

Good organization requires you to write modular code. That means code that is broken down into smaller, self-contained parts. Smaller components are not only easier to reason about but also create a sense of harmony in your codebase. 

Pushing for smaller components shouldn’t be absolute. If the logical flow of the code requires it, it’s fine to have some bigger components or classes here or there. But you should avoid creating multiple huge files that overwhelm any developer who sees the codebase for the first time.

Another way to improve your code organization is to use appropriate data structures, especially taking into consideration clarity and use of use. In more complex cases, also consider memory use and performance.

I hope these design rules can help to make your code better the way it helped me over the years!

Liked the article? Share it!