Our team has been very focused on building systems rather than styling every element on a site with custom pixel perfect css. We break the site design into modules and then build out and style each module. Sections of pages that look/function the same or even similar we group them into a single module. Then, we put the modules back together in proper page layouts and they all come together as a cohesive website. Much like a kit of parts mindset we’re looking at making the parts for the system and then the system becomes very flexible.
When we create these modules for use on a site, one of the trickiest tasks in connection to creating it, is naming it. It’s tempting to name things by what they look like or what elements they contain or by what function they fill. We’ve found though, that names that are too functional or literal or tied to the content don’t do justice to the module because, it ends up building in a prejudice and limiting the flexibility and use of this module.
Naming should reflect the main function of the module and nothing more if it can be helped. It should not reflect the style, since as we should all know, the style of any element can be changed, sometimes drastically. A certain module may have a background image or color in multiple instances, but who’s to say it always will? We’ve even begun building in options and templates into our modules to help set expectations.
Once the team gets used to using a “billboard” module, we’ll naturally begin using it in our communication in the project, and then when the next project comes along, it’s natural to pick up where we left off and take all we’ve learned as a group about that module, tweaking as needed for the new project, and we’re pretty far down the road already. We continue to speak in terms of modules and use the terminology or naming conventions that make sense to the team at the time. Though, admittedly, a module may change for a different requirement or design in the new project, and that’s ok. This library of modules must keep in mind that the modules are flexible entities, once they are defined in a specific style guide they become more defined.
Using this method for a few sites you’ll certainly see that many sites do indeed have some of the same design patterns. Most sites tend to have some very similar modules in use, so why not make these modules universal in your team’s workflow. Adding every module to a module library allows us to pick and choose modules for each new project, and when needed, we can simply create a new module for a specific use that doesn’t yet exist and then in turn add it to our library. This module library is very much like a pattern library, it defines the patterns we use to create sites as well as how we talk about creating sites. It is a new struggle to continue to think abstractly enough to pick a previously used module and tweak it slightly for a new project, we have to continuously rethink requirements and functionality. One great part about this library is that these modules that have been created have already been tested and run through our QA process, so we know that they work and that they’ve been successful on numerous sites. While we continue to test and improve them, we already trust them a great deal. We’re continuing to work on our pattern library though. Documentation is a lot of work, but has a huge payoff. We’re going so far as to create a module gallery that includes examples of where these modules have been used previously, display any design requirements, html and css options as well as any scripts that may accompany the module. This helps our whole team to see the modules in real world examples and renderings (on desktop and mobile) as well as the nitty gritty details about each one too. We even added some extra functionality to let us filter the gallery to narrow down what is displayed so we can get pretty granular. It’s helping us to see all the similarities of these modules, but also the differences, and that each site has it’s own look and feel, but shares a good bit of functionality.
So, have fun naming your modules and try not to box yourself in with whatever name you settle on. And revisit the modules as you use them and find the ones that make sense to keep around for other projects. It can really change the way you talk about building in your team (for the better).