It’s a collaborative process involving designers, technical leads, quality assurance specialists, and content authors working together through critical discussion points and strategies to develop a functional, sustainable platform. This process will go through the initial design system, the right questions and assumptions, implementation and communication, and ultimately exposing the design elements to the content team. And it all starts with design.

It’s the job of the technical lead role to gather and communicate requirements to a team of developers. Technical leads don’t write the code, they design the system. When gathering details about a design system from a designer or design team, some details should be discussed before any development begins. Effectively communicating the right requirements for that system is the first defense your team has against changes in scope.

An important first step in development is breaking down a project into manageable pieces and then creating tasks that complete those pieces in a way that ensures those pieces all work together at the end, and a design system is no different.

• Scaffolding system — This can be a full set of pre-built components such as AEM (Adobe Experience Manager) Core Components or Bootstrap, a standard grid system, or a set of base units.
• Shared vocabulary — Discussing the core scaffolding also has the added benefit of getting the design and development teams a baseline set of rules and vocabulary for the system.
• Technology stack — Choosing a technology stack to develop with as well as talking through critical structural elements before any front-end development can be discussed.

With those pieces decided, there are three design features that are essential to the process. These considerations are the touchstone of any design process and will ultimately serve as the building blocks for the content team. 

A breakpoint is the screen size that the layout of a webpage adjusts for different devices. The team will need to agree on which breakpoints to target. Some things to look out for with breakpoints:A breakpoint is the screen size that the layout of a webpage adjusts for different devices. The team will need to agree on which breakpoints to target. Some things to look out for with breakpoints:

• Designs are often provided in desktop and mobile views which usually flips at 768px.
• Developers and designers should understand there will need to be a middle breakpoint to support small laptop and tablet screens.
• There are often two breakpoints that need to be added, one for tiny screens of 480px or less, and very wide screens of 1440px or greater. While these breakpoints are not used often, having them available to make small adjustments to spacing and sizing can save headaches during the exhaustive testing cycle toward the end of the project.  

Grid columns are vertical spaces in a website design where components can be placed and arranged. Components are self-contained and repeatable pieces of user interface (UI) or functionality. When designing gird columns, consider the following:

• Both designers and developers need to understand that grid columns have variable widths and will change across different screen sizes, whereas the gutter width between columns is a hard pixel value.
• If the components line up on a columnar grid, will they use the usual 12 columns and how wide will the gutters (spaces between the grid columns) be? This sets the expectation that a container which takes up 3 columns on a wide screen will need take up 6 columns on wide tablets and all 12 columns on a mobile screen to preserve the same look and feel.
• The team should establish which common elements in the designs will be used throughout such as: calls to action (CTAs), expandable panels, form fields, typography styles, and icons.

Extracting all versions of these common elements and building them out early in the project allows developers to compose complex components more easily as the project goes on. Having a pool of common elements also allows a set of conventions to be agreed upon so that if a design element breaks with the conventions, it is done with purpose and not as an oversight.

Agreeing on which components will be available across colours and themes is necessary for accurately scoping out the styling tasks.

• Themes are often broken into light and dark, though an accent theme may also be available.
• Colours can be stored as variables, which is useful for maintaining continuity and are especially helpful if the website needs to be rebranded or extended for any new brands or campaigns.

Even with all the core design concepts discussed and agreed upon, ambiguity will continue to come up as designs become a website. When you review the developed components at screen sizes between the designed widths or with different text, image, or video content and things start to look broken it is safe to assume that some specific adjustments need to be made.

In the preliminary stages of a project, the best step forward would be visually displaying the issue to the designer during a meeting, explaining what the cause of this issue is, and working with them to produce a solution. Having a few potential fixes in your belt and applying them live during the meeting can save a day of turning around updated designs. This has the added benefit of building a trusted relationship between the design and development teams, so long as there are no hard feelings when a proposed fix does not work out for one reason or another.

The number of assumptions that can safely be made about designed components usually goes up as a project progresses. As more design work is developed similar cases can use the same solution — and developers should be able to propose solutions that align with the designer team’s intentions as they spend more time solving problems together.

As components and structure come together it is important to keep the lines of communication open between the development and design teams. When your first components are ready to be demonstrated to the wider team, show them what the component looks like across a few form factors and with varying content. Discuss any specifics that were missing in the designs and what decisions were made by the team to resolve those missing pieces. This has three benefits:

1. The development team will know how to tackle similar issues if they come up during the project.
2. The quality assurance team will know not to flag these differences between design and live site as issues during their testing.
3. The design team gains insight into the specific conditions that their designed components may be put through which can help design future components and features.

The last step toward making a design system into a developed platform is to expose the underlying design elements to the content team. The team responsible for building out the content should understand the ins and outs of how the design system works in their authoring environment. For example:

• If the colour of CTAs can be adjusted independently of the overall component theme, then the content authors should know how the colours are expected to be used together.
• Some components may support background images with others using them inline.
• Images with text should not be used as background images since the text may be cropped and alternative text will not be available.

These intricacies should be captured in the documentation, but a live demo from the team that designed and developed the platform is especially helpful when fielding any questions about the system.

With design and development teams working closely together, they collectively design a stronger platform than either could on their own. If a designed system is converted clearly into code with intention, then building out new components that match the overall look and feel of the rest of the site can be easily accomplished.

Ready to get started on your own platform? Reach out to our experts to take your idea from design to development.