Designers should consider how to take advantage of familiar design patterns to help people easily navigate our designs and reduce cognitive strain. In this lesson, we'll cover some common design patterns and best practices for working with design systems as you design entire user flows to ensure consistency within a given brand or product.

User Interactions and Flows

Imagine you've been hired as a UX designer for a new travel website targeted to young adult travelers. You've been tasked with designing a flow for finding and booking a flight.

Where would we start? A good place to begin would be referencing existing design patterns. **Design patterns** are widely adopted solutions to common design problems. While there isn't any global or standardized reference for industry-wide design patterns, there are many ways to find a baseline to design from.

When designing a flight booking process, we need to consider what types of actions are part of this process. We'll need some sort of way for users to select dates and locations, as well as a listing of the results once they've completed a search. We'll also likely want to offer some ways for users to filter and narrow down search results. 

Once we have a sense for what types of actions the user will need to take, we can reference design patterns from competitive analysis and pattern libraries as we build out our flow.

We should always perform a **competitive analysis** to examine designs with related functionality as part of the design research process. For our flight example, we might look at search flows on existing airline websites. We could expand our search by looking at other travel websites, like train, bus, and car rental services services, or travel aggregators like [Kayak](https://kayak.com). We might also consider non-competitive designs with similar functionality, like hotels or event listing websites, for creative ideas.

We can also reference pattern libraries, websites that collect and define different UX and UI patterns for reference, for example:

* [UI-Patterns](https://ui-patterns.com/)  
* [UIPatterns](http://uipatterns.io/) 
* [Page Flows](https://pageflows.com/) 
* [UI Guideline](https://www.uiguideline.com/components) 
* [Patternfly](https://www.patternfly.org/v3/pattern-library/index.html)

(The term "pattern library" is also sometimes used to describe internal pattern libraries used for reference within an organization's design system, which will be covered later in this lesson.) 

While it may be tempting to reference a design pattern because it's our personal favorite, or because we think it looks best, always consider the *user needs* and *business goals* of a product to design the best pattern. We can always diverge from patterns as needed to meet our goals, while remembering that novel variations may add cognitive strain for the user.

In the following exercises, we'll take a look at a few different example design patterns relevant to our flight booking user flow. Keep in mind that this lesson doesn't cover all of the many design patterns out there, but you can use the tools, knowledge, vocabulary, and research skills here to find design patterns for any design problem you might encounter.


Screenshots of three different types of travel search field designs. The flight booking search from Kayak includes fields for locations, dates, round trip, number of passengers, flight class, and bags. The hotel booking search from Marriott includes destination, dates, number of rooms and guests, sorting options, and a checkbox for using points or certificates. The car rental search from Enterprise includes pickup location, dates, driver age, account number or promotion code, and vehicle class.


Design Patterns: An Overview

Most of us have had the embarrassing experience of not knowing whether to push or pull a specific door handle. In these situations, is it our fault – or can we blame the door? When we see a door handle like the one pictured below, we are probably inclined to pull. This is because the shape of the handle *affords* pulling. If it turned out that this door needed to be pushed, that would be a confusing experience!

![A door handle on a transparent glass door, which extends from the door in a shape that a person could grasp and pull.](https://static-assets.codecademy.com/Courses/interaction-design/user-interactions-and-flows/door.jpg)

An **affordance** is what an individual expects can be done with an object given its properties and their own abilities. Designing with affordances in mind ensures that a user's expectations of a given design align with what will actually happen when a particular action is taken. 

As we've learned from [Usability Heuristic #2: Match between system and the real world](https://codecademy.com/resources/docs/uiux/usability-heuristics), people tend to recognize design patterns from the physical world. As digital designers, we can build off what people already know to create the most intuitive designs possible. 

As more of design moved into virtual spaces, many virtual designs relied on **skeuomorphism**, a design style that imitates physical designs, to reference a familiar pattern. For example, [the J37 Tape plugin by Waves](https://www.waves.com/plugins/j37-tape#image) was designed to imitate a J37 tape machine.

![A physical tape machine with two tape reels and a series of buttons and knobs, alongside a screenshot of a digital plugin, the Waves J37 Tape, that closely imitates the physical tape machine.](https://static-assets.codecademy.com/Courses/interaction-design/user-interactions-and-flows/j37-skeuomorphism.png)

As more time has passed, we've seen new fully digital design patterns emerge, such as **flat design**. This style of design, which typically uses two-dimensional design elements and bright colors, can be cheaper, but can struggle with clear affordances. As digital literacy has increased and people have become more familiar with digital design, it has become more possible to use flat design while creating an intuitive user experience. 

Continuing on the music theme above, the popular music production software [Ableton Live](https://www.ableton.com/) uses flat design.

![A screenshot of a digital music plugin from Ableton Live, with two-dimensional knobs and meters in simple colors.](https://static-assets.codecademy.com/Courses/interaction-design/user-interactions-and-flows/ableton-compressor.png)

As designers, we should consider how to take advantage of familiar design patterns to help people easily navigate our designs and reduce cognitive strain. We can do this by referencing existing **design patterns**, and by creating **design systems** to ensure consistency within a given brand or product.

In this lesson, we'll cover some common design patterns and best practices for working with design systems as you design entire user flows. Let's get started!

Three images of different calculators: a photo of a Casio calculator representing physical design, a screenshot of an iOS calculator from 2013 with three-dimensional shaded buttons that resemble a physical calculator representing skeuomorphism, and a screenshot of a Mac OS calculator from 2022 with simple two-dimensional buttons representing flat design.

Introduction to User Interactions and Flows

Have you ever found yourself browsing a website and feeling like you couldn't escape from a particular flow? Perhaps like you were tricked into providing information you didn't want to share or buying additional items you didn't plan to purchase? Maybe you've found yourself accidentally inviting your entire contact list to an app you were trying out?

Deceptive design patterns like these are known as **dark patterns**, coined by UX specialist Harry Brignull, founder of the [Deceptive Design](https://www.deceptive.design/) blog, in 2010. The blog describes dark patterns, or deceptive design patterns, as "tricks used in websites and apps that make you do things that you didn't mean to, like buying or signing up for something." 

Some types of dark patterns include:

* **[Sneak into basket](https://www.deceptive.design/types/sneak-into-basket)**: "You attempt to purchase something, but somewhere in the purchasing journey the site sneaks an additional item into your basket, often through the use of an opt-out radio button or checkbox on a prior page."
* **[Confirmshaming](https://www.deceptive.design/types/confirmshaming)**: "The act of guilting the user into opting into something. The option to decline is worded in such a way as to shame the user into compliance."
* **[Misdirection](https://www.deceptive.design/types/misdirection)**: "The design purposefully focuses your attention on one thing in order to distract your attention from another."

Dark patterns often violate the [usability heuristics](https://codecademy.com/resources/docs/uiux/usability-heuristics) we've discussed in previous lessons. For example, a dark pattern might make it difficult for a user to get out of a particular flow once they've entered it (also known as the [roach motel](https://www.deceptive.design/types/roach-motel)), violating Heuristic #3: User control and freedom.

As UX and UI designers, instead of relying on dark patterns, we should consider how to create honest, intuitive designs that balance favorable outcomes that serve both user needs and business goals. While dark design patterns may lead to short-term business gains, they ultimately diminish trust for a product or brand over time and do a disservice to the people using our designs.



Be Wary of Dark Patterns

You're a new designer starting a job at a company that makes photo editing software. The company already has a well-established web presence. You've been tasked with designing a searchable gallery of images users have created using the software. Where would you begin?

If the company has a well-documented design system, our lives probably just got a lot easier!

Design systems often include, [according to the Nielsen-Norman Group](https://www.nngroup.com/articles/design-systems-101/):

* **Style guide**: Style guides are often focused on visual design and branding. For example, what are different colors used for? How should the logo be treated? How are different typefaces used? How large should header text be? Some style guides may include further guidance on written content, UX copy, or interaction design.
* **Component library**: Component libraries are repositories of reusable design components that designers can easily copy into new designs. For example, if a designer needs to add a button to an input form, they could copy a component from the component library.
* **Pattern library**: Pattern libraries are repositories of reusable design patterns which focus on layouts that could include multiple components and focus on content structure. For example, a login pattern might include multiple components such as a header, text input fields, a button, and potential error or success indicators.

These systems allow UX and UI designers to focus on the flow of user behavior, rather than needing to redesign specific components every single time they come up. They also keep design consistent for users. There's still room for creativity, but a lot of repeat effort is saved on problems that have been solved before.

Different organizations document their design systems differently, and different aspects of the system may live within different tools. For example, some organizations might maintain an internal wiki with their style guide, while their component library is maintained in [digital design software](https://www.codecademy.com/resources/docs/uiux/design-software) like Figma or Adobe XD for easy duplication into new design prototypes.

Getting Started with Design Systems

**Search results** are a list of results displayed after a search form is completed and submitted.

This is an interesting design pattern for us to discuss here because it can take a number of different forms. It's fairly common for search results to be showed as a [list view](https://www.patternfly.org/v3/pattern-library/content-views/list-view/), but we could also potentially use a [card view](https://www.patternfly.org/v3/pattern-library/content-views/card-view/) to display results as a grid. Some types of data might work well with a [table view](https://www.patternfly.org/v3/pattern-library/content-views/table-view/).

In designing how search results are displayed, we should consider:

**What information should be displayed for each result to help users select the best fitting result?** 
For a search on a newspaper site, this might mean showing a title, author, description, thumbnail, and date. For our flight booking tool, users might want to see the airline, flight date, departure time, arrival time, total duration, number of stops, and airports. 


**What order should results appear in by default?** 
Should other sorting options be available to the user? Some examples of sorting methods include relevancy, chronological, and alphabetical.

**Should any filters be available to users after searching?** 
For example, on an ecommerce website, users might be able to filter results by price or available sizes. For our flight booking site, users might be able to toggle whether to show nonstop flights only.

**What is the next desired step after the search, and should there be any shortcuts?** 
For example, a shopping website might allow a user to quickly buy a product or add it to their cart directly from the search results, without navigating to a more detailed product page.

**How will users scroll through results?** 
Is the listing an infinite scroll that loads more results as the user scrolls? Will it use pagination? If so, how many results should it show per page?

**Should any results be differentiated visually?** 
For example, for our flight booking app, should limited deals on flights be highlighted or featured so users see them first? On a news website, sponsored stories might be visually differentiated to make it clear they aren't standard editorial.

Design Patterns: Search Results

General site structures flowing from one to the next.

In previous lessons, we've spent some time designing wireframes for individual screens within a website or application. But any given screen or action on a website doesn't exist in isolation. Every screen is part of an entire flow. Thinking about how users will move from one screen of a flow to the next, as well as designing small actions within a given screen, is what interaction design is all about.

As you can see from the diagram on the right, this can get complicated quickly. As we know from earlier exercises, novel design patterns can create additional cognitive load for users, and often, many designers are simultaneously working on different problems within the same organization.

How do we, as designers, ensure the most consistent experience possible?

This is where **design systems** come in. These repositories of reusable components and patterns can be used across a team or organization to ensure consistency across all design output. 

**Design patterns**, as we discussed previously, are solutions to common design problems. Design patterns can include specific modules, flows, or behaviors, and are more likely to be edited or adapted for a specific context. **Design components**, on the other hand, are specific examples of elements that might exist within a given context. For example, a button designed in accordance with the style guide for a specific website section would qualify as a component and would be more likely to be copied directly across instances, rather than adapted.

Design systems allow for design to happen more quickly at scale, and can help with onboarding new design team members. One of the challenges of design systems is ensuring that they are maintained. Both building and updating the system requires time and effort.

In the next exercises, we'll talk about design components, as well as what is typically included in a design system and how to get started using them.

> Design systems are not to be confused with CSS libraries and frameworks like [Bootstrap](https://getbootstrap.com/), [Foundation](https://get.foundation/), and [Bulma](https://bulma.io/), which offer templates and components to frontend designers and developers – but these libraries may be used for a similar purpose to ensure consistency once a design is in the development phase.

Implementing a Design System

Whether you're entering your birthdate, searching for events, or booking travel, a **date picker** is a common design pattern used on many different types of websites and applications. This design pattern should allow users to easily select a specific date or date range.

As we design a date input field, we should consider questions like:

* Will it be easier for users to select dates from a calendar, to input dates through a text field, or a hybrid approach?
* Do users need to select a single date, such as for appointment scheduling, or a range of dates, such as for vacation planning?
* Should there be a default value? For example, should the date default to today's date?
* Are there any shortcuts that should be included (per the seventh [usability heuristic](https://www.codecademy.com/resources/docs/uiux/usability-heuristics) coined by Jakob Nielsen, "Flexibility and Efficiency of Use")? For example, should users be able to jump to the next month or year? Should users be able to manually enter a date even when a calendar is available?

We can reference some existing design pattern listings, such as the [Calendar Picker on ui-patterns.com](https://ui-patterns.com/patterns/CalendarPicker), [Date Picker on UI Guideline](https://www.uiguideline.com/components/date-picker), and [Date Input on uipatterns.io](http://uipatterns.io/date-input) (which focuses on mobile applications).

Four types of date pickers. Option A is a calendar with clickable dates. Option B is a text field with 'MM/DD/YYYY' inside it, with the option to click and select a date from a calendar. Option C is three dropdown menus for the month, date, and year. Option D is a freeform text field with 'MM/DD/YYYY' inside it.

Design Patterns: Date Picker

A collage of images related to design systems, patterns, and components, such as a login design pattern, a wireframe of a content block, a button, spinner and stepper progress indicators, and a calendar.


That's a wrap! In this lesson, we got an overview of how to design user interactions and flows using existing design patterns and design systems. After this lesson, we hope you feel ready to tackle some larger-scale design problems and build larger flows and interactions beyond a single wireframe view, while optimizing for both user needs and business goals.

Here's a summary of what we covered: 

* An **affordance** is what an individual expects can be done with an object given its properties and their own abilities. Designing with affordances in mind ensures that a user's expectations of a given design align with what will actually happen when a particular action is taken. 
* **Skeuomorphism** is a design style that imitates physical design,  to reference a familiar pattern, while **flat design** typically uses two-dimensional design elements and bright colors.
* **Design patterns** are standardized solutions to common design problems, such as progress indicators, date pickers, and search results. Designers should always consider the user needs and business goals of a product to choose the best design pattern.
* **Design components** are specific examples of elements that might exist within a given context. For example, a button designed in accordance with the style guide for a specific website section would qualify as a component.
* **Pattern libraries** are repositories of reusable design patterns which focus on layouts that could include multiple components and focus on content structure. Pattern libraries can refer to both public listings cataloging design patterns from across the web, and internal pattern libraries used within a specific company's design system.
* **Dark patterns** are tricky or deceptive design patterns used in websites and apps that make users do things that they didn't intend to. While dark design patterns may lead to short-term business gains, they ultimately diminish trust over time and do a disservice to the people using our designs.
* **Design systems** are repositories of reusable components and patterns that can be used across a team or organization to ensure consistency across all design output. They often contain a **style guide**, **component library**, and **pattern library**.

Next, we'll be applying these lessons to design wireframes for an entire product.


Wrap-Up

An illustration of three types of progress indicators. The first is a spinner, a simple spinning wheel icon. The second is a progress bar, a rectangle filled 75%, which says '75% loaded' underneath. The third is a stepper with four steps indicated by circles progressing along a line.

Have you ever clicked a link or submitted a form, only to find yourself frustrated and waiting for an indefinite amount of time? 

While the digital experience of waiting is relatively novel, experts have been studying how to make physical queuing more tolerable for a long time. We'll often find that digital design methods can draw from broader studies of psychology or other fields. [According to queue theorist Richard Larson](https://99percentinvisible.org/episode/episode-49-queue-theory-and-design/transcript), there are two rules to consider when designing a queue: first, keep your customers entertained while they wait in line. Second, manage their expectations.

**Progress indicators** are design elements that help users understand how far along they are in a given process, such as loading a web page or search results. These can help manage user expectations by offering information about what stage they have reached in a given process.

**[Progress bars](https://www.patternfly.org/v3/pattern-library/widgets/#progress-bars)** show what percent of a process a user has gone through. These are common for loading content and can be combined with other types of progress indicators, such as a countdown of the time or percent of the process completed or remaining. (See also: [UI Guideline](https://www.uiguideline.com/components/progress), [UI Patterns](https://ui-patterns.com/patterns/CompletenessMeter))

**[Steppers](https://www.uiguideline.com/components/stepper)** show which steps of a process the user has completed and which steps remain. These are often used with long forms or questionnaires to indicate how many more stages the user needs to complete.

**[Spinners](https://www.patternfly.org/v3/pattern-library/widgets/#spinner)** (sometimes associated with [loading states](https://www.patternfly.org/v3/pattern-library/communication/loading-state/)) are sometimes used to indicate that progress is happening, but for longer processes can be frustrating, as they continuously loop and don't provide additional information to manage user expectations. (See also: [UI Guideline](https://www.uiguideline.com/components/spinner))

It's up to us as designers to decide which type of indicator, or which combination of indicators, best serves both user needs and business goals, in a given scenario. We might make a decision based on what information is available to us &mdash; for example, we do have access to the time remaining or percent completed to display that data? We might consider how long of a wait we expect the user to face &mdash; a spinner with no additional information might be fine for a quick wait, but frustrating for longer wait times.


Design Patterns: Progress Indicator

Earlier in this lesson, we discussed design patterns in depth. Design patterns are made up of smaller, more static design components, such as buttons, menus, and form fields, which are typically documented in a brand's design system. 

As an example, let's think about the role of buttons in digital design.

Within early digital interfaces, many buttons were skeuomorphic and imitated physical designs. For example, a play button on a music player might have resembled the play button on a radio. 

As digital design has evolved, users have come to recognize both skeuomorphic and flat design buttons as clickable elements that will cause some sort of action, whether it's navigating to the next step in a flow, submitting a form, or activating a feature. 

In summary, **buttons** are clickable elements often used to highlight certain calls-to-action or links on a website. They are a common design pattern used across all kinds of websites and applications.

In designing buttons, we should consider questions like:

**Where does a button make sense over a text link or other clickable element?** 
Buttons are associated with some of the actions that a user needs to take. For our flight booking example, this might mean using buttons for submitting the search form and to book the selected flight.

**What text should be included on the button?** 
Text on buttons should be concise and make it clear what action will occur once the button is clicked.

**How will users know the state of the button?** 
Does the button change color or style on hover or when it is pressed?

**What different types of buttons will exist in this design system?** 
Should there be different button styles for primary and secondary calls-to-action (CTAs)? What color should a "delete" or "disable" button be, versus a button that advances a positive action? Does the "submit" button for a form have a special style compared to other call-to-action buttons?

As we design buttons, we can reference some existing design pattern listings, such as [Buttons on Patternfly](https://www.patternfly.org/v3/pattern-library/widgets/#buttons) and [Buttons on UI Guideline](https://www.uiguideline.com/components/button).

Four examples of different button designs. There is a rounded three-dimensional skeuomorphic button with a drop shadow that says "Learn More," a two-dimensional flat design button with a stroke or outline around it that says "Browse the Gallery," a rounded flat design button with a drop shadow that says "Sign Up," and a more subtly skeuomorphic button with a cart icon that says "Add to Cart."