Many large companies struggle with a uniform user interface of their web presence. The larger a website, the more complex the maintenance of the user interface elements. Here the Pattern Library provides clarity and simplifies the ongoing additions to a website. In this post you’ll find out exactly what a pattern library is and when it makes sense to use it.
In complex web projects, you are usually part of a product team. Almost everyone who has been in this position can see how quickly chaos and confusion can creep in. From the first point of view, the chaos here results from the inconsistency of the user interface in combination with redundant code. Negative effects on the user experience are only one of the disadvantages. In addition, no speed (increasing efficiency in the workflow) can be taken up for future adjustments of the website – on the contrary. With the natural fluctuation of team members, it is inevitable that the same problems will be solved anew by other project participants. All this can be avoided with Pattern Libraries.
Write me if you want to outsource this process
What is a Pattern Library?
Ok, ok I admit it: Pattern Library sounds fancy, but what does that actually mean? Ultimately, it is nothing more than a collection of user interface elements. These elements solve recurring problems.
Pattern libraries are nested within each other. The specification of the specifications and the degree of nesting depends on the free space the brand would like to have in the future.
Ideally, each recurring element is displayed. Design + code + explanation and possible variations. Caution: I myself am a friend of good and careful documentation. But if you start with very detailed documentation, you run the risk that the library will no longer be maintained in the future. Quite simply because the maintenance effort of this is not related to the newly added element(s). This, of course, undermines the purpose of the library.
Why do I need a Pattern Library?
Improved user experience
A uniform user interface is maintained by a pattern library. This, in turn, has a positive effect on the user experience.
Long-term time and cost saving
The creation of a pattern library is initially associated with additional work. However, once the website has reached a certain complexity, you will benefit from time savings throughout the entire project. Sooner or later, this outweighs the initial effort. Already solved problems do not have to be solved again and again. There is a central location where all new and existing project participants can access. Which brings us to the next point…
Onboarding of new project participants
New project participants do not have to search for elements and templates together on the basis of the existing website, or even worse: rethink. Designers and programmers are provided with the Pattern Library. This provides a good overview of the project and the tonality (in terms of design and programming), which serves as an orientation for the expansion of the Pattern Library. If the solution requires elements that are not available in the Pattern Library, the respective elements can be extended. An additional point that must not be ignored: motivation. I myself am much more motivated to work in an orderly project structure than having to dig through the chaos every time. There is then a voice in the back of my mind that does not become quieter and constantly tells me: “All this can run much faster and more efficiently”.
Working through tasks and knowing that there are actually more elegant ways to implement these things is definitely a factor for demotivation. Not every product owner always has the time, resources and knowledge to tackle this right from the start – especially in fast-growing companies. This is often one of many struggles of a product manager. I am of the opinion that as a project participant one has the obligation to inform about abuses of this kind. In no case, one should devote oneself to a sub-optimal workflow. That you are “new” to the team or because “it has always been done this way” are also no reasons for it. One should point out what is wrong and where resources are wasted. But please only do if you can provide realistic solutions to the problems described.
Redundant code is avoided. The danger of duplicating the same or almost identical elements is gone.
More time for iterations and A / B testing
The time saved by modular working with the Pattern Library can be put into further iterations and A/B testing.
Write me if you want professional help
How and where to start a pattern library?
We have now learned that a pattern library solves a recurring problem in the form of UI elements. A good pattern library has the following features:
Description of the problem
A solution of the problem in the form of user interface element(s) and the corresponding code
A brief explanation of the solution chosen
A good balancing act between a manageable initial effort and completeness is to always cover the basic elements first. The library is slim in the beginning and is gradually expanded with new problem definitions of the user stories. No-brainer! Make sure that elements also have the permission to be included in the Pattern Library. That means, among other things:
The problem to be solved will occur more frequently in the future
Cannot be combined with the existing, or a variation of the existing
Otherwise, the library inflates with elements that are only used 1-2 times.
Different teams can contribute to the library
Once the library’s policies are in place, different teams can contribute to the library and help expand it.
How do I create a library?
Now that we know what is important in the core of a pattern library, you can see exactly how and where to start. With growing software offerings, everyone has their favorite tools. I am just going to touch on some of my approaches here. I hope this helps to get an idea of what a starting point might look like. As I said: as long as the meaning of the Pattern Library is fulfilled, everyone is free to choose which tools to use.
There are more and more design tools, so it can happen that the suggested methods I do now are no longer timely at the time of reading (similar to when I read the UI elements in Photoshop on four-year-old posts). I personally prefer to work with Sketch during the design phase. Just since version 47, it is possible to access a central file as symbol source – Game Changer! All screens I create and distribute to different User Story folders will change when I open them as soon as I have changed elements from the central symbol file, the elements of the screen access the central symbol file in advance. Also take a look at the possibility of nesting symbols – keyword: Overrides. I can create an element as a symbol, which in turn has further child elements, which in turn can have further child elements. Through overrides, I can then decide what variation of child elements I want to have. With a detailed library, screens are ideally created with hardly any new elements. All necessary elements are covered by the library.
Documentation & Code Storage
A slim HTML page in which all elements are sorted and displayed in a meaningful way is usually a good choice. Here are some examples:
Depending on the project size, you can create an HTML page with all elements and the respective code. The code of the library should be separate from the rest of the code in order to clearly separate library elements from the rest. Here everyone can personally decide how the code is stored. It is important to note that the code can be maintained with as little effort as possible (note the changes in the documentation when changing the source code). For larger projects, source control should be mandatory.
Yes, pattern libraries are upfront work and therefore time-consuming. The investment always pays off after a certain project size and foreseeable project period. The order, clarity, and containment of misunderstandings is improved. The time saved in the long term in terms of organization can benefit other important construction sites of the product.