UI Patterns. Why and How?

Hi! My name is Ksenia Toloknova, I am a product designer and design lead with 12+ years of experience. For the last 5 years, I have been passionate about design systems and, in general, issues of a systematic approach to design creation. A couple of years ago, I realized that a design system does not always cope with its tasks, and today I would like to discuss why this may happen.

Design systems have rapidly gained popularity. It is great that many companies have already created their design systems and are now developing them. Meanwhile, launching a design system and supporting it is quite an expensive pleasure. When a company decides to take such a step, it definitely wants to make a profit from it. And yet, sometimes it happens differently.

Let me say right away that the market is aware of the problems. The section of UI patterns that will be discussed is available to major players: Atlassian, Polaris, IBM and many others. However, in my opinion, the topic is not raised often enough, and we will try to fix this.

Here's an example of the patterns section from Shopify's design system, where you can find information on how to design different cards or how to place actions in buttons. It's being expanded and over time, I'm sure there will be much more information here.

Within such patterns, there is detailed information on how to correctly use components in the context of common situations. In the card pattern, for example, the information architecture of the cards is clearly described. With it, designers will be able to create uniform designs with similar logic.

I think this is a pretty important focus for:

• product designers, because it is important for them to see the big picture and think about it, and not exist only within the framework of their favorite piece of the product;

• teams, especially those with 10 or more designers. When the team is small, problems arise less often, since they are handled by a limited number of people and it is easier for them to synchronize.

Why You Should Consider Creating UI Patterns

It would seem that a design system, by its very nature, as implied in its name, guarantees consistency. A full-fledged design system has a set of rules and components. According to these rules, designers can make one product without communicating at all and without even knowing each other. Such a product will look quite uniform – at first glance.

What's wrong? Unfortunately, I see that having a design system does not guarantee uniformity of solutions because:

• The same components can be used and understood in different ways.

• It's not just the elements themselves that matter, but also their relationships—how they fit together to form a unified interface.

The larger the team, the more important it is to have not only components and unified principles, such as editorial rules, but also your own UI patterns! Their importance is described by NNgroup in their famous heuristics:

In the process of working on a product, as well as writing articles about patterns in mobile applications, I study many services in detail. I see that many services have a fairly uniform appearance at first glance, but if you dig deeper, nuances become visible. Users often encounter unpredictable behavior of elements, navigation becomes difficult.

The largest market players are not immune to this (and are even more susceptible to it) – such inconsistencies occur in services like Google. Of course, sometimes there are quick launches for experiments, but this does not always justify the disunity of UI patterns in a product.

Let's look at an example of a fairly large application, which I have no doubt is being worked on by many teams. Let's try to find answers to the questions:

• Why is the curtain open in the first case, and the pop-up in the second and third?

• Why are the buttons located on the same line in the first and second cases, and one under the other in the third?

• Why does the “Cancel” button have an outline in the first and second cases, but not in the third?

• Why can the curtain be closed by clicking on the cross, but there is no cross in the pop-ups?

Think about how to answer these questions – we can even discuss them in the comments. I have at least a couple of options.

I see how problems arise from within. When I came to Alfa-Bank, there was already a mature design system that was used on many products. At first glance, everything was fine, but after analyzing the business application I was responsible for, I discovered that:

• Designers use navigation in different ways. For example, some of the designers designed the bottom navigation throughout the entire scenario in their mockups, while others left it only on the first level.

• Some designers opened additional information in the form of a new screen, while others used curtains. It was unclear how exactly the designer made decisions about what to use.

• The loading screens were varied. Some used skeletal loading, while others limited themselves to a screen with a loader. The scenarios were as similar as possible.

And this is only a small part of the interesting things I discovered. Again, I am looking at a specific example, but I see this often in other services.

Why does the design on one product turn out different?

I started to look into the reasons, and this is what I found:

• The components have fairly comprehensive documentation on their behavior, but there aren't enough examples of usage in context.

• When creating new scenarios, designers look at either their old layouts or their neighbor's layouts, but are unable to conduct a full analysis due to lack of time.

All this is quite logical and explainable. A design system, especially if it supports not one product, but several, does not provide a sufficient number of examples. Several different services with their own internal rules are implemented on its basis.

This is why, despite the comprehensive component base, it can be difficult for designers to understand which component to use.

Why do we need patterns at all?

Yes, the user probably won't notice many of these issues. But then why do I still think patterns are so important?

• Uniform standards save significant money. Without standards, we may not be developing basic components like buttons and input fields from scratch, but we still solve the same interface problems in different ways.

• The level of quality will reach a new level. Approved, time-tested solutions are guaranteed not to break the user experience. At the same time, if everything is done wisely, they will not limit the freedom of the designer.

I often hear the objection that designers will stop thinking if they are given everything ready-made. In my opinion, designers, on the contrary, will start thinking more about those parts of the interface that require their attention. A good system in itself is not capable of making a person think (although sometimes it would be desirable) or depriving him of this opportunity.

Patterns and their types

UI Patterns (User Interface Patterns) — are repeatable solutions to common user interface design problems. They are proven approaches to solving problems that designers often encounter when creating interfaces.

Examples of patterns

Navigation menu: Typically located at the top or side of the screen, it helps users navigate between the main sections of a site or app.

Login form: a standard form that includes fields for entering a username and password and a button for submitting the data.

Modal windows: Pop-up windows that appear on top of the main page and require user interaction before continuing with the main page.

Nilsson Norman has a group together selection of patternswhich they recommend to use. Currently, this section contains 72 materials on this topic.

