How to Design for Development

Design for Development

In my role at the intersection of development and design, I see a lot of things being handed off in docs that aren’t necessarily helpful to the developer. Of course, the designer means well—but if you’re at all involved in either discipline, I’m sure you can appreciate the difference between the two.

What can you do to avoid a crushing hand-off meeting? It’s devastating when your design doesn’t become reality, but equally so for the developer who was given a design they can’t actually build.

Being a hybrid designer/developer affords me an uncommon vantage point from which to evaluate communication and collaboration between these two critically important roles. Here are a few tips for designers to help you view responsive design from the perspective of your developers. Use these examples to enhance your understanding of issues that commonly trip up the design + development relationship so you can design for development.

Tips for designing with viewport units

There are a lot of fun and innovative ways to use viewport units. Don’t let them become a stumbling block for your developers. Think about designing elements that scale, regardless of the breakpoint. Browser support for viewport units is now well supported.

Use view width & view height units to scale divs proportionally as the screen size changes, instead of specific sizes at each breakpoint.

We can now scale anything on the page; exact widths are no longer required. I would rather a designer specify 25vw for a block of text than 40rem or 400px.

Further, unlike traditional percentages, viewport units can be specified for either the x- or y-axis. For example, if you want to make a perfectly square object that is 50% of the screen size, regardless of screen size, your hand-off spec for that can state height: 50vw, width: 50vw.

In theory, we could take advantage of the VH/VW units and scale UI’s to fit any size monitor just like TV shows fill any size TV. Check out Fun with Viewport Units to keep exploring the possibilities.

What happens between breakpoints?

Consider not only about how the design looks at an exact breakpoint, but also what it looks like in between the defined resolutions. What’s more, designers and developers both need to have accessibility issues in mind and make sure the end product doesn’t throw up any inadvertent hurdles to accessing the content.

A good front end dev will spend a lot of time solving for layout issues at the in-between sizes that aren’t specified in the design. Try and visualize these issues ahead of time and give recommendations.

Too often, we only provide mobile and desktop mocks—but that isn’t sufficient. The last project I developed had five different breakpoints: ≤600px, 768px, 1024px, 1280px, and 1500px. The layout was so complex I had to add extra breakpoints to account for UI issues that cropped up.

The industry as a whole has a mobile-first mentality, as it should be, but that doesn’t mean desktop browsers should be totally ignored. The truth is that due to the limited screen real estate, mobile layouts are typically pretty easy to build. Designers often get more creative on large desktop sizes, but they only provide a single generic “desktop” mockup as guidance. Desktop often gets designed at around 1400px wide. On complex layouts, that is totally insufficient. Currently, the two most common desktop resolutions are 768x1366px & 1080x1920px.

If the desktop mock you provide is at 1280px wide, and looks like this, how should a Dev solve for 1920px?

If your hand-off doc specs out fixed widths, and you don’t provide any specs for XL desktops, that could result in a design that looks like this at 1920px:

Now that is an extreme example, but I have seen it happen. Your dev may not understand something like that is wrong and isn’t what your design intended.

There are a few ways to solve this. You could simply tell your Dev to create an inner container for the content with a max width of 1280px. That will produce a layout like this:

Depending on your user stats, that might be sufficient if only a small percentage of your user base uses high-resolution screens.

However, a better solution could be to use scalable units or design an XL breakpoint in your mockups.

Otherwise, you’re leaving it up to the dev to do what they think is best—and you may not be happy with the result.

Consider reusable patterns unless unique designs add real value.

Think about reusable patterns and reuse as much as possible without making your design look boring. For years now, both web apps and sites have been built using reusable template partials. Consider how the same layout pattern you design could be repurposed from page to page.

The fewer templates a dev needs to create, the better. The codebase will be smaller, and there will be less to maintain and test.

As a designer, you may want to make every page unique and different, but what value does that offer the consumer? If you can’t identify what the benefit is to your end-user, you could be making a lot of extra and unnecessary work for both yourself and your developer.

Think about how the Dev will have to build it, then come up with ways you can reuse that exact HTML structure but can alter the design with CSS.

