The philosophy of component-based design: how we work at Loud&Clear

The dawn of component-based design may very well be the future of the web.

All signs point to that being the case given the growing number of front-end frameworks that support components. But it’s one thing to technically work in toolsets to create components and put them all together — it’s another thing entirely to work holistically across multiple disciplines in a way that actually takes advantage of a component-based philosophy.

At full-service agencies like here at Loud&Clear, it can be tempting to think of component-based design as simply puzzle pieces that fit together to create a nice-looking experience. Instead, component-based design is simply the end-product of a comprehensive approach adopted by different groups working together to communicate information.

Component-based design won’t fix anything if your working philosophy is faulty or if design, UX and development aren’t working together — achieving success with component-based design is simply an outcome of doing things the right way.

So how has component-based design helped us here?

You need to get into a user’s mindset

Before any type of work begins, agencies need to ask what component-based design means for the end user. At Loud&Clear, we think this is pretty simple — components breed repeatability, usability, and a consistent experience.

Repeatability, for us, is key. If we can standardise the way in which in contact is formatted, it becomes recognisable and easy to teach. From an end-user perspective, that’s all that matters — getting them information in the best way possible. Component-based design is essentially a new type of language for communicating information to the user.

Speed is everything

Above everything else, using component-based design at Loud&Clear has allowed to use move rapidly with deployments that takes weeks and months, not years as they once might have. It helps us respond to opportunities and challenges rapidly and flexibly.

We test pages all the time, but using component-based design has allowed us to test one page and then use the learnings from that particular test and imprint them on the rest of the website.

Traditionally, insight gained during testing for a page would specifically be used for that page and nothing else. The powerful abilities of component-based design lets us speed up that learning and implementation process.

The way we build components is to essentially use sub-components, that roll up into other components, that themselves roll into templates. With that design approach we can be confident that if we test each individual component, they will be rolled into something that has been thoroughly vetted and applicable to multiple pages.

Another aspect of speed, apart from testing, is collaboration. We can give developers in our Ukraine or Russian offices very specific components and guidelines, and it works extremely well. We’ve reduced some of the dependency overheads that can plague global delivery teams.

Another key aspect of the speed element is mobile development. We often talk about developing for mobile first in this industry, but rather than mobile-first a component-based design philosophy allows for a truly cross-channel approach to content and interactivity.

When you’ve got the ability to test delivery of content across components, mobile simply becomes another channel of that development process. It gives us far more flexibility in testing rather than doing everything separately.

Component-based coding

The key we keep coming back to with component design is dependability — each area of the business is able to work by the same set of rules. In the case of front and back-end development, working with components creates structured processes.

It used to be that developers were given a page, and they would have to make individual decisions about how to cut that page and make changes. Many of those changes would have to be duplicated based on user testing across multiple pages — now design and development work together in actually implementing what we learn.

We saw this at work during a recent project with AGL. We conducted an audit of components that comprised various pages for a digital transformation project. During that audit we were able to identify nearly 60 components across those pages. We were able to significantly reduce that number to simplify each page while still achieving the best experience for the user.

By using this process, we can leap-frog in development. Traditionally design might start with a home page and go from there, but by using components we can start building up pages and “unlock” them as development continues. The home page might be finished on the final day of the project — but as long as the components themselves comprising those pages are ready to go, the order in which those pages are built doesn’t matter. This is a huge efficiency gain.

The future of component-based design

Component-based design isn’t a substitute for good design aesthetic. It can’t replace creativity. But it does, with the right touch, enable multiple areas of an agency to work together quicker to achieve the ultimate goal: giving users the right information in the best way possible.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.