Components over pages

The classic page-based approach

It was only natural for users browsing the web, and also for clients requesting a new website for their business, to think of websites in terms of pages.

People used to browse the different directories on their computers, going from folder to folder and jumping between files as they explore their data, and the web came to basically provide the same scheme of allowing people to access uploaded documents, just like they would have them on their local machines.

The same goes for clients. A business owner who wants to build a new website for his restaurant chain would care to provide whomever that is going to develop his website with the different pages that need to be present on the website.

"I need a products page where I can list the different products we offer. I also would like my website to have a friendly cart page that allows users to easily checkout and place their orders". The previous are the common statements you'd expect from someone who is asking for such a service, and he's correct as to the way he perceives the website in terms of pages that serve different purposes.

And the page-based approach makes sense, as it clearly dictates the purpose and functionality of each web page, where every page has a clear user flow and requirements that need to be met.

Design and development teams followed what seemed to be a successful process based on pages approach. Designers take in client input and create initial mock-ups in collaboration with the UX team. These mock-ups are then handed by the project manager to the development team after they have been divided into a number of tasks. 

The development team would start turning these designs into code by implementing these different mock-ups. Finally the Quality Assurance team makes sure that the design has served its purpose and is properly implemented by the developers.

Now when a change in design occurs, or if the client requests certain design updates, that process repeats.

That indeed seemed like a steady process, often called page-based design, but it came with certain flaws. A major flaw was the amount of duplicated work that was done across the different pages. Since every component in each page had to be implemented with certain considerations of the context around it, and often times these components would not behave as expected.

Even the traditional Content Management Systems (CMS) got their power from providing their customers with ready-made templates, for them to quickly build their next page of their website. Looking to build a portfolio? A CMS would allow you to choose from different templates made for portfolios, each with its own way of displaying things, but they all ultimately served the same purpose (and even looked the same to a decent extent)

Now, these templates were great, and saving time was their biggest merit. But what about the possibilities these templates provided? How would you scaffold a template after another without the feeling of boredom you would get when you use any cookie-cutting technique? What if you were looking to make a page for a very unique idea you just came up with, and you just couldn't find a template that fits your page specifications? Would you build it your own from scratch and just add it as a foreign page among the supposedly symmetric pages based on a template you've used? Or will you take the time to try and make it the closest you can get to its fellow pages of the template?

The above takes us to the conclusion that while designing and thinking of websites in terms of templates might seem like a time-saver and boosts efficiency, it is very limiting at the same time.

Thinking in components

So in order to cross the limitations barrier, one would think it's a good idea to ditch templates and start designing every page from scratch according to its own characteristics. This will certainly solve the boring pages problem and unlock unlimited possibilities when making your next website. But this already sounds like too much work, and is surely to be time consuming.

You are also susceptible to end up with a not very consistent website in the bigger picture. It would be hard to build a number of unique pages, each starting from scratch, and ensure that they will work well together and have a consistent look and feel if you let your imagination flow while designing every page.

To overcome these problems, one had to come up with a solution that strikes a balance between preserving efficiency and fostering uniqueness. Building consistent websites that also don't look boring, while staying efficient and saving time seems like a goal everyone would seek. Unlike thinking in pages and templates, thinking in terms of singular components adopts an inside-out pattern of looking at things.

Components here are the building blocks of the pages of the website. A component can be a button, an input field, or it could even be a more complex component like a navigation bar that consists of other smaller components.

This way of thinking in terms of modular components was first established by Brad Frost in his Atomic Design book. The book suggested breaking down pages and templates into their smallest elements, which when put together form a bigger element.

These components ultimately form the different pages of a given website or an application, when put together in accordance to specified guidelines that dictate the overall flow and connection of components in a website.

So a component-based approach would involve having the team decide on a number of components that address all the functionalities to be present in the website or product, and the designers create mock-ups of these components.

The developers can then build a component library and the QA team makes sure the implemented components match their original specifications as issued by designers and others taking part in the creation of these components.

This frees anyone working on the product from worrying too much about how individual components behave, their different states and their structure. Designers won't have to describe these components again to other team members, developers also no longer need to code core components, unless of course a new change in requirements calls for introducing such a component, and also the QA team doesn't have to test these components at their core level.

Now the team gets to focus on page functionality and other important detail at a higher level of the product which makes the overall process more efficient and essentially increases productivity, while ensuring consistency at the same time, since each of these components will be used based on common guidelines agreed to by the team.

These guidelines and the components, as well as other elements we'll talk about in detail in the coming chapters, make up what is called a Design System.

What gives components the edge

Going back to the problem of balancing efficiency and uniqueness, we find that these components have the following characteristics that allow them to be the perfect solution for this situation:

1. Components are reusable

This tackles the problem of wasting time building pages from scratch every time. Instead, you start with building and gathering all the possible components you may need for the website.

From that point, working on building a website should mainly resemble building a castle out of Lego blocks. You put these components together according to the way they fit a certain scenario -the scenario here could be a bigger component, a section of a page, or a full page as whole-, and based on certain guidelines that govern how these components should play together in relation to each other, and also in relation to the context they are present in.

2. Components offer consistency

The stage of building the components is also guided in compliance to a set of rules that define the main characteristics of these components. This ensures that the big picture will remain harmonious, and delivers a consistent outcome while avoiding the boring templates.

3. Components are unique in their own domain

Each design system is unique in its own sense. They are initially built with the several characteristics of the thing they are made for in mind. Starting from its purpose and business goals, to the target audience and the branding of the project. And since you get to put these components together in an abundance of ways, you unlock different possibilities that are yielded from each different combination.

These characteristics give the components approach an edge when it comes to building a website with the flexible consistency they add to the design process.