Latest posts

Maintainable responsive layouts

There are many design decisions that need to be made in order to get started with a large project. There’s nothing that can’t be undone, but misjudgements at this stage can have a significant impact on how easy the system is to update as well as affecting the speed of development and performance.

I thought it’d be useful to share how we created an effective layout system for Endsleigh as it’s proven to be an efficient way of working. I won’t be discussing code, rather I’ll be stepping back and looking at the concept behind the layout design.

Common pitfalls with responsive design

When building large websites, there are multiple team members working on both the layout design and front-end development. How should a designer document page layout to a front-end developer? Mocking every page element up at every width is impractical and isn’t helpful, as it relies on the developer to decode the system behind the design. A good handover should be concise. Deliverables should have been thought about and boiled down to provide the developer with what they need to build the system. It’s a phrase often heard, but we need to design systems not pages. The more condensed and focused the handover, the less confusion there is. It can seem like more design time upfront to prepare this condensed handover, but the time saving for future design tasks, development and testing shouldn’t be underestimated. A happy production team is one that has an easy to follow design style guide and a concise codebase.

A closer look at the Endsleigh layout

The system used on the Endsleigh site needed to be easy to understand for everyone on the production team. We wanted to keep things as clear as possible and only vary the layout where needed. After exploring the content during a discovery stage and starting to think about different layouts, we were able to decide on where best to place the breakpoints so that the design wouldn’t fall apart.

We deliberately decided to make the design focused and didn’t want the layout to change unnecessarily. We also wanted to keep the information density high and allow easy scanning of the content. This meant avoiding blowing up the design too much at wide viewports. The website analytics also informed the decision on where the minimum and maximum browser widths should be. We chose to split the layouts into five groups with fluid columns at the following breakpoints:

  1. 300-399px
  2. 400-499px
  3. 500-699px
  4. 700-849px
  5. 850-995px

(We actually convert pixels to REMs during development, but I find it easier to think in terms of pixels.)

Illustration of the five layout groups used on
The five layout groups together.

Splitting the layouts up into five groups might sound like a lot, but we do this to provide flexibility should we need to modify a module slightly. We try to avoid using unique breakpoints for individual modules as this results in undesired complexity and makes debugging more difficult.

The layouts for groups 1+2 and groups 4+5 can be very similar. Most of the time, we’re actually thinking about there only being three groups. This saves time and helps keep the system manageable.

  • Group 1a: 300-399px
  • Group 1b: 400-499px
  • Group 2: 500-699px
  • Group 3a: 700-849px
  • Group 3b: 850-995px
Splitting the five groups up
Each group is given a name.

The advantage to using these additional groups, is that it enables us to make visual tweaks to particular modules when needed. Because the gutters are fluid, it means that we tweak them at the sub-groups to make sure they don’t get too narrow. Making sure that groups 1a and 1b have the same number of columns means it’s easy to use the same layout for both groups.

Layout tweaks between groups 3a and 3b
The layout generally stays the same between groups 3a and 3b. Splitting these up has the advantage of allowing us to make small layout tweaks, such as the positioning of the purple panel in this image.

Having a system like this provides the designer with a way to create shorthand mockups. The designer can simply say ‘same as group 3a’ and the developer will know what they mean. This is better than duplicating design elements as there’s much less ambiguity.

Mockup for with annotation for developer
The primary content area is the same in both these groups so can be quickly documented as such.

We chose to keep the padding on modules quite tight. This means that there can be consistency between the padding on all page elements such as call-out boxes and buttons.

Padding on Twitter module
We use fixed padding of 10px. This doesn't scale and is consistent at all viewport widths.

Combining horizontal and vertical guides

Typography can quite easily fall apart when designing responsive layouts. Deciding upon typefaces and font sizes is another topic, but these decisions do influence the grid. To help the typography and layout play nicely together, we chose font sizes that work well when the line-height is a multiple of 5px.

5px baseline overlay
Baseline guide shown overlaying the content.

This Endsleigh grid system has been designed in a way that makes it as enjoyable to work with as possible. Although the grid is fluid, the column widths have been calculated to make it very easy when designing new modules in a graphics package as everything snaps to 5px.

To summarise

The benefits of adopting responsive layout are obvious, but doing so properly is harder than it looks at first glance. The goal is to serve tidy layouts to our site visitors, no matter what device they are using as, without care, at some browser widths ugly layouts can slip through the net. By setting considered constraints, not only can we establish a bit more control over what the visitor will be seeing, we can also use budgets more sensibly and improve the lives of the designers and developers behind the scenes.

If you’re interested in taking a closer look at the structure behind the Endsleigh layout, feel free to download the layered templates here.

Phil Swan
Published in: