Patterns

What are Patterns?

Design Patterns

A design pattern is a recipe for a solution to a common problem.

"Design pattern" is an overarching term covering more than just UI/UX design, and more than just software. For example, you'll probably hear the term most frequently in the context of approaching problems using object-oriented programming—and it has its origins in the realm of architecture and civil engineering (Links to an external site.).

Usually, you won't even see the term "design pattern" used to refer to UI/UX, since there are specific types of user interface and user experience patterns.

We're going to focus on those user-facing patterns here—approaches to recognizing common user situations, and accommodating them with well-established, repeatable solutions.

UX Patterns

UX Patterns: Modeling an Experience

Once we narrow our focus to UI/UX, the difference between a UX pattern and a UI pattern becomes subtle. Why is that?

Think about our definition of pattern—a recipe for a solution to a common problem.

So much of what we design and build for a user experience is via a user interface. So naturally, a pattern to solve a user experience problem will often involve a user interface pattern.

But let's start by considering the general ways we can understand and start to model a user experience—the knowledge we have about what drives positive product experiences.

Jakob's Law

In 2000, Jakob Nielsen of the Nielsen Norman Group posited (Links to an external site.):

Users spend most of their time on _other_** sites.** This means that users prefer your site to work the same way as all the other sites they already know.

Note that Nielsen isn't just talking about the way websites look—he's referring to how they work. In other words, in general, a user's experience with a website will be better if they don't have to learn new ways to interact with it. What's the takeaway here? Use UX patterns!

Naturally, there's some controversy (Links to an external site.) about taking Jakob's Law to its absolute conclusion. If we all want users to avoid having to experience different sites differently, then will all websites end up exactly the same?

Nonetheless, when you're designing a product and thinking about your user's experience, it can be a very useful rule of thumb: don't reinvent the wheel. Default to the "boring" way to let your user experience your product—then think about ways to tweak that experience if it makes sense for your product's goals.

The Hook Model

In his influential 2014 book Hooked: How to Build Habit-Forming Products, Nir Eyal proposed the Hook Model (Links to an external site.).

The Hook model divides a user's interaction and experience with a product into four phases:

A trigger to start using it
An action that "satisfies" the trigger
A reward for the action
An "investment" that makes the product more valuable to the user

Taken together, these phases of the Hook Model are a UX pattern. We're predicting ways that users will become engaged with our product via an experience we can engineer.

One thing to note here, however—the Hook Model focuses on optimizing products for engagement—it doesn't necessarily optimize products for quality. In any case, though, keep it in mind as a valuable way to build a product experience that will keep users coming back.

Gamification

Gamification is incorporating game-like reward features into a product that isn't nominally a game.

One example of gamification is the Wikimedia Foundation's donation badges (Links to an external site.)—users who donate get recognized with a public badge (this also incorporates another useful concept: social proof—giving your users examples of other people using your product in a certain way to encourage them to do so, too). Another frequent example is giving users points for completing certain actions, like filling in their profile information.

To drive positive product experiences, you'll want to ensure you're motivating your users, not manipulating them—and that you're not relying on gamification alone to make the user experience great.

The List Goes On...

There are hundreds of UX patterns out there, like:

ways to give feedback to the user
ways to increase or decrease choices for the user
ways to rely on or assist users' memory

If you want to read more about UX patterns, check out Laws of UX (Links to an external site.), a really cool site laying out a bunch of research-driven UX principles and best practices.

We've barely scratched the surface—but hopefully, these examples give you an idea of the work that has been done to understand user experiences, and to synthesize that knowledge into formulas for product success.

UI Patterns

UI Patterns: Implementing Paradigms

Now that we've examined general approaches to user experience problems, we can take some of those paradigms—models for thinking about things—and see how we can implement them via user interfaces.

Common UI Patterns

These frequently-used UI patterns combine structure, organization, and interaction behavior to meet users where they are and provide predictable, minimum-friction experiences. You'll almost certainly immediately recognize them!

Pagination

Pagination is splitting content up into pages. These aren't necessary separate screens or webpages—you'll usually deal with pagination when you're working with tables:

Pagination helps us avoid putting too much information in front of our users at once.

Note that to implement pagination, your product will often need to adjust the way it queries a database—we'll probably only want to retrieve the "page" of data we're interested in displaying. This is called query pagination. Pagination is thus a great example of how designing a user interface based on a user experience can result in a full-stack engineering feature—the frontend and the backend will need to accommodate paginated queries in order to present this experience to the user.

Progressive Disclosure

Progressive disclosure is waiting to show content and/or prompt the user for action until it's needed. As the user continues toward a goal, they complete the process gradually. Pagination is an example of progressive disclosure!

Another example of progressive disclosure is using lazy forms—forms whose fields only appear once the user has filled in the previous field (or set of fields):

A related concept is using wizards—walking the user through a process, with input fields or other required actions showing over multiple pages or screens:

Progressive disclosure prevents users from being intimidated by having to go through a lot of information or perform a lot of actions at once.

Breadcrumbs

Breadcrumbs are a very common UI pattern where we display a "secondary" navigation system to the user based on where they are in a hierarchy of pages or screens.

Note the breadcrumbs below (New Items → Popular → On Sale):

Breadcrumbs both orient the user and allow them to navigate in context.

In order to be usefully orienting, breadcrumbs should be based on the actual page or screen hierarchy (the way the content is actually organized) rather than whatever way the user has happened to navigate around (their history). That's because showing the hierarchy gives the user more information about how your product's content is structured.

Empty States

Empty states are an extremely useful pattern that tells the user: "There's nothing here right now—but there could be!"

Empty states are highly orienting for users, because it tells them both how they should be interacting with your product, and what to expect both in the short term and the long term.

If your users will land on a screen where data could be displayed, but there currently isn't anything to show them—you'll almost certainly want to show them an empty state.

My Docs