We built a system to help us more efficiently organize and use design assets and code across sites that share these elements.

We often create and tie together multiple websites, building what feels like a single site to its end user. Doing this makes our projects easier to maintain, allows us to develop in an extremely agile manner, and gives us the freedom to use the technology that best suits each task.

For instance, we built a number separate sites for OpenAerialMap, a tool that provides humanitarians with satellite and drone imagery. We built a separate site for the imagery browser, the data uploader form, and the documentation, just to name a few. Building a site for each of these facets allowed us not only to select the tech stack that best fit the needs of the project, but also prevented us from building a monolith app whose maintenance would be complicated. However, maintaining a consistent design language and interactions across all of them became a real challenge.

We found ourselves copying and pasting code between sites, creating a codebase that was hard to maintain. To cope with this we built Design System, a centralized module to contain all shared elements across sites.

These are all separate websites, but we manage the design and user interactions in one place.Design System

Building on the approach we took for Collecticons, and drawing further inspiration from Foundation, Bootstrap, and this great article by Salesforce, we used methods for distributing code through a package manager, e.g. node package manager (NPM) or Ruby Gems. This allowed us to take all of our shared elements across sites, and turn them into an installable node module that can be included in each website that makes up a project. The three main elements that make up the Design System are:

• scripts that can be included like any node module;
• styles that can be loaded as a whole or as individual components and;
• images which are common throughout the ecosystem and include logos and other branding elements.

Instead of copying and pasting code across websites, using node packages let us store all shared elements in one place and make those elements easily accessible and readily available to each and every site. For example, if we wanted to update the logo, we’d only have to change it in one place for it to be automatically updated on all other sites the next time they build.

Finally, having one repository for all shared elements, allows codebases to be more easily maintained and standardized, helping developers get started on new products, which is especially important for open source projects.

Although we’re still testing out this approach, using OAM, we think having a centralized design system, like the one we’ve shown here, is a great solution for complex and/or open source projects. Want to help? Give the Design System a try and send any suggestions or recommendations our way. We’re always looking to improve our workflow. A quick look at the docs is all that’s needed to start building. For more tech-savvy users, an example of its usage can be found in the OAM Docs gulpfile.