Building UI Patterns Library: A 5-step Process

UI Design Patterns, User Interface Standards, or UI Toolkit. They go by many names.

What is common is a set of screen layouts with a common look and feel along with interaction rules and guidelines of use. They typically come with well-illustrated examples and specific do’s & don’ts.

Most of the big software producing companies have their library of enterprise user interface design patterns. While, I do not intend to devote this article to the debate on the benefits of introducing pattern libraries, UI Design Patterns do have their use in a large company with a huge product-line. Consistent user-experience being the primary.

However, all the benefits of using UI Design Patterns are applicable only when you do it the right way. Go wrong and you end up with Anti-Patterns! Which neither your users will appreciate, nor your colleagues going to adopt!

How to ensure that you are building a UI Pattern Library that works? Not Anti-patterns!


I have built and used design patterns and standards in two large enterprises. And witnessed things that made a positive difference to the product user-experience, and things that can go wrong. If the key requirements are not covered, the design patterns will not be useful. Being consistent across product would not help much if the have negative design value, low on usability and inconsistent to user’s mental models and flout basic tenets of human-computer interaction.

Like building any product, you need a 'process' to build a useful design pattern library that adds value and is adopted by the staff. A process that will guarantee that you build the 'right' thing.

Building UI Pattern Library the right way!
A 5-step process to build UI design pattern library:

1. Nail down audience

Who are you building the pattern library for? For designers? For software developers? Or for third party software producers? If the pattern library is meant to be used by the software developers, you might to support by a component library or framework which could be readily used by the UI developers. If it is meant be consumed by the third party developers, you need to point to the some examples of correct adoption.

2. Identify common use cases across products

Design means solving a problem. Each product design has its own set of problem solving. But in your design pattern library, you want to provide solution for the common problems? The common use cases across key product lines. Now what do you mean by 'common' use case? You do not simply club together some use cases across products. For a use case to called 'common', the context has be common. The uses types and roles have to be common. And, the problem definition have to be similar. Only then, you can apply a common design to a set of problems. Remember, patterns are a common solution to a set of similar problems

3. Abstract design patterns from the real products

Now you have identified the common problems to be addressed. How do you go about providing a common design solution? You do not design a pattern in isolation. Designing is all about providing solution within a context. Design patters must be abstracted from real products. Design for a real product, with a real audience, and generalize it into a pattern.

Remember! When you abstract a design from a real product, you must ensure that the design has gone through a rigorous usability testing at all the stages of design.Perform usability testing on design patterns within the context of a real product. Then 'patternize' it.

By abstracting the design from a real product, you also ensure that it has blessing from the software developers, and can be implemented in a real world.

4. Validate the patterns in the context of new product design.

Like in product design, user testing is an key component of the pattern design process. Does the design add positive value to the overall user-experience or ends up frustrating the end user? The true test of patterns is testing the real products which have adopted the design patterns. Whether you conduct benchmark usability studies, or monitor the user data through a analytics software, you need to get feedback from the real world users on how does your design patterns perform. Apart of just plain bad design, there might be cases where patterns have been applied to problems other than the one intended. Interpretation of usage guidelines if ambiguous can be influenced by the one that the pattern consumer has in mind. Patterns might be applied in a different context or use a technique with unintended consequences.

5. Refine the design patterns

Building design pattern library is a continuous process. Refine the design patterns based on user data you collected from the end-users of real products. Not only does the user feedback directly impact the design patterns, they have an indirect influence by impacting the requirements and the use cases of the actual products. All design and requirement changes in the actual products should percolate back to design patterns that went into building the software.