How to build better websites, faster.

This is the quest we — like addicts to the rubik’s cube — have repeated over and over again. And while there will never be one single solution there are winning strategies. We now packaged some of them into code and design for the Hubspot CMS.

Remember those long past days when websites were like trees and a “webmaster” had his hands in every branch — from design to raw HTML? Alberto Contreras and I have been amassing website-building rings since then. Our first joint startup, MSM Interactive, did website development only and was acquired in 2000 by Nurun and then by Publicis.

Since then we have been spending a significant amount of our time on application development across multiple startups. When InboundLabs became a HubSpot partner in 2014 we somewhat went back to our roots and together with our lead developer (Joe) and the contribution of countless other team members we have been on the quest for building better websites since then. Specifically on HubSpot.

The BRiX Framework allows users to creates better web sites — including shops, dashboards and other HubSpot CMS Apps — faster.

Love_and_Hate@HubSpot

Since becoming a HubSpot partner in 2014, we have implemented hundreds of web projects for HubSpot customers, as well as directly for HubSpot including the Code Gallery, BigLytics and Inspire. Back in the early days, the HubSpot CMS was still called the COS to differentiate from the Wordpress CMS and others. Despite the awkward attempt to differentiate as a “content optimization system,” we fell in love (in the way only geeks can) with the architecture of that platform. It seemed to have reusability imprinted in its DNA: the separation of layout from pages, display from logic and the modules early on allowed for some fun experimentation.

One thing Alberto as a designer, and I as a marketer (with some programming experience), always agreed on was that we hated templates. And this was amplified by HubSpot templates. The majority of HubSpot templates did (and still do!) suck, especially as the walled HubSpot Assets Marketplaces clearly lacks the depth and breadth of any of the open competitors like Envato or Template Monster.

But the problem of templates goes way beyond HubSpot.

A Pain in the Templates

In a world where content matters more than ever, templates force marketeers, writers, and editors into prebuilt narratives. Templated sites come off like a movie where the dialog was written after the movie was shot. Placing content on templates is a PITA and leads to bad storytelling. Experienced marketers hate templates.

Beyond the content troubles, most templates lack the design source files. At InboundLabs, we have worked with dozens of customers who have had to reverse engineer templates into design files so they could make changes to their sites. To do that effectively, you need a skilled designer (who, after such a project, will likely end up hating templates as well).

The developer then gets to change the code of a template by forcing the reverse engineered design back into the CSS. This process requires modifying usually undocumented, and often badly structured, code. It’s not surprising that the resulting “Frankensites” underperform in every aspect: from speed to responsiveness. But the real problem is the waste of a developer’s scarce time. That is why developers hate templates, too.

And all of that leads to compromised conversions, which are hated by sales team, business execs, and everyone in between (whether they know it all comes back to a template problem or not)

As a result, HubSpot marketers can identify a templated website with their eyes closed.

Solution v.1.0

In 2017, we tried to tackle a few of these problems and partnered with DesignModo to bring the Startup Framework to HubSpot. This partnership not only allowed us to save precious design and coding time, but more importantly we felt we were sharing important concepts: simplified reusability of components that makes it easy for marketers to assemble pages to tell their stories.

An idea we labeled “Pattern Driven Design” or “PDD”.

Thoughts on Pattern Driven Design revisited.

The concept of PDD is not new. Software Development has been reusing components for half a century. More recently, this reuse has extended from code into design and bridging the two calling it a Design System, like Google’s Material.io. These Designs Systems, as well as more theoretical approaches like Atomic Design, are all focused on better user interfaces for applications and high degrees of interactivity.

In our perspective, websites are different. While they might as well be considered “quasi-apps,” their primary objective is to deliver easy-to-consume “stories.” Users (in the western world) read them like pages in a book: left to right, top to bottom. Applications (think accounting, CRM, etc.) do not use that reading order. As a result, websites closely resemble comic books or a storyboard: picture by picture, block by block or “pattern per pattern.” Scroll down on any website and you see it: a hero section with big bold statements, customer testimonials, product features, etc.

Pattern Driven Design puts this storytelling at its core. Each chapter of a website story can be assembled with a pattern.

The Startup Framework for HubSpot has become one of the most installed HubSpot templates of all times.

We launched the Startup Framework for HubSpot as a template with design source files, 100+ patterns, and an app to build pages out of patterns with a simple drag and drop interface. The template has been downloaded several thousand times and the app has several thousand registered users making both the template and the app among the most installed assets in the HubSpot ecosystem today. We have heard a clear message from HubSpot customers: this is what we want!

Time for an Improvement

The Startup Framework had a several significant shortcomings:

The design source files were in layered photoshop files and — due to licensing agreements with DesignModo — only available in the paid version of SUF. This not only limited the designer through the obsolete file format (Photoshop sucks!) but also excluded value from the framework in order to sell an upgrade. As a result our customers had a hard time customizing the free and the paid versions.

The code we produced was a copy of the original DesignModo code. It was not created for HubSpot, it was only adapted to it. It was not built to extend beyond the pre-built modules and styles. We tortured our customers by putting their developers into the same confined space as all other template providers: guilty as charged.

