Back to all Design Systems work

Layout Architecture

Workflows established to facilitate a design to engineering pipeline

Working with engineers.

Design handoffs often includes “invisible” rules that don’t have consequences within a design but do in a live product. Making those design rules visible and defining their data is a process that requires marrying design and engineering.

‍

There is a lot of debate over whether or not designers need to code or if engineers need to design in order to develop a successful delivery process. In my opinion, both designers and engineers need to base their approaches on product logic. How that logic applies to the role of a designer and an engineer may be different, but being fluent in the same logic makes efficient collaboration possible.

layout

Rules for component layout rendering needs to be accounted for within your system.

‍

In my experience, the most frequent place that is overlooked by designers, is within the container structure of the design. Components are powerful building blocks and their behavior within the DOM is just as important to define as the data they hold.

‍

Knowing there are elements dedicated to handling layout behavior means we can define system components that accept layout rules from their parent container. Hugging the elements that hold component data within our system components allows for maximum flexibility.

‍

Organizing layout rules within a nested wrapper architecture is prescriptive — we know what we need to affect to achieve the functionality we’re after.

Defining markup architecture: Card layout example

The container structure defines where styles are declared while being able to hold and properly render dynamic content.

‍

Case for integrating dev workflows into design foundations

Spacing, sizing, and direction rules need to be set on both sides of the workflow but how and were rules are set doesn’t need to mirrored in order to achieve the desired rule on either side.

‍

By using a layout model like you see above, we have a model for where rules, such as padding is applied to a surface component. Surface components, such as a card, may have different uses and hold different content but should retain consistent visual system patterns across a product.

‍

Knowing where to target when applying revisions, adding variants, or building new components is established for us. This helps prevent visual system conflicts and makes it easy to review and revise visual system rules across multiple components and component variants.

‍

problems this solves
  • Forward-looking
  • Standardized
  • Set it and forget it

‍

Building a “Basic Message Card” components with this model.

This is a simplified example that illustrates how to work with the layout breakdown above. This card accommodates different media types and both primary and secondary action menus.

basic message card

We’re creating two variants: Default and Disclaimer. The required components show which components and content blocks (defined elsewhere) are required to build the entire component. As we build both unique variants, we’ll show which requirements need to be pulled in.

Card layout documentation

This is a model used in Component Documentation that shows the nesting structure used for a card component. The naming convention applied here is part of a pattern I used across all components.

‍

wrapper

The outermost container which hugs all data.

‍

container

An internal container, of which there can be several, that hugs content.

‍

content (or content container)

This is where content is held.

‍

In most cases, wrapper and containers are establishing style rules between each other or within themselves and their children. A universal format gives us a guide to where and how to establish styles. Rules required could be spacing, colors, or other visual design elements. Even if there are no rules established, the layout architecture should be maintained.

1. card template

Two variants are defined for all cards — flat and elevated. While styles are defined for both, which styles are required is unique to the variant. Defining props for all variants in a single rule, even if they aren’t required for all variants, is part of setting up a styling cascade.

‍

“Basic Message” requirements declare that we need to use the Elevated variant

2. layout breakdown - body section

We’re using the card model to establish a layout. While the model gives us the outline for the card’s architecture, we still need to apply contextual rules as well as styling rules.

‍

  • Blue lines: Layout containers (Outer)
  • Red lines: Content containers (Inner)
  • Solid red: Shows padding (area between the outer and inner containers)

Because cards can have a single media item or a group of media items, rules for both are built into the component. The single item view is our base style and the multi item view inherits its rules and adds its own.

‍

Component styling is mostly additive. That means that a view, such as “Multi Item View” builds its rules in addition to the base rules. Again, this is the style cascade.

Container breakdowns help designers as well.

Layout breakdowns help define where styles should be added.

  • Where is the best place to declare padding rules?
  • Does some, or all, content need to extend the full width of the container?
  • Is there a row of items that need to be spaced differently if different amounts of items are rendered in different instances?

These are common questions designers ask themselves. Matching the desired design direction against a layout breakdown helps designers see where to apply those rules.

4. content views - footer & disclaimer sections

Just as with the body sections, the footer and disclaimer sections show contextual examples of their respective sections along with the components required to build these sections.

