We design platforms and services—not pages and websites—so we approach frontend architecture as a system of robust, independent components.
A modular architecture involves breaking interfaces down into their component parts, and sharing that thought throughout a project, from strategy to design to code. By looking for re-usable interface patterns we strive to create scalable design systems, not fixed pictures of pages.
We’re not designing pages, we’re designing systems of components. Stephen Hay
There are numerous efforts to standardise an approach to modular user interfaces, from atoms, molecules and organisms; utilities, quarks, atoms and molecules; elements, collections, views and modules to base CSS frameworks and HTML pattern libraries.
We have settled on a simple naming convention:
Elements are the individual building blocks that make up a component. Think of them as individual HTML elements (
p etc.) or light interface pieces such as buttons, dividers, progress bars and labels.
To avoid conflicts and to improve the re-usability of HTML, when styling an item inside components it is strongly encouraged to use class selectors (over raw element selectors). This way you can swap the element semantics (such as heading hierarchy) without changing the element's style.
Components are the primary currency of any interface: headers, footers, navigation, promos, accordions, forms, tables, images and everything else in between:
A component should be designed with a fluid width so that it can be dropped in to any position on a template. Their dimensions should be relative to the container in which they are dropped, not relying on a specific layout or template for styling. Use elementQuery to add component-level tweakpoints.
Web designers will have to look beyond the layout in front of them to envision how its elements will reflow & lockup at various widths while maintaining form and hierarchy. Trent Walton
Templates are comprised of components arranged in a layout. Templates allow you to see components in context with a focus on content structure (character length, image sizes) and usually have names such as "Article", "Product" or "Category Listing".
Template markup should be as light as possible: global header/footer and container layout structure only. If you find yourself adding content directly into a template, consider refactoring this into a component.
A template's layout will usually be containers of rows and columns aligned to a grid. These re-size and re-order based on viewport size using media queries.
Pages are instances of templates. For example if an ecommerce site has 10 products, you have 10 product pages, all using the "Product" template. Linked together they allow you to see templates with real content and to review the design system as a whole. Pages should be presented in code, not as Omnigraffle or PSD comps.
Tiny Bootstraps, for every client. Dave Rupert
You are encouraged to render a single list of all components outside of the framework of a template. If you cannot, your components and templates are too tightly-coupled. Share these component libraries with the project team and the client.
Designers and prototypers on our team can use the components to rapidly create real, interactive deliverables. Salesforce
Note that a component library is subtly different from a pattern library. Elements and components are patterns in themselves, and we have found that atomic patterns are too granular for client review. Component libraries are less contrived and a better structure for presenting to clients.
This separation of design from layout that we achieve when we design at an atomic level is important because it helps everyone — the designer and their boss or client — focus on the details in a design while setting no expectations for how components will ultimately be arranged across various screen sizes or devices. Brad Frost
An example component library for Co-operative Funeralcare (repo):
Agree naming conventions for components as early as possible during the design phase. Give them memorable names, not reference numbers. Name components as to their purpose rather than the content they contain so that they are as re-usable as possible e.g. "teaser with image" rather than "product case study". Use these names throughout wireframes, comps and code.
Consider the concept of transclusion for modular content hierarchy across pages.
Start with base-level element styling (headings, paragraphs and lists), particularly the base paragraph size and line-height. All other type sizes will be relative to this, larger or smaller. Consider using a style tile. Bonus points for doing it in CSS.
Retain the semantic distinction between grid, column, container and layout. A layout is essentially a set of containers which are filled with components. You might be using a 12, 24 or 48 column grid, therefore the layout (container size) will span a multiple of grid columns. Try not to refer to these containers as "columns" (main column, right hand column) since container hierarchy will change at different screen sizes.
Early on in a project you should discuss what artefacts are relevant for client sign-off. Do we need full Photoshop comps, or will a style tile be sufficient for early agreement? Would the client prefer to review an evolving component library, or do they want to see a design system working with real content from the start? Will you need frontend assistance to develop these artefacts?
Start with a CSS reset and a style tile for base typography. Consider developing an "article" template first to get the basic typography correct. Each component might have its own typography rules but these should never be attached to templates or containers.
Use a responsive grid like Susy that provides mixins to provide widths for containers. As described above, use elementQuery for component tweakpoints and media queries for layout container breakpoints.