HubSpot’s Custom Modules are a great invention. However, the fact that we had to create one Custom Module for every pattern and place them on pages with Flexible Columns had serious down sides. To start, removing any element, like a line of text or a button, required coding. Second, it created an exaggerated amount of custom modules that were hard to maintain, organize and understand. When customized, the websites built with the Startup Framework became unnecessarily complex.

Building a larger web site became a pain for our customers.

Supporting customers in this undertaking became a pain for us.

2.0 is Born

Then HubSpot’s release of Themes and Drag & Drop Areas set a clear sign of things to come. Our curiosity made us pick up the ball where we had left it. We embarked on a (somewhat over-)ambitious project. And we had to agree on its direction.

The first decision we made was to end the relationship with DesignModo. While we were very happy with their product, we ended up using obsolete features, design and code. Unfortunately, DesignModo decided to build a “walled garden” of their own with the subsequent product versions. A decision that made it impossible for us to keep using their product and a reflection of vision we do not share.

As a result, “Framework 2.0” was born because we wanted the old Framework to grow up and become Enterprise-ready.

Our primary objective of Framework 2.0 was to overcome some of the problems of the previous version, incorporate new learnings, and align with a culture of collaboration we have found to be the base of any successful company. And marketeer.

We wanted to maintain the focus on marketeers. We want to make it easy for marketeers to tell the stories they need to tell without the typical limitations of templates. This meant relying on prebuilt canvases (aka patterns) without compromising the ability to tailor them exactly to one’s needs. All while at the same time, allowing them to work with designers and developers seamlessly to implement them. They should be able to actively participate in the development process: implement and change pages without relying on anyone. We also wanted them to be able to request and add basic responsive behavior and effects without exploding their budgets.

We wanted to give designers the time to express their creative ideas instead of reverse engineering templates and reinventing the wheel (aka another customer testimony section). We want them to use (or learn!) the latest generation of design tools that not only save time but — due to their web-based nature — allow faster translation from design to code. It should be easy to adjust styles to the need of a specific company without starting over again. We want them to have a common language that facilitates the work with the marketeer and the developer by providing patterns that have the same names and properties.

For developers, we envisioned reusability paired with the highest degree of freedom to do their jobs. Similar to designers, the developers should have reusable patterns that can easily be modified. They should be able to communicate in the same common language with designers and marketeers. And because developers spend hundreds of hours trying to create coded carbon copies from designs, we need a better way to compare source designs with resulting web pages.

Finally we glanced hard at the future. And the future of the HubSpot CMS is “CMS Apps”. We firmly believe that today, having a website is not enough. Truly successful businesses do not just build websites, but focus on alternate modes of customer engagements and relationships. They build transformative, digital and meaningful relationships through web and mobile applications. A modern framework has to enable companies to do that.

We started building Framework 2.0 in 10 steps:

1. We reverse-engineered the HubSpot Boilerplate to create the designs in Figma.
2. We created a style guide that can be extended in an easy and coherent way.
3. We created a new skin (called “bluesteal”) to stress test new the style guide.
4. We forked the HubSpot Boilerplate and extended the fields.json to match the styles guide in Figma.
5. We developed a new version of our BRiX App that stores patterns as JSONs. A definition of a pattern being a combination of HubSpot Modules.
6. We added a JS into the BRiX Theme that allows us to run the app within the HubSpot Page Editor.
7. We broke all pages into patterns and added them to our library accessible via the BRiX App.
8. We implemented a Grid in BRiX App that allows to match the one in Figma that allows to compare Figma designs with HubSpot Pages
9. We added custom modules like authentication, shopping, and dashboard to use custom objects, server-less functions, memberships to the theme and library.
10. We took the BRiX theme and reduced it and put it on Github. We want to contribute back without making them dependent on our apps. If you want the apps simply use the the full HubSpot Theme.

This process resulted in the following assets:

• A HubSpot Theme with extended fields.json, additional modules and pages.
• An App that allows users to insert patterns for a Library and toggle the Grid.
• A Library of patterns with default modules as well as custom modules
• A Figma file with pages, patterns and skins that match the library and theme.

Now, because each of these parts plays an important role in the overall value proposition we are calling this the BRiX “Framework.” A way to build better websites and a great way to do scaffolding for CMS Apps.

HubSpot Adoption

We are very much aware that we have built features that HubSpot will provide natively sooner or later. This includes, specifically, skins and sub-themes, replications of sections, advanced modules with HubDB, custom objects, and server-less support. As these features become available, we will integrate them into the BRiX Framework and likely discontinue ours. It will allow us to focus on where we add the most value: increasing productivity of marketing teams.

With that, the future of the Framework lies one part in providing HubSpot customers and partners with a powerful, open source Design System to build websites and CMS apps; and one part in the creation of a specialized Design System Manager, the BRiX App that enables collaboration in marketing teams.

While developing the Framework we had the chance to start testing it with real life customer cases. Both projects, one a full website design and one a migration from Squarespace, seem to reduce overall implementation time by 40% or more. This factor is likely to grow with every pattern that is added to the library and publicly made available in the BRiX DSM.

If you are a HubSpot customer, a Hubspot partner or simply passionate about building a better web then install the BRiX Theme (starting Jan 2021!) and/or join our Slack Team (today!). You can also demos from here.