Document space between components for designers

Question

How are spacial relations between components documented by the big design systems? They only seem to explain how the components look and behave in isolation, not in relation to each other.

For example, if I have an H1 followed by a paragraph, I would like the distance between them to be 40px. On a different page I have an H1 followed by an image, in which case I want the distance to be 30px.

For different combinations of elements I want to define different distances. I want to document these combinations so that designers and developers don't have to figure this out each time and there is more consistency between pages.

For developers this could be documented in css. Designers typically don't see that. How should these rules be communicated to design teams so they use the appropriate spacing between components in their designs?

What is the best method to communicate / document spacial rules between components to designers?

Answer 1

This is a great question that highlights a gap in many articles and conversations about design documentation and pattern libraries. By and large, they’re visual designer-centric and focused on atom and molecule components in isolation. To be useful in practical application, design documentation should explain what to do when and why across a breadth of different examples.

This H1 example is perfect for illustrating this point. (I’m deliberately writing pseudo-styles and not valid CSS selectors or attributes because my assumption is that this question is about how to communicate conventions, NOT about how one can technically achieve the different conditional behaviors.)

H1 Headers

Notes: Use sparingly. Adjust white space according to adjacent design elements. 

Font: Helvetica
Font Weight: Bold
Size: 28px
Line height: 32px
Bottom Margin: 
   IF (followed by paragraph text) THEN 
      15px and show a visual example
   ELSE IF (followed by an image) THEN
      30px and show a visual example 
   END
Letter spacing: 1px expanded
(Etc)

That’s my $.02. Design documentation is already a message in a bottle, but without practical and explicit examples it forces people to make their best guess as to what to do.

**Edit to add an example I found **

This article does a great job unpacking the use of space with intent within design systems. The author deconstructs some pattern-based design elements (in this case cards with content) to show the different conditional rules that are being employed:

From the article:

Most collaborators can’t see space, a primary reason it’s so arbitrarily applied.

In sum: design documentation meant to support disciplined reuse of patterns should be written with that in mind. User-friendly systems illustrate what to do and when using practical, well-annotated examples.

Answer 2

You shouldn't define the padding and margin in the smallest element of your system. A most important property of an element is the attributes unique for that element type, for example for a heading (h1. h2 etc) or any text element, important attributes to communicate is the size and the color of the text.

You should define the spacing in more complex situations, where multiple elemets interact with each other, let's call them "components".

In any given app or website you would have multiple components with different behaviors, those components might look very similar with just small differences, you should document each specification of these components.

In your case you have a content component with text (text_content_bloc) and content components with an image (image_content_bloc), you should document these blocs individually (if there are visual differences like the padding of h1 )

Design systems are living organisms, you will never complete a system and move to the next one, it needs maintenance, iteration and time to time cleaning.

Few good examples of components:

https://material-ui.com/demos/cards/

https://semantic-ui.com/views/card.html

PS: In my experience best systems are the systems with fewer exceptions, if your h1 that have 100 different paddings, you should try to simplify your system, make it more consistent

Answer 3

You could use the adjacent sibling combinator

/* Paragraphs that come immediately after any image */
img + p {
  font-style: bold;
}

For your case you could add a margin to the paragraph or image.

h1 + p {
    margin-top: 40px;
}

h1 + img {
    margin-top: 30px;
}

Answer 4

It would be helpful for designers to see a visual application and examples of the design pattern. You could explain how the spacing is derived (percentage of x element etc) and also the rationale and context of use.

Answer 5

CSS has a hierarchy, when applied correctly, the language has had what you're asking for built into it for a long time now.

A combination of:

CSS Selectors : https://www.w3schools.com/CSSref/css_selectors.asp

And

An understanding of CSS hierarchy: https://en.wikibooks.org/wiki/Cascading_Style_Sheets/Applying_CSS_to_HTML_and_XHTML

Will let you "cascade" your styles across a project, it's as easy as adding an ID field to your forms and locking down your selectors to specific sections or having top level selectors affect the entire site.

To go deeper, you have templates, containers/master pages, and directives/user controls that are used to enforce consistency (again from a technical standpoint).

Answer 6

I think this comes back to the intent of the design language/systems that have been created and what the limitations are with documentation.

The biggest hurdle with trying to document details like the one regarding spacing that you have highlighted in your question is to be able to come up with a consistent rule that applies to all different potential scenarios. Perhaps when you put all the spacing rules for individual components together it doesn't make in all cases, but if you create too many rules then it is probably easier to provide general guidelines and leave it to the hands of the designer to apply them in a practical if not consistent manner.

You'll be surprise how interactive some of the design systems actually are. For example, the Carbon Design System is integrated with CodePen so you can actually try and play around with the styling and customize it to your own needs.

Other design systems specify general guidelines for application layout like the Clarity Design System so you can see how major components on a page might be laid out.

I think the main reasons why these types of detail are not specified are:

• They can restrict the design of the layout to the extent where problems with alignment and positioning becomes problematic (since grid systems are not normally pixel specific to be responsive to the size of the page on different devices).
• They can be difficult to maintain depending on the number of components that you have and the combinations that are used or potentially used, of which most design systems generally have a reasonably large number.
• It can be difficult to make things work across the whole design system when components are no longer used, replaced or combined with legacy components

But luckily this is where designers can come in and help smooth out these issues by working with the developers that start off with page templates and general guidelines for the components, so that there isn't too much adjustment to make for the developer.

In terms of effort versus benefit, I think existing design systems have the right approach and balance when it comes to the level of detail that is specified in their documentation.

Answer 7

Let's leave CSS aside and talk about the visual design. I assume a website has a reasonable number of the page types: landing, product description, dashboard, etc.

a. Include the distance information into the page template. I would create a couple of template pages, that show the specific distance between the H1 and the image/text. For instance, landing page can have 4x between the H1 and image and 2x for the text.

b. Include the distance information into the element template. Specify the top-margin of the image for every image size. I guess, there should be some layout-specific image sizes, e.g. hero-image, product-main, product-secondary etc. In this case, I'd create a group consisting of an image and a transparent rectangle on top of it, so it will be easy to build the mockup from the pre-defined blocks.