There are at least two types of designers and front-end developers.
On the one hand, you have people who like to lay out elements freeform. This results in design-by-page and gives the greatest amount of freedom possible to the designer. A new designer will feel most comfortable with this workflow.
Other people advocate for a component-based design strategy. In a nutshell, a component is a design element used on more than one page. Rather than design pages, you design components. Thus, content editors build pages by arranging pre-designed components.
Freedom is good, right? We like the idea of freedom, and we usually conflate freedom with flexibility. If we have more freedom, we are more flexible.
In website design, we crave freedom to express ourselves. Freedom at this level creates design that is bound to content and context. This consequence may not be too bad for single page apps (SPAs) or smaller websites.
But as the complexity of the website grows, individual, art-directed page design leads to fragmentation and bad usability. The designer or front-end developer is too focused on full pages to consider how they relate to one another and how a user will comprehend them.
In some cases, it's hard to know if a design is too bound to context.
For example, a freeform designed element may have text overlaying an image. The text appears on the right side of the image because the image has a focus point in the left. This is a design element that is bound to content and is not flexible.
Other examples become obvious when considering design for content management systems. Drupal, Sitecore, WordPress, and all other CMSs have their own unique design constraints. If a design expects a specific number of elements or a specific field to display correctly, you know your design is inflexible.
All CMSs give content editors the ability to build pages, and designers should keep this in mind. The point here is to consider the editor as well as the end-user's perception of the design.
If we need to scale back freedom to gain some flexibility, what does that look like?
Once a content audit is complete, designers should have an idea of the types of content on a website. Designers and front-end developers should take a holistic view of the website to identify content patterns.
For a simplistic example, a component could have an image, a title, and some introductory text. This type of component could display an event, a blog post, a product, or any category of content. The component is consistent regardless of content. We provide the best usability for website visitors because appearance and functionality are unified across all pages.
To provide more context, the designer can add labels to the component that indicates content type or tagging. For example, show labels for a "Blog Post" categorized under "Design."
The designer should test the component for different contexts. Remove the image or the introductory text from the component. Place three components in a row or several in a column. Look for other ways to "break" your design to ensure flexibility for editors.
Furthermore, the CMS or website system should provide the necessary constraints to make the design work. Design should not rely on the editor's discretion (i.e. the editor's context) to create formatted content.
Freeform design, while rewarding from a design perspective, is usually not the best path for development. Pages will look great on their own as an isolated view. But when navigating through pages, users will face too large design variety. This leads to confusion and bad user experience.
Other problems emerge too.
Budgets rapidly expand. A site with 10 individually designed pages likely has hundreds of actual pages. A hyper focus on 10 page designs means a front-end developer has to grapple with blind spots. This leads to design iteration in the browser when you and your client are in the QA or UAT phase of development.
While creating their content, editors lose the ability to mentally preview their work. Large design diversity leads to confusion for editors and frustration from a sense of unpredictability in how their content will look.
Styles get applied to elements depending on their content or page. This leads to more work during front-end development, and again a budget expansion.
As the number of pages on the website grows, so does the number of individually designed pages. Lack of consistency and bad user experiences will result.
"Move that image up 3 pixels and make this text bold." Just say no to exceptions!
So, modular design fixes problems in freeform design and provides additional benefits too.
Design-by-component accounts for the editor's ability to be flexible with their content. An editor may want to show a list of blog posts without images, or she may want to lay out two events in a row instead of three. A design can be compelling even if a designer is not too controlling of a component's content.
Also, an infinite number of pages can be built by arranging pre-defined components. This is easier for an editor to think about, much simpler for a front-end developer to create, and less stressful on budget constraints.
Maximizing the use of components means greater code and functionality reuse too. Future maintainability is easier and cheaper for component designed websites.
Components broaden flexibility. For example, a contact page should not be exceptional as the only page that can have a map. Instead, create a map component that can be used on any page. The map component always appears and acts the same.
The Paragraphs module for Drupal makes designing components easy for the whole team!
Now that we've made the case against page-based design, how do we modularize our design?
First, we need a general idea of the types of content a website will showcase. An audit outlining the types of content and associated fields helps. Ideally your information architect or content strategist can get these requirements.
Next, wireframes are key to modularizing design. A wireframe is simply an information architecture tool divorced from design. The wireframe phase is the ideal time to create a component library because the focus is on content and not design.
Once you've created your component blueprints, a designer can create mockups for each component. Make sure to show examples for different scenarios. Consider components with or without imagery, different background colors, etc. The level of flexibility required was outlined in your content audit.
Finally, mockups for sample pages are created to show how these components layout with each other. At this phase, the designer is simply adding the components to page mockups. Care must be taken at this point to not provide exceptions at the page level. If an exception is found necessary, instead try to standardize it as an option across the site.
Traditional web design amounts to focusing on a subset of pages to design. The designer creates a few different versions of the same page and goes back and forth with the client to finalize the design. While rewarding and intuitive for the designer, the client has a larger budget to pay. This process also leaves front-end developers with more blindspots to reckon with later. Opening the door to page-driven design ramps up the budget for back-end developers too. As the client comes up with more ways to individualize pages, back-end developers need to allow them.
If clients wanted to design pages individually, they'd just use Dreamweaver (is that still a thing?). The content editor shouldn't be considering design on a page-basis. They should only need to think about their content. Specifically, the client should think about the components from their library that they need to create their page.
Modular design can still produce innovative and rewarding design. The focus is instead placed on reusable elements, user experience, and delivering on-budget. The result is an easily maintained website and greater degrees of flexibility.
View the discussion thread.
Tell us about your project