The construction industry is experiencing a revolution. Safe, sustainable skyscrapers are being built with unbelievable speed.

57 stories in 19 days.

Much of this incredible feat can be attributed to the vision of Chinese construction tycoon, Zhang Yue. Driven by environmentalism and a desire to provide safer buildings, Zhang hired architects and engineers to find a way to build safe, environmentally-friendly buildings quickly and economically.

The software development industry often draws inspiration from other industries. The same ideas that are revolutionizing architecture can be applied to how we build websites.

The Revolution will be Modular

Zhang Yue doesn’t construct buildings in the traditional way. Rather than gathering all the materials on-site and building in linear phases, 90% of the skyscraper is built in a factory. The pre-fabricated modules are shipped to the construction site and assembled like Legos.

The process was changed from linear to modular.

We can do the same thing with websites. 90% of a website can be built as a collection of pre-fabricated modules — a toolkit.

A Design System Emerges

Most websites already have this sort of systematic, modular feel even if not built with modularity in mind. Good web design seeks to help users by being consistent and predictable. Buttons, tabs, pop-ups, animations, etc. should look and feel like they are part of the same system. Each new part of the site should feel familiar. When you look at a well-designed app, it’s easy to identify these patterns.

Patterns in web design

The problem is we don’t always design or write code with this in mind. These design systems are often not 100% intentional — they emerge organically through the design process.

Many shops are adopting the concept of the “style guide” to help capture these design systems. Style guides do a great job of communicating the design language across a large site, or network of sites under a single brand. But, to make the most of a style guide, you need something more than just a communication tool — you need a living source of code from which your site can be built. You need a toolkit.

Tiny Bootstraps for every client.

Dave Rupert

Bootstrap is a great example of this in practice. It’s a toolkit of well-documented components that cover the requirements of many sites. It’s so widely adopted because it’s comprehensive and easy to use. The goal should be to build the same thing for your sites.

How to Get There

Here are five ways to apply this to your next project:

1. Root your process in collaboration

Modular construction requires collaboration between different disciplines. Architects, materials specialists, foremen, process engineers, etc. must all be engaged in the design process.

The intelligence of all relevant disciplines is used as collective inspiration and constraint.

Refabricating Architecture: How Manufacturing Methodologies are Poised to Transform Building Construction

The same is true of website construction. Developers, UX designers, strategists, and solution architects must all work together, during all phases of the project.

To state it practically: developers need to understand the UX and aesthetic themes, designers need to understand the constraints of the browser and the unseen (read: code) relationships between modules, and everyone needs to know the business problems the site is meant to solve.

Working together keeps expectations aligned, prevents surprises, and ultimately produces a better product faster.

2. Shift to thinking in modules

What does your content look like? What functionality do you need? Organize these things into smaller chunks (modules), and you’ll start to get a good picture of your scope.

Give each module its own lifecycle. Gather requirements, design, develop, and test at a per-module level, but with a mindfulness of how each module fits into the rest of the site.

Illustration of components treated individually

This is probably the hardest change for designers to adopt because it’s at odds with how most designers work. Design is a constant process of experimentation and refinement, usually done at a macro level. Designers like to see the whole canvas, not just one small part. The modular approach requires designers to think at both macro and micro levels.

3. Divide and conquer

Modularity is the key to scaling your team.

When I work on a toolkit-driven project, I act as the lead engineer, breaking down and distributing work to other developers. When work is complete, they submit a pull request, and I review the code, ensuring it aligns with the rest of the codebase. After a little back and forth, the code is merged and our toolkit grows. As team members become more fluent with the design and code, this process becomes more and more compact. Even a team of junior engineers can contribute in meaningful ways.

This is especially helpful in an agency environment when resource allocation is a huge variable. Large projects can run smoothly with only a single dedicated resource (per discipline).

4. Move quickly, reduce waste

According to Broad’s numbers, a traditional high-rise will produce about 3,000 tons of construction waste, while a Broad building will produce only 25 tons.


This is where the metaphor with building construction breaks down. You can’t move a factory to production without months and months of careful planning. Building a website is a much more forgiving endeavor. You can start writing code with little or no design or requirements. Change and iteration are cheap and quick (relatively).

Focus on getting your MVM (minimally viable module) in the browser as quickly as possible. Don’t spend too much time refining a design outside the browser where you’re prone to false assumptions. Getting your module in the browser allows you to interact with it. To test it. To see how it feels. You’ll make move meaningful refinements, you’ll gain a lot of momentum, and you’ll waste less time and money.

Illustration of component states, from abstract to concrete

Remember, that your final product, a website, is code. Every artifact you produce — sketches, wireframes, PSDs — that isn’t part of the final product, is like construction waste. It’s necessary, but should be kept to minimum

5. Be useful immediately

Remove every barrier to usefulness.

Infrastructure dependencies are barriers to usefulness. Keep your codebase small and portable. Things like server-side runtime environments and databases can make it difficult to move your toolkit around.

Lack of information is a barrier to usefulness. Provide comprehensive and meaningful documentation that helps people understand the design system and how to use it.

Extra steps are barriers to usefulness. A developer should be able to drop a toolkit (.css and .js) onto a page and have access to all the modules in the toolkit. No extra initialization steps. No need to load specific files. It should just work.

Fabricating Websites

At Dynamit, we’ve started to build this way, and we use an open source tool I started called Fabricator to drive that process. It’s a style guide generator, documentation tool, local development environment, and build tool rolled into one.

Fabricator comes with very few code conventions or opinions, which makes it flexible and easy for developers work with.

It is totally geared toward a modular style of development. It includes libraries that enable developers to write stylesheets, JavaScript, and HTML as modules.

It has a build system that compiles and optimizes code. In addition to the CSS, JavaScript, and image assets, it generates a static HTML site that can be used by other developers as a documentation reference. There’s no back-end language or database involved, so it can be deployed anywhere.

My favorite aspect of Fabricator is that it’s designed to make prototyping and iteration in the browser a very quick, efficient process. As a developer, I can quickly spin up my local instance, make changes to the code, and see those changes reflected immediately in the browser without refreshing the page. I can also share the site with a designer across the room, or across the country, and they’ll see the same live updates to the code as they happen. It’s the perfect tool to facilitate a developer-design jam session.

In Conclusion

Style guides have become the buzzword of buzzwords with new articles, books, and talks coming out all the time. They even have their own podcast. We love them, but don’t mistake having a style guide for having a useful tool that will help you execute your style guide’s vision. For that, you need something more. You need a more complete UI toolkit and you need to adopt a modular approach to execution.

There’s a tremendous amount of value in taking this approach. It allows us to do more with less, and to do it more quickly.

Webinar: The Impact of Accessibility