Come with us on a journey to the murky past, many years ago, when we first started building websites. Cold and tired, we huddled around our Photoshop comps and static templates, dreaming of a world to come where we could create websites with beautiful and flexible content strategies, design patterns, and build them using perfectly encapsulated modules. We imagined making gorgeous, dynamic websites that could be updated easily by a client when, as it inevitably does, there are shifts to content and the strategy. Clients would call us and say, “We want to put a new call to action on this page,” or, “We want to create a page for our newest initiative!” and we would respond, “Of course! You can do it all on your own, easily! Simply drag and drop!” And the client would look to the sky, sing our praises, and all would be well. World peace. 

But no. That's not how it was. Instead, we had to create rigid information architectures with static, pre-baked patterns that felt static to visitors as they navigated the site. We had to make sure that we got things right the first time because if we didn’t, we were locked in.

Over the years since those dark days, technology has changed, and now, we’re living in our utopia.

We’re creating fully modular websites with flexible web components that make our clients’ experiences so much better and give them a better product that can scale and grow with them and their needs while keeping quality design and content integrity. We don’t have world peace, but it’s a start.  

Here’s what you need to know about modular websites.
 

What are modular web components, and why do we use them?

To explain what modular web components are, let’s go back to that murky past. 

Back then, sites were been planned and designed using templates (and often they still are). The process went something like this: 

1. Come up with an information architecture that showed the site map — what pages the client needed. 

2. Next, create a content strategy that explains what would be on each template. Don't plan too many templates! If you want something different on a specific page, that would be a “one-off.” That means $$$. (Learn more about our approach to strategy.)

3. Design templates in Photoshop. 

4. Build a back-end content management system for each template.

5. Front-end developer translates the design comp into (hopefully) pixel-perfect HTML, CSS, and JavaScript.

As you navigate around the web, pay attention to how websites will often conspicuously have only a couple of templates and feel static. Yes, you might get beautiful new images and unique messages, but the patterns are all the same. 

The problem is that organizational needs change over time, and new requirements arise. So they would bolt in new features, add a new integration, throw in a new block of text, an alert, and before you knew it, they’d have a patched-together solution that was difficult for them to use (and messy to experience as a visitor). 

The problem is that organizational needs change over time, and new requirements arise.

Around 2010, we started to get new concepts in web design and development that were reacting to this state of affairs. Atomic Design was an idea that you could think about using small pieces of design and code, atoms, such as a color or a font. Together you combine atoms into molecules, such as a button. Then you had organisms, which were like calls to action, that were collections of molecules. The problem was that organisms collected into templates. It was a nice way to think, but it wasn’t a solution, ultimately. 

But technology was catching up. Those concepts translated into reality when products like SquareSpace came about in 2012, scaring agencies everywhere. They built a system that almost anyone could (and still can) use to create and alter a website to your heart’s content. They also worked in templates, but they were just starting points — you could drag and drop modular components (with limitations, of course), to customize your pages. However, unless you had a designer and developer, you were locked into their design. That was fine for many, but for larger organizations, and those that understand the importance of their brand story, it was an issue because it was easy to spot a SquareSpace site. They’re pretty generic. Many have rushed into this space, such as Wix and Weebly. They’re also not as customizable as you think, so don’t expect to have fine-tuned control over the layouts, UX, and details. 

But the development community was working hard at delivering new solutions and technologies for the enterprise. React came out in 2013 and Vue.js a year later. These were open-source frameworks that were based on the idea of encapsulated collections of code that made it relatively easy to use modular elements like Lego bricks. You still needed a separate CMS, however. 

Then big CMSs got into the game, with Drupal coming up with a solution first, and then WordPress and others. However, out of the box they weren’t easy to use and they weren’t adopted by many developers. With something like half of all websites in the world built with WordPress, we still have a ways to go. 

Once we saw the opportunity to build websites for our clients that could marry the early days of bespoke web with the new dynamic structure needed for the ever-changing needs of an organization, we haven't turned back.

Here’s why.
 

The Benefits of Modular Websites

When you build sites like this, you’re practicing encapsulation. That means that you can build with overarching design patterns, but you are isolating components so that if you change something, it doesn’t mess up the page. If a component breaks, it doesn’t break the site. Components are adopting rules for the site in general, but they’re not reliant on other components.

The Berkeley Lab website is one modular website project we did recently. It allowed us to have a separation of concerns, so that back-end developers could be working separately from front-end developers, and using handy tools, we had the ability to work quickly on isolated elements that all came together as a system. So there are big benefits for the development team to work this way. This saves time and money and lowers stress levels. Design can be iterative and we can be more innovative across the project. It takes some real effort, of course, to make sure that components can flow into each other from a design perspective, but that level of attention is important for a fully custom, branded website. 

The biggest benefits come for the client because what we deliver is infinitely flexible and easy to use. What they see in the back end is a native drag-and-drop interface. They can assemble a page using pulldown menus to select options for each modular component (such as backgrounds, colorways, orientation of images or text, and so on). Again, like playing with Lego bricks, and as we know, playing is more fun than working any day. 

The biggest benefits come for the client because what we deliver is infinitely flexible and easy to use.

What’s cool is that this extends the lifespan of a project. If later, the client needs a new modular component, we can build it and plug it into the system. We design the components to play well with each other, so that a text block looks good next to a CTA, for example. We can establish rules and work those into the system, like don’t use these two image components butted up against each other. 

If you update a component in the backend, the changes will cascade through all of the uses on the site. We can retire a component later if it’s not working. This kind of flexibility allows for us to think about websites as living organisms that can grow and adapt with an organization over time. 

The website visitor, the most important person, benefits because they get a more dynamic feeling site, something that feels constantly fresh and relevant. The site can deliver content faster and more nimbly than ever. 
 

So What’s Next?

We’re always looking to improve our process to be more efficient and provide a better experience for our clients, and nothing has come close to matching the potential of creating modular websites. We’re developing this approach in different CMS’s. We’ve done a lot in WordPress, including Berkeley Lab, and we built our new site in Drupal to see how we can do this across many platforms. We encourage everyone to take this approach and make the web easy to use for all. 

Take a look at our case studies for Oregon Community Foundation's website and Arizona Community Foundation's website, just two recent sites we did using modular features.