Educate yourself on how Flexbox actually works. We can move child items around almost freely within their parent container and all your Dev has to do is add a unique class name for each instance. It’s like cooking—you can start with one base and end up with 100 different dishes.

Design with flexibility in your text wrapping

Text flow is a tough one because there is this constant struggle between what comes first, the content or the design. I have found it helpful to design page elements in a way that the content creators have flexibility without breaking your design. Better yet, specify an acceptable character count range for any given component.

It can be incredibly difficult to get just the right amount of text for a particular design. Designers need to give their content creators some leeway here to ensure that all of the compelling, engaging information that needs to be included is there.

Take the design below, for example. The layout looks extremely simple, just two columns with photos meeting at the corner:

However, as a hybrid designer/developer I can immediately see a number of scenarios that I need to develop for:

• What happens if the copywriter gives the dev a bit too much content?
• What happens if a person is viewing the web page at a resolution that causes the text to flow down further than you planned and pushes the bottom image down? Are you okay with the gap that is going to be created?
• Should the dev scale the images to always fill the space, regardless of image ratio, or would you prefer they always maintain the exact image ratio as much as possible?
• Should the left column be a fixed width while the right is flexible?
• Should both columns scale?

Those are all questions a Dev will have to answer and it should be part of their job to do so.

Even so, be aware that your design will be affected by the decisions they make. How you give your instructions can prevent disappointment in the end result.

Relative vs absolute positioned elements

When you’re designing, think about how an element is positioned in relation to its parent element.

• Does the child element overlap the boundaries of its parent?
• Are you positioning child items inside the parent container that don’t have any positional relationship to each other?

Doing things like this can add visual interest to your design, but more likely than not, you’ve just introduced absolute positioning to the CSS.

Any good Dev should know how to use absolute positioning effectively but in a responsive design, you’ve just given that Dev a lot more work. Depending on the complexity of the design, they might have to specify exact positions at every single breakpoint in order to make the design a reality. If a site has five different breakpoints, you’ve just given that dev 5x as much work to complete the layout.

This is another area that creates a lot of extra work for your Developer and you have to make sure the value is there to justify this. That may very well be if it improves the end user’s experience, but you need to assess and prove that before simply assigning it.

Envision how your design might fit together like building blocks. If everything locks into place, you’ve just made the development easier and more cost-effective.

Understand that not all Devs are created equal

I’ve seen front-end devs of various talent levels throughout my years. That’s not to say that one is better than another, but it’s important to understand that each has strengths in their own unique areas.

To set yourself up for success, be aware of what your team is capable of actually creating.

The devs at Apple or Google being able to create something doesn’t mean that yours will be able to, as well (and even if they could, resources and budget may not allow it). Your job is to design to their ability and the realities of your budget. Feel free to do an aspirational future state design but as a designer, you need to be able to design something that can actually be produced.

I’ve worked on projects where designers didn’t understand the skill set of their developers and it was truly crippling. The developers had no chance of executing on the designers’ vision.

Improving communication with the dev team

The single biggest benefit I had when learning how to transition to the dev world was the fact I shared an office with a Sr. Developer for 10 years. Any question I had, I could simply ask—and I did so almost daily. The same was true of him. Any design questions he had, he could turn around and ask me. A hand-off doc is wonderful and a great starting point, but that’s all it is: a starting point.

There is no possible way to account for every layout issue which will arise throughout the development process. Unless your dev team is fortunate enough to have a unicorn designer/dev, then you will need to be involved in the process.

Whether it’s a single page app or a marketing website, follow through on your design until completion. Let the devs know if they see a weird layout issue to bring you in to offer visual guidance. Be a part of the development process.

The physical space you work in is important, as well. If you’re working remotely, make it a priority to have face-to-face video meetings so you can talk issues out and have those important visual cues to help the conversation and relationship.

If you’re struggling to get your designers and developers on the same page, we can help. Get in touch with Method today and see how a dedicated and experienced digital partner can help each of your team members operate at their greatest potential and fulfill your experience design needs.