Layout templates.

Components are placed within templates following the Atomic Design model. The layout architecture defined above means that the component's outermost container safely "wraps" the component and allows the template to control its own layout rules without requiring us to dive into the component(s) in the template layout to edit and set properties.

Page templates.

While not shown here, page templates hold layout templates and are what makes the entire layout come together. Dividing and assigning layout requirements within a logical and leveled method means we can rapidly build layouts.

‍

‍

jump to section
jump to section
layout

Rules for component layout rendering needs to be accounted for within your system.

‍

In my experience, the most frequent place that is overlooked by designers, is within the container structure of the design. Components are powerful building blocks and their behavior within the DOM is just as important to define as the data they hold.

‍

Knowing there are elements dedicated to handling layout behavior means we can define system components that accept layout rules from their parent container. Hugging the elements that hold component data within our system components allows for maximum flexibility.

‍

Organizing layout rules within a nested wrapper architecture is prescriptive — we know what we need to affect to achieve the functionality we’re after.

‍

Defining markup architecture: Card layout example

The container structure defines where styles are declared while being able to hold and properly render dynamic content.

‍

Case for integrating dev workflows into design foundations

Spacing, sizing, and direction rules need to be set on both sides of the workflow but how and were rules are set doesn’t need to mirrored in order to achieve the desired rule on either side.

‍

By using a layout model like you see above, we have a model for where rules, such as padding is applied to a surface component. Surface components, such as a card, may have different uses and hold different content but should retain consistent visual system patterns across a product.

‍

Knowing where to target when applying revisions, adding variants, or building new components is established for us. This helps prevent visual system conflicts and makes it easy to review and revise visual system rules across multiple components and component variants.

‍

problems this solves
  • Forward-looking
  • Standardized
  • Set it and forget it
1. card template

Two variants are defined for all cards — flat and elevated. While styles are defined for both, which styles are required is unique to the variant. Defining props for all variants in a single rule, even if they aren’t required for all variants, is part of setting up a styling cascade.

‍

“Basic Message” requirements declare that we need to use the Elevated variant

2. layout breakdown - body section

We’re using the card model to establish a layout. While the model gives us the outline for the card’s architecture, we still need to apply contextual rules as well as styling rules.

‍

  • Blue lines: Layout containers (Outer)
  • Red lines: Content containers (Inner)
  • Solid red: Shows padding (area between the outer and inner containers)

Because cards can have a single media item or a group of media items, rules for both are built into the component. The single item view is our base style and the multi item view inherits its rules and adds its own.

‍

Component styling is mostly additive. That means that a view, such as “Multi Item View” builds its rules in addition to the base rules. Again, this is the style cascade.

3. content views - body section

This shows content within the body section we have defined. The same blue and red lines show the outermost areas and the solid red section shows how padding is used within those containers.

‍

Layout styles aren’t defined within these views because the styles are defined, and inherited, in the layout rules we’ve already built.

‍

Layout properties, however, do need to be declared. These views show where the content sits within the layout containers and notes which content is required for each view.

Container breakdowns help designers as well.

Layout breakdowns help define where styles should be added.

  • Where is the best place to declare padding rules?
  • Does some, or all, content need to extend the full width of the container?
  • Is there a row of items that need to be spaced differently if different amounts of items are rendered in different instances?

These are common questions designers ask themselves. Matching the desired design direction against a layout breakdown helps designers see where to apply those rules.

layout

Rules for component layout rendering needs to be accounted for within your system.

‍

In my experience, the most frequent place that is overlooked by designers, is within the container structure of the design. Components are powerful building blocks and their behavior within the DOM is just as important to define as the data they hold.

‍

Knowing there are elements dedicated to handling layout behavior means we can define system components that accept layout rules from their parent container. Hugging the elements that hold component data within our system components allows for maximum flexibility.

‍

Organizing layout rules within a nested wrapper architecture is prescriptive — we know what we need to affect to achieve the functionality we’re after.

Defining markup architecture: Card layout example

The container structure defines where styles are declared while being able to hold and properly render dynamic content.

‍

Case for integrating dev workflows into design foundations

Spacing, sizing, and direction rules need to be set on both sides of the workflow but how and were rules are set doesn’t need to mirrored in order to achieve the desired rule on either side.