Patterns improve the lives of everyone around you

• Designers do not struggle to solve the same problems.

• Developers get the opportunity to develop ready-made modules with embedded logic.

• Managers can better predict release dates.

• Business gets results faster.

I believe that patterns are essential in every product. The main thing is not to overdo it. To make designers' lives easier, not more complicated, patterns should contain only the basic concepts that are indispensable.

The app I'm working on currently has 17 patterns that cover about 70% of designers' tasks. Here I follow recommendations Dan Mall, who says 80% coverage is a great number and shouldn't exceed that to leave room for new solutions.

Pattern development

If you already want to implement patterns in your product, but don’t know how, I have good news – this is a standard product cycle. To create patterns, you need to go through the stages necessary for any solution. Let's list them and look at the details.

Step 1: Understand the picture as it is

To do this, you will have to do a rather complicated exercise – create a service map with screenshots from the sales. Step by step go through all the key scenarios and sections. This map will become outdated very quickly, but we have no task to keep it up to date.

You don't have to make the whole map at once; the number and specific list of screens depends on your task.

Step 2: List the main consistency issues and evaluate them

The map will help you see the whole picture. Based on it, you can make a list of all the recurring moments. Next, you need to make a table with the scoring of these problems. I suggest using the same parameters that are used Dan Mallremoving from the list everything that relates to a lower level – to components:

• Potential for common patterns: 1 = no or few templates that can be reused. 10 = many templates that can be reused.

• High Value Items: 1 = no high value items 10 = one or more high value items that Necessarily will be reused.

• Technical feasibility: 1 = Completely technically unfeasible. 10 = Technically feasible right now.

• Volume of work: 1 = cannot be completed in a reasonable time frame. 10 = can be completed quickly.

• Technical independence: 1 = Requires too many dependencies on other software. 10 = Does not require any other software to complete.

• Marketing potential: 1 = no one will want to use a design system. 10 = everyone will want to use a design system.

• Available supporter: 1 = No one will remind you that this site/app was created using a design system. 10 = People will constantly hear about how well the product was created using a design system.

The table will give you the clearest possible picture of your priorities.

Step 3. Market analysis

During the analysis, we add up all the implemented options and analyze similar solutions in other services. This will help not only to understand what options are available in a specific service, but also to understand what patterns are on the market in general. You should not neglect the analysis part, because only together they give a clear picture of the future solution. If you have saved the results of research that touched on parts of the pattern, they should definitely be considered as well.

An example from my practice. The designer collected examples of search implementation and analyzed external examples. This gave us a picture of our future result as quickly as possible:

I recommend that you explore applications close to your field on your own, but also a very powerful tool – portals that collect patternsHere are some of them:

Step 4. Brainstorming and Constraints

After the analysis, it is worth collecting 2-3 variants of the pattern and discussing their implementation with those whose work directly affects the patterns, or the patterns depend on the work of these teams. Most often, this is the design system team and developers who will implement interfaces according to these patterns.

Here, limitations or additional inputs may (and most likely will) be identified that may affect your future pattern.

For example, when my team and I were developing the navigation pattern in our app, we discovered that we couldn't technically implement bottom navigation that would be visible on all screens. That's why we decided to leave navigation only on the main screens and wrote it down in the rules. By the way, you can read about how navigation works here.

Step 5. Developing a solution

Once all the pitfalls have been pulled out, you can work on a specific solution. At this stage, it is important to make a good, succinct description of the new pattern and provide a sufficiently large number of visual examples.

I love writing and reading. But I also understand that not everyone loves this, and a designer does not always have enough time to understand the meaning of the rules in patterns, especially if the text consists of more than two lines. Therefore, I always try to give an example for each rule, or even better – several examples.

To take the edge off seriousness and increase empathy, you can add some little Easter eggs.

Step 6. Distribution

Surprisingly, many people think that the rules they have developed will just start working. This is not true at all! A designer will hardly find time in his life to study anything beyond his usual workload.

There are many ways to distribute patterns. I recommend using several at once, since people absorb information differently. Here are my methods:

• Telegram channel. My team and I publish the best of our patterns, with pictures of course.

• Meetings. Whenever a new pattern or major update is released, we hold presentation meetings.

• Implementation into onboardingIt's easier to feed information to newbies, since they've already accepted that there will be a lot of it.

• Personal messages. If the team size allows, this is the most effective way. I send each of the 40 designers a message so they feel like it's personal and can ask questions directly and immediately.

Whatever options you choose, I recommend that you think carefully about the format of your messages. Here is my checklist:

• Convey benefits quickly. Why is it important for a designer to look at the material?

• Be brief. No one has time for a long text.

• It's great if you can take care of the design. Add graphics if possible, and don't forget about emotions in the text.

Patterns update and support

What's the power of patterns: they're relatively easy to maintain. You just need to implement changes to the patterns and teach designers to go there when creating new scenarios.

Patterns, like components, can be versioned. We live in an environment of constantly evolving design systems and rules. They are flexible and can be revised. That’s why we constantly check our patterns and update them periodically.

In order not to make life difficult for product designers and not to disrupt the product cycle, we do not insist on immediate replacement of all outdated components. However, when updating the scenario, designers should use the latest patterns. In this way, we ensure the process of continuous development and improvement of our products.

Instead of a conclusion

We already have a lot of experience behind us, we have formed habits that can and should be used to design high-quality design solutions.

I'm sure UI patterns will appear more and more often and help us, product designers, create truly consistent user experiences, focusing on the truly complex moments and challenges of the market.

Share in the comments whether you work with patterns on your project.