What does it mean to design for development?

Designing for development is about finding the solution that produces the best possible user experience with the least moving parts.

Web applications aren’t one-and-done projects. They need to grow, evolve, and change—sometimes rather quickly. When making decisions, designers must consider how the design is constructed. A design that looks great to the user but breaks every time a developer needs to make a change isn’t a great design—it’s a pretty interface with an underlying problem.

Designing with development in mind is about working as a team, not merely completing a step in a procedure.

The end goal is to create a great product that’s the sum of the design and development process. A design can improve with the input of a developer, and code can be better written with the help of a designer. Working together and understanding where you both come from will help tremendously in achieving goals and overcoming obstacles.

“Designing with development in mind is about working as a team.”

Designing with development in mind is about knowing the end goals and better answering tough decisions through expanded knowledge of the full picture.

When you can see the forest through the trees, you can better navigate to a destination. In this case your destination is a great product.

What designing with development is not

This isn’t an invitation or excuse to yield to every bit of developer criticism or feedback. And it doesn’t suggest that their job is more important in any way. Just like how a product can’t exist until it’s coded, the product has no place in a user’s life without a design.

The design and experience of a product is what attracts and keeps users. Without a good design, the best sites and apps can only hope to be successful despite their appearance (I’m looking at you, Craigslist).

The reality is that design usually happens first. So knowing what tools and techniques are going to be used to carry out your design will have a much bigger effect than that of the opposite.

It doesn’t do the developer much good if they know how to retouch an image by adjusting the levels and curves and using the burn tool in Photoshop, because by the time it gets to them, they simply have to add the finished image to the site.

Conversely, if you know the best ways to save that image to reduce the file size and increase performance, your product will improve. You can think about helping them do their job while you do yours, but it usually doesn’t work the other way around.

You are the architect. It’s in everyone’s best interest if you know a little bit about how the construction crew does its job.

Follow these simple rules to become an awesome designer

This course is meant to help you design with your developers in mind. What’s left unsaid throughout this is that your job is first and foremost to design with your users in mind. You know this, you’re awesome at this, and you don’t need to hear it from me. The goal is to make you better at the bigger picture so that every design decision you make will improve the product one way or the other.

The simple checklist to run through when you’re confronted with any design decision is as follows:

When there’s a clear benefit to the user, do it. Don’t let a developer talk you out of it if it’s absolutely a better user experience.

Example: If error messages on your site need to be different colors, have specific wording, and show up inline with their form elements to avoid user abandonment rather than a generic message at the top of the page, make it happen. The extra work in the beginning will be well worth it for the success of your product.

“Code can be better written with the help of a designer.”

Ask how you can help get this done. Use whatever facts and sources you can to explain your position, but don’t let the user suffer because it’s slightly more challenging in development.

Investigate whether there’s a way to create a similar effect to benefit the user and the codebase. Many times what you want to accomplish can be done in a similar way that’s easier or less messy to code. Seek developers’ input. Their logical brain might come up with a better solution than you had originally planned that works for the user and them as well.

Example: Maybe the error messages can be categorized and color-coded into a reusable scheme. Instead of having a custom message and color for every input like the example above, maybe there are 3 categories of messages, each with their own color. This allows the developers to better organize and reuse code while still communicating clearly to the user.

When an argument can be made either way about whether an item, design element, or feature benefits the user, choose the path that makes the code more reusable, consistent, or clean. Can your warning messages use your corporate yellow instead of a more typical orange? Both of these convey the nature of the alert to the user, but using a saved and consistent color value cuts down on complexity and keeps the code leaner.