As someone who creates and implements designs for nonprofit organizations, I have learned a lot of ways to keep costs down. There are many little tips and tricks, like leveraging open source software, free fonts, and creative commons stock photos. But the most comprehensive way I’ve found to both meet client needs, keep project costs down, and avoid headaches is by using what we call Component-based Design.
In the past, graphic designers have approached website design in ways that can be inflexible and unforgiving — designing too many comps, designing for mobile as an afterthought, not using design patterns and repeatable elements, and creating redundant style documents. Luckily that is changing, and we are applying some lessons from the agile software development world to site graphic design.
Old-school design deliverables are analogous to waterfall project management style. Designers create full-page comps in their silos, and say “Ta-da!” when they are done. These designs will still need revisions, which may be painful now that the full page designs are complete. Component-based deliverables, however, are agile: they can be reviewed in stages and the rejection of one component won’t hold back the rest of the work.
Component-based design also works with the agile concept of a minimum viable product — where a shop can deliver a styleguide with the most important components designed — and less important components can be an enhanced feature, only delivered if time and money allows.
First, let’s define what we mean by “component.” Components are self-contained groups of elements, an element being a single item in a design, like a title, an icon, or an image. So a component might be a header, a sign-up box, a teaser, a hero image with overlay text, a list of related content, or a twitter feed. A component tends to also be reused across many (or all) pages of the site.
In the past, deliverables for site design might be a mockup of the homepage and select internal pages. The deliverables with component-based design are broken up into more manageable chunks, to lessen the chance of wasting too much time headed down the wrong path.
The first deliverable is a Style Tile. A style tile is a design document that illustrates the colors, fonts, icon treatments, button styles, image treatments and white space/line space. It gives a very high level look at what the site will look like. It is the site’s look and feel, in very broad strokes.
A designer can create a style tile in a fraction of the time of a comp, so it’s a quick way to throw some ideas out there and get the client talking about what they like and dislike. Often, elements from different style tiles will work their way into the final design.
This deliverable can sometimes be tricky because clients may mistake this for what a page might look like, so be sure to be as clear as possible about the feedback you need on this. You might accidentally get feedback on layout or even content, which is not helpful at this stage.
The next deliverables are the Style Guide and Component Library. Here we start applying the styles from the Style Tiles to different components that will be on the final site (most likely coming from wireframes.) The Style Guide is generally the simple text styles — like how titles, links and lists look. The Component Library is literally a list of components. Some designers will list even list them horizontally on the page (a very wide page) to discourage clients from trying to evaluate it as if it were a full page comp. I usually do mobile component versions first, working my way up to a wide version last.
At this point, you will begin to see patterns emerging that can be reused throughout your design. Finding these patterns will not only make the front end developers’ lives easier during implementation, but will provide a visual consistency, one that will carry through all the way to the content creation phase.
With no library of component styles, the freedom of being able to add ANYTHING can end up being more work (with patchwork results and a loss of cohesion) – and it is harder to maintain. Content creators should not have to worry about design at all.
A component is considered modular if it can be reused, sometimes in different places on the page, with different text and images, and sometimes with varied style (for instance, with different colors or other appearance differences.)
Modularity is important when we think of ways to simplify the design of the site. How can you reuse a design pattern? An image style? Strip down all the chunks of content you will need until you have a versatile yet concise set of core component styles to choose from. Being able to reuse component styles will not only save money, but will bring cohesion and clarity to the design.
Lastly, perhaps in spite of everything I have said so far, make Comps. Throw all the components on a mock-up for the client to see (I will often just do a homepage and one or two internal pages, with a small and large version). While this step technically isn’t necessary, it feels really gratifying to see how things fit together, and you may catch mistakes when you see things laid out together as they will on the site.
Of course, all of this only works if you have buy-in from the client. Clients need to be educated on why so many of the initial deliverables won’t look like the final product — or even resemble a website at all. But once they are on board, they will be delighted to find how much more satisfied they are with the final product, and all within their budget.
Also, be sure to check out slides from our recent presentation on component-based design:
Lego graphics courtesy of jon trillana at The Noun Project.