Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/pretty-bats-know.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
---
'polaris.shopify.com': minor
---

Remove section on compositions vs patterns.
37 changes: 5 additions & 32 deletions polaris.shopify.com/content/patterns/design-patterns.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,19 +15,15 @@ A design pattern is a repeatable solution to a common UX problem in a specific m

---

### Join the conversation!
### Join the conversation

Do you have ideas or feedback on how we can make these guidelines more empowering and useful? Please share your thoughts in the [GitHub discussion](https://github.com/Shopify/polaris/discussions/6046).

---

## Principles

For patterns to be successful, they need to be contextual, consistent, and unified.

### Contextual

A pattern is always paired with the problem it solves and the situation it appears in. A solution applied in a context it wasn’t designed for is not a pattern.
For patterns to be successful, they need to be consistent, unified, and contextual.

### Consistent

Expand All @@ -37,31 +33,8 @@ Patterns are always used in the same way for the same reasons. Merchants need to

Patterns are always informed by and designed together with similar patterns. For example, patterns with similar purpose should complement each other, and patterns with similar functionality should share appearance and behavior.

![A solution box within a problem box within a situation box.](/images/foundations/patterns/design-patterns/situation-problem-solution.png)

Patterns come with a solution, problem, and situation that belong together. Solutions taken out of this context are no longer a pattern.

## Patterns vs. compositions

Patterns are for merchants and compositions are for builders.

### Pattern purpose

- Design the best possible merchant experience
- Simplify learning the UI
- Improve recognizability and ease of use
- Improve merchants’ admin proficiency

### Composition purpose

- Share as much code as possible
- Speed up the build process
- Improve maintainability and reusability
- Ensure build consistency
### Contextual

### How to distinguish
A pattern is always paired with the problem it solves and the situation it appears in. A solution applied in a context it wasn’t designed for is not a pattern.

- Patterns solve usability problems that relate to the usage of admin, while compositions solve build problems that relate to the build process
- Patterns ensure consistent product experience, while compositions ensure consistent implementation
- A pattern can be hard coded and still be a pattern, and a composition can be using Polaris primitives and tokens and still not be a pattern
- Patterns are the language we speak with merchants, compositions are the code we share among us
![A solution box within a problem box within a situation box.](/images/foundations/patterns/design-patterns/situation-problem-solution.png)