This is an excerpt from Designing with your developer in mind, an InVision e-course by Kevin Tomasso.
Design is both an art and a science. The better you become at both arms, the greater your problem-solving skills will become, and, in turn, the better your products.
While there are plenty of ways to bolster your artistic skills, what we want to concentrate on today is the science facet of web design.
Wikipedia defines the scientific method as “a body of techniques for investigating phenomena, acquiring new knowledge, or correcting and integrating previous knowledge.”
It goes on to add, “To be termed scientific, a method of inquiry is commonly based on empirical or measurable evidence subject to specific principles of reasoning.”
“Design is both an art and a science.”
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.
Related: Determining your design principles
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:
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.
While you design, constantly cross-check your decisions based on rules you’ve set or against other design elements you’ve used previously throughout the design.
Continuously ask yourself, “Why am I doing this?”
- 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.
“Continuously ask yourself, ‘Why am I doing this?'”
Setting rules without becoming a robot
You may be thinking, “If I’m constantly second-guessing why I’m doing something, that will hamper my creativity and hurt my design process.”
Being diligent with rules shouldn’t handcuff the artistic side of your design. Instead, it should allow you to identify the best way to represent recurring elements or themes within your design.
You definitely shouldn’t try to define all the rules at once, either.
“Being diligent with rules shouldn’t handcuff the artistic side of your design.”
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.
See? Design is easy.
Style guides to organize your designs
Style guides are one of the best ways to keep your rules organized and ready to use. There are many different ways to formulate a style guide, but at the very least these should contain colors, elements, and type that will be reused throughout the design.
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.
“Employ a logical approach to your design.”
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.
Read the next chapter
Learn to work with developers, not against them, in this free e-course by Kevin Tomasso and InVision. Sign up here to get the other chapters of this e-course delivered straight to your inbox, completely free.
UX/UI Designer/Developer at Homes & Land. Look for me at the intersection of logical and beautiful.