Automated Pattern Libraries for Complex Web Design Projects
Earlier this year, we put out a poll to gather some quick insights on how design teams use and maintain their pattern libraries. The question asked was:
How do you develop and maintain your UI style guides / pattern libraries within your team or organization?
58% of the respondents stated they update and maintain their UI pattern libraries manually. This seemed high (even if it was a quick poll) and went against our own thoughts and approach on the subject. We thought automation would be the status-quo for most.
That’s not to say teams who maintain design systems manually do not have an effective process in place. Yet, our experiences working with teams at start-ups through to global organizations tend to suggest otherwise. More so, when dealing with design systems that change regularly. As such, we find that despite best intentions and efforts, workflows put in place are too often idealistic. The pattern library gets treated as a static document while reliant on designers / developers having to retrospectively update it. Not only can it be time and resource intensive to do so, but over time the pattern library gets relegated in the design process and sidelined.
But why generate a pattern library?
A pattern library is a collection of reusable and maintainable design patterns, often tailored towards the specific needs of a client. When done right, it can help promote consistent experiences and be of great benefit to a design team and organization.
But, rarely do we sell design systems let alone mention pattern libraries to clients, unless a brief explicitly asks for a unified design system. Rather, our goal is to first and foremost solve the particular challenges a client faces. Meaning, the design system is almost always a natural consequence of the design process undertaken. And, the pattern library is just one part of our deliverable; an interactive and responsive prototype of the solution that satisfies business and user needs. Nevertheless, the pattern library is still key to help the design team integrate the proposed design system straight into their digital system.
Seamless pattern libraries
While there are many tools available, a tool alone does not guarantee success. It also requires a cultural shift in design thinking on the part of a client. Thus establishing the right workflow can take time, as attested to by the teams at GOV.UK and Lonely Planet. As such, the pattern library has to be seamless, complementing the workflow of a design team. This is where automation comes in.
A pattern library in our world is a single page that pulls in all modules from a dedicated folder. Whenever we complete the initial discovery phase (client and user research) we start building prototypes. With each prototype mimicking the real website as much as possible (minus a database), we ensure all links and pages behave as expected. Meaning, stakeholders have something tangible to review while users can perform usability testing at anytime. It too allows us to address any front-end performance issues in advance, before any database or server side implementations.
Most importantly, the prototypes help us to educate our clients. We get teams to think more in terms of designing and developing modules, rather than complete pages. After all, pages are just large containers consisting of many building blocks (modules). When you consider some modules can get referenced multiple times i.e. a navigation system, as well needing to be responsive, the idea of designing and developing reusable modules makes more sense.
As such, we work with design teams at all stages to create, design and iterate modules. These are all developed in HTML, CSS and/or JavaScript using semantic, accessible and robust markup. We’re then able to reuse components from any initial prototype(s) later on in the design process, should we need to. Whenever a repeatable object in the UI gets identified, it becomes a (parameterized) module pattern. And by working on and committing changes to modules the design team get to indirectly update the pattern library. This means it’s always kept up-to-date thus requiring little effort or resource thereafter.
File-system set-up
PHP is our go to language for implementing automated tasks or features. Even so, automation is possible using any server-side language. Just as long as the final output is semantic HTML. We have developed a simple file system framework for our own prototypes. A typical file-system structure includes:
- .htaccess file — redirects all URLs to the index file.
- Index file — all URLs are redirected to this file and then assembled by including the required layout, template and modules, in that exact order.
- [css] folder—contains any CSS related files — i.e. SASS files, presentational graphics as well as generated CSS files.
- [images] folder — contains all content images that can be subdivided into specific folders.
- [includes] folder — contains any file that cannot be qualified as a module, template or layout.
- [javascript] folder — contains JavaScript files, along with any pre-/post-processors if required.
- [layouts] folder — contains all layout files.
- [modules] folder — contains all module files.
- [templates] folder — contains all template files.
Three layers
Now that you have a better idea about our file-system organization, it’s time to explain the different layers. While other teams may specify more layers, we have found the following provides us with enough granularity and flexibility:
- Layouts
- Templates
- Modules
Layouts
Layouts contain common page elements such as the header, footer and sidebar, as well as layout-specific CSS and JS. We generally have three to four distinctive layouts in our projects and add more if required:
- Default layout — either a single or a multicolumn layout, whichever is the default for the project.
- Homepage layout — often distinctive from the default layout, thus requiring its own version.
- Focussed task layout — used for registration, log-in and/or checkout processes.
- Pseudo-modal layout — used instead of overlay modal windows; while pseudo-modals don’t feature a header or footer, they still need to be accessible to visually impaired users, therefore always contain basic navigation aids.
Templates
Each template has it’s own unique URL, for example http://prototype.dev/section/template. The template name and path is the actual parameter the index file uses to generate a page. In essence, templates are containers consisting of one or more modules. To test content and module scenarios we often create a separate file for each scenario. For instance, articles often vary in length and attached media, so we create templates to show each potential difference. If a project is more complex, we group templates into folders that represent website sections, categories or page types. Here’s an example setup for a content-driven website:
Modules
A module is a specific element that occurs two or more times in a design system. Each module contains precise descriptions and comments that get displayed via the pattern library. These are all written using markdown syntax, thus making it easier to identify and format them.
Unless we’ve already identified any repeatable elements, each element is first coded directly onto the page, without extracting it into a module. In other words, it’s still not a separate file at that point. Once another instance of that same element gets found, it’s then extracted into a separate file and moved to the modules folder. But before an element becomes a true module, we need to extract any content into a variable, so that the module remains fully parametrized:
<? // Check if the $related_news is specified beforeIf (!is_array($related_news)) {
// If not, use the generic list of news
$related_news = array(
‘Boosting Your Rates With Validated Principles’,
‘Content Security Policy, Your Future Best Friend’,
‘Reducing Cognitive Overload For A Better User Experience’,
);
}?><ul class=”related_news”>
<? foreach ($related_news as $news) { ?>
<li><a href=”#”><? echo $news ?></a></li>
<? } ?>
</ul>
The automated pattern library
As the prototype is programmatically controlled with requests passed via the index file, we are then able to create some handy tools:
- A list of links to all templates in the prototype — it is accessible on every page template while it also forms the basis of a navigation system. As we always place related template files together in the same sub-folders, the templates get organized and displayed according to the groupings. This improves the usability of the prototype especially when there is a large volume of assorted templates. Another useful feature is the ability to detect the presence of certain keywords in each template file. We use this feature to manage the development status for each template. For instance, DONE = (ready for revision), APPROVED = (signed-off) and WIP = (work-in-progress). By adding a respective class to each template navigation link we’re then able to clearly display the status of each template. This way everyone has a quick insight into the progress by looking at the template navigation.
- A list of modules — the pattern library is really just another template in the prototype. Instead of just consisting of a few module examples, it contains a full list of modules, generated automatically according to the contents of the modules folder. By following the link to a module’s dynamically generated page, it’s easy to preview and share each rendered module, its formatted explanation and auto-generated HTML code snippet. Furthermore, the script can also detect where in the prototype a module gets used as well as generate the links to the respective templates.
- Contextually grouped modules — considering some modules get used together (for instance form elements such as fields, checkboxes and buttons or body content elements such as subheads, paragraphs or lists) it makes sense to display them together in one combined module. Thus, we group related modules by either prefixing them with a keyword, i.e. form-, body-content- etc., or by creating new folders inside the module folder.
Conclusion: Reap benefits with automation
Our set-up not only enables us to deliver what the client requires in a structured manner, it helps the design team to get off the ground with the beginnings of a usable and maintainable pattern library. Some of the teams we’ve been working with who have benefited from adopting an automated pattern library include Croatian Telekom, Development Agency Zagreb and SGS SA.
Does that mean a client has to settle for our solution? Of course not. It’s fair to say that over time each organization will need to further refine and develop their workflow processes to suit their needs. What’s most important to us is that an organization is able to recognize that by making small adjustments to their design process thinking i.e. working with modules, they can achieve lasting and effective gains.
Want to learn more about how you can improve your digital project UX? Tin Kadoic and Marko Dugonjic are running a UX for Startups workshop in NYC on November 11, 2016.
Creative Nights is a UX design consultancy specialized in planning, designing and building fast and effective websites and digital products. Get in touch and join our list of happy clients or see us in action at one of our public workshops.