‍

By using a layout model like you see above, we have a model for where rules, such as padding is applied to a surface component. Surface components, such as a card, may have different uses and hold different content but should retain consistent visual system patterns across a product.

‍

Knowing where to target when applying revisions, adding variants, or building new components is established for us. This helps prevent visual system conflicts and makes it easy to review and revise visual system rules across multiple components and component variants.

‍

problems this solves
  • Forward-looking
  • Standardized
  • Set it and forget it

Building a “Basic Message Card” components with this model.

This is a simplified example that illustrates how to work with the layout breakdown above. This card accommodates different media types and both primary and secondary action menus.

basic message card

We’re creating two variants: Default and Disclaimer. The required components show which components and content blocks (defined elsewhere) are required to build the entire component. As we build both unique variants, we’ll show which requirements need to be pulled in.

1. card template

Two variants are defined for all cards — flat and elevated. While styles are defined for both, which styles are required is unique to the variant. Defining props for all variants in a single rule, even if they aren’t required for all variants, is part of setting up a styling cascade.

‍

“Basic Message” requirements declare that we need to use the Elevated variant

2. layout breakdown - body section

We’re using the card model to establish a layout. While the model gives us the outline for the card’s architecture, we still need to apply contextual rules as well as styling rules.

‍

  • Blue lines: Layout containers (Outer)
  • Red lines: Content containers (Inner)
  • Solid red: Shows padding (area between the outer and inner containers)

Because cards can have a single media item or a group of media items, rules for both are built into the component. The single item view is our base style and the multi item view inherits its rules and adds its own.

‍

Component styling is mostly additive. That means that a view, such as “Multi Item View” builds its rules in addition to the base rules. Again, this is the style cascade.

3. content views - body section

This shows content within the body section we have defined. The same blue and red lines show the outermost areas and the solid red section shows how padding is used within those containers.

‍

Layout styles aren’t defined within these views because the styles are defined, and inherited, in the layout rules we’ve already built.

‍

Layout properties, however, do need to be declared. These views show where the content sits within the layout containers and notes which content is required for each view.

4. content views - footer & disclaimer sections

Just as with the body sections, the footer and disclaimer sections show contextual examples of their respective sections along with the components required to build these sections.

Layout templates.

Components are placed within templates following the Atomic Design model. The layout architecture defined above means that the component's outermost container safely "wraps" the component and allows the template to control its own layout rules without requiring us to dive into the component(s) in the template layout to edit and set properties.

Page templates.

While not shown here, page templates hold layout templates and are what makes the entire layout come together. Dividing and assigning layout requirements within a logical and leveled method means we can rapidly build layouts.

layout

Rules for component layout rendering needs to be accounted for within your system.

‍

In my experience, the most frequent place that is overlooked by designers, is within the container structure of the design. Components are powerful building blocks and their behavior within the DOM is just as important to define as the data they hold.

‍

Knowing there are elements dedicated to handling layout behavior means we can define system components that accept layout rules from their parent container. Hugging the elements that hold component data within our system components allows for maximum flexibility.

‍

Organizing layout rules within a nested wrapper architecture is prescriptive — we know what we need to affect to achieve the functionality we’re after.

‍

‍

Defining markup architecture: Card layout example

The container structure defines where styles are declared while being able to hold and properly render dynamic content.

‍

Case for integrating dev workflows into design foundations

Spacing, sizing, and direction rules need to be set on both sides of the workflow but how and were rules are set doesn’t need to mirrored in order to achieve the desired rule on either side.

‍

By using a layout model like you see above, we have a model for where rules, such as padding is applied to a surface component. Surface components, such as a card, may have different uses and hold different content but should retain consistent visual system patterns across a product.

‍

Knowing where to target when applying revisions, adding variants, or building new components is established for us. This helps prevent visual system conflicts and makes it easy to review and revise visual system rules across multiple components and component variants.

‍

problems this solves
  • Forward-looking
  • Standardized
  • Set it and forget it

Building a “Basic Message Card” components with this model.

This is a simplified example that illustrates how to work with the layout breakdown above. This card accommodates different media types and both primary and secondary action menus.

basic message card

