To simplify that for our purposes, we can say that the scientific method answers questions by asking “why” against a common set of “rules” we know to be true.

This still may sound a little cryptic, so let’s apply this directly to the design process.

When developing a user interface, you need to base your design decisions on some basic rules or truths that govern your product’s ecosystem. These rules can be based on already established principles and/or best practices, or they can be defined by you as the architect.

For example, there are plenty of icons that are established in the world of UI design that are immediately recognized and associated with particular actions. Below , check out a handful of icons that you’ll undoubtedly recognize and have at least a vague understanding of their purpose:

You didn’t need me to label these.

By including these in your design, you’re basing your decisions on the established associations that these icons carry.

But many rules or principles are up for interpretation and can exist solely within your product’s ecosystem. What do specific colors mean within your product? Do you have custom icons? What animations happen after certain actions?

These are rules that you define as the architect of your product.

My challenge to you is to be more diligent in employing and creating these rules within your products.

Why am I using a double arrow to signify the next slide? Did I use a single arrow somewhere else? Is the behavior the same?

Why am I making the border radius 10px for this widget? Did I use a different border radius on another widget? Do I need 2 different values or should I choose one?

Why does this subheading have a 17px font size? Have I used 18px everywhere else in similar situations? Do we really need to have both a 17px and 18px option?

Why is the margin between these 2 elements 10px and the margin 20px in a similar situation? What is the rule for space between elements?

Why am I using this shade of gray for the background of this sidebar? Is this consistent with the background of a similar use case?

Ask why. All. The. Time. Programmers are logical creatures. If it appears to them that something violates the rules you set forth (on purpose or inadvertently), they will either call you on it or blindly add unnecessary lines of code to the project. Both scenarios end up wasting time.

In fact, this doesn’t have to change the way you begin your design process at all. If your normal process is to lay out the homepage in Photoshop and use that to formulate the look of the inner pages, that’s just fine.

As you continue to work, start to compare elements that you put down on the screen with elements from the pages you’ve already completed. Are you being consistent? Ask similar questions to the examples above and allow your design to organically form the rules for you.

You don’t need to know that you want every paragraph to have 20px of bottom margin from the get-go, but after you realize it works well across a few different scenarios, make it a rule. Now that you know the rule, go back through your designs and make sure all pages that you’ve already laid out follow this rule as well. Use it in all similar situations moving forward.

I like to take it a step further and actually write a brief description of what the elements are used for. This helps me answer my own “Why am I using this particular element here?” questions and stay consistent.

Style guides can also be leveraged within your layout programs. Specifically with Sketch, you can create Symbols for these elements and simply place instances of them throughout your designs.

One of the main mantras of coding is DRY—it stands for Don’t Repeat Yourself. You already created a sidebar background with the perfect background color, border, shadow, and heading, so why go through that all again? Simply place a symbol or object style down and fill it in with the new information.

Knowing your rules and reusing them while you work will drastically speed up your design process.

The ol’ bait and switch

Throughout this post, we’ve been talking about the science and logic behind design. These things sound quite “programmy” in nature like they’re put in place exclusively to keep code clean and help developers.

While this is true, in the long run you’re actually improving the experience for the end user just as much, if not more.

Whether we realize it, as humans we respond to systems and consistency. (Ever been referred to as a creature of habit?)

A website that has a strict set of rules and consistency will simply feel better to users than one that is more arbitrary in its construction. They may not consciously realize or understand it, but it will come across in the end.

Ever hear clients ask for a “professional” and “clean” design? This is largely what they’re referring to.

Think about the aesthetic rules of your product as you work—it’s one of the cornerstones of designing for development. Few other techniques will improve both the user experience and codebase to a greater extent. Make a concerted effort to do so on your next project, and you’ll immediately be a better designer than you were yesterday.