How to create good layer hierarchies for responsive mobile design

One common problem with responsive mobile designs is that the layer hierarchy isn’t being carefully considered during the design process. Good layer hierarchy allows the design and implementation to share a similar UI model, reducing confusion between designers and engineers and speeding up development iterations. It’s also necessary for responsive layouts to work well on different screen sizes, and for creating reusable UI components.

I’ve come up with a short list of guidelines for designers on how to create a good layer hierarchy. This isn’t a comprehensive list and they aren’t rules to live by; just some general tips that may help.

But first….let’s talk layout concepts

Beforehand, I’ll preface these guidelines with some definitions of concepts critical to understanding layer hierarchy.

Layers

Layers are rectangles that can contain content. This may sound obvious, but it’s important to differentiate between layers and their content. Content can come in all shapes, but it’s always inside layers, and these layers are always rectangles.

Responsive layout

Layout is the size and position of layers on a screen. Responsive layouts look good on different screen sizes by adjusting the position and sizes of layers, depending on the screen size.

Layer hierarchy

Layer hierarchy is a tree graph, where layers nest inside one another.

Layer properties

Properties are used to determine the size and position of layers. Layers can have properties like:

• Center — X, Y
• Size — Width, Height
• Edges — Left, Right, Top, Bottom

Property links

Property links enable responsive mobile layouts. Properties can be linked to other properties so they can respond to changes. If they don’t need to be responsive, they can be linked to fixed values such as “44 points”. Properties can have links like:

• equalTo
• greaterThanOrEqualTo
• lessThanOrEqualTo

blue centerX equals green centerX and yellow centerX equals green centerXaligns both child layers with their parent layer.

Now onto some general guidelines that I hope will reduce confusion and ultimately speed up development iterations.

Eight layer hierarchy guidelines for designers

1. Logical grouping

Firstly, group layers that belong with each other, and make sure ones that don’t are kept separate. Each layer should only ever have one parent, but can have multiple ‘children’ or ‘siblings’.

2. Invisible layers

Use invisible layers to group layers. Don’t forget to specify and create property links for invisible layers.

3. One degree of separation

Keep property links limited to one degree of separation between layers. Linking distant layers increases the risk of property changes causing messy side effects. Having localized property links also makes UI components easier to reuse.

4. Chain of command

Decide where a layer derives its properties from, i.e. ask: which layer is the master and which one is subordinate? Having a chain of command reduces the risk of links conflicting.

Exceptions to this arise when two layers link to each others’ properties. Do this rarely and carefully. For example, even though a layer may have its height determined by its children, it can still set those same child’s layer widths itself.

5. Avoid link spaghetti

Individual layers shouldn’t be linked to heaps of other layers. Having lots of links increases combinatorial complexity and the risk of links conflicting.

6. Property limits

Add limits to properties to protect layers from being messed up by their own links. Links such as greaterThanOrEqualTo and lessThanOrEqualTo are useful for preventing layers getting too small or too big.

7. Multiple links on individual properties

Make sure individual properties are linked to only one other property. If this is unavoidable you can use different types of links that don’t conflict, or set different priorities to those links so the property knows which one to choose when they do conflict.

The property links blue width equals green width and blue width lessThanOrEqualTo yellow width don’t conflict.

8. Hierarchy specification

The inherent structure of a layout should be obvious to the engineers. It shouldn’t be necessary to provide diagrams of the hierarchy, or give super detailed specifications. If developers keep asking for clarification, then the layout hierarchy might be too complicated.

Conclusion

Designers, please use these guidelines to think about layer hierarchy during your design process. Your engineers will like you more and your UI designs will be better.

By Aiden Benton.