We’re creating two variants: Default and Disclaimer. The required components show which components and content blocks (defined elsewhere) are required to build the entire component. As we build both unique variants, we’ll show which requirements need to be pulled in.

Card layout documentation

This is a model used in Component Documentation that shows the nesting structure used for a card component. The naming convention applied here is part of a pattern I used across all components.

‍

wrapper

The outermost container which hugs all data.

‍

container

An internal container, of which there can be several, that hugs content.

‍

content (or content container)

This is where content is held.

‍

In most cases, wrapper and containers are establishing style rules between each other or within themselves and their children. A universal format gives us a guide to where and how to establish styles. Rules required could be spacing, colors, or other visual design elements. Even if there are no rules established, the layout architecture should be maintained.

Container breakdowns help designers as well.

Layout breakdowns help define where styles should be added.

  • Where is the best place to declare padding rules?
  • Does some, or all, content need to extend the full width of the container?
  • Is there a row of items that need to be spaced differently if different amounts of items are rendered in different instances?

These are common questions designers ask themselves. Matching the desired design direction against a layout breakdown helps designers see where to apply those rules.

1. card template

Two variants are defined for all cards — flat and elevated. While styles are defined for both, which styles are required is unique to the variant. Defining props for all variants in a single rule, even if they aren’t required for all variants, is part of setting up a styling cascade.

‍

“Basic Message” requirements declare that we need to use the Elevated variant

Layout templates.

Components are placed within templates following the Atomic Design model. The layout architecture defined above means that the component's outermost container safely "wraps" the component and allows the template to control its own layout rules without requiring us to dive into the component(s) in the template layout to edit and set properties.

layout

Rules for component layout rendering needs to be accounted for within your system.

‍

In my experience, the most frequent place that is overlooked by designers, is within the container structure of the design. Components are powerful building blocks and their behavior within the DOM is just as important to define as the data they hold.

‍

Knowing there are elements dedicated to handling layout behavior means we can define system components that accept layout rules from their parent container. Hugging the elements that hold component data within our system components allows for maximum flexibility.

‍

Organizing layout rules within a nested wrapper architecture is prescriptive — we know what we need to affect to achieve the functionality we’re after.

basic message card

We’re creating two variants: Default and Disclaimer. The required components show which components and content blocks (defined elsewhere) are required to build the entire component. As we build both unique variants, we’ll show which requirements need to be pulled in.

layout

Rules for component layout rendering needs to be accounted for within your system.

‍

In my experience, the most frequent place that is overlooked by designers, is within the container structure of the design. Components are powerful building blocks and their behavior within the DOM is just as important to define as the data they hold.

‍

Knowing there are elements dedicated to handling layout behavior means we can define system components that accept layout rules from their parent container. Hugging the elements that hold component data within our system components allows for maximum flexibility.

‍

Organizing layout rules within a nested wrapper architecture is prescriptive — we know what we need to affect to achieve the functionality we’re after.

Card layout documentation

This is a model used in Component Documentation that shows the nesting structure used for a card component. The naming convention applied here is part of a pattern I used across all components.

‍

wrapper

The outermost container which hugs all data.

‍

container

An internal container, of which there can be several, that hugs content.

‍

content (or content container)

This is where content is held.

‍

In most cases, wrapper and containers are establishing style rules between each other or within themselves and their children. A universal format gives us a guide to where and how to establish styles. Rules required could be spacing, colors, or other visual design elements. Even if there are no rules established, the layout architecture should be maintained.

Container breakdowns help designers as well.

Layout breakdowns help define where styles should be added.

  • Where is the best place to declare padding rules?
  • Does some, or all, content need to extend the full width of the container?
  • Is there a row of items that need to be spaced differently if different amounts of items are rendered in different instances?

These are common questions designers ask themselves. Matching the desired design direction against a layout breakdown helps designers see where to apply those rules.

Project Recap

‍

Building a box structure into the component areas within the design system has increased the handoff efficiency with every team I have worked with. The biggest challenge I have encountered is engineers cutting corners because the level of detail doesn’t seem necessary.

‍

Once the theory behind these rules is understood, development time speeds up significantly.

ALEXA I. STEFANOU
instagram icon that links to my instagram accountdribbble icon that links to my dribbble account linkedin icon that links to my linkedin account