Introduction

Experience pattern components are more complex than components, they may contain content and logic.

Components	Experience patterns
Can be an atom, molecule or organism.	Built using Nucleus components and foundations.
Can have it’s own custom styles.	Can’t have any custom styles.
Does not hold any content.	Can hold content.
Does not perform any logic or UX.	Can perform some logic or UX.
Built to serve lots of variations.	Built for a very specific purpose.
	Handle complex data that is passed down to it.

An example

Take <nsx-marketing-consent> as an example. This is built up of typography such as paragraphs, headings, links, and form inputs.

If it was just this then we would raise a Proposal and see if there are other uses for this pattern to create a component. However, nsx-marketing-consent requires legal copy to be compliant with GDPR, only specific options to be contacted and most journey’s require it. Therefore, this is an experience pattern.

A Proposal can still be raised to see if this pattern is used elsewhere. Journeys might be having a similar pattern, such as for how to contact your engineer.

From the RFC (request for comments) we find that each journey want different variations of how to contact your engineer, such as with radio buttons, checkboxes. Also different engineers would require different copy for, therefore this can’t be an experience pattern, but it can be a component. Then we can create the component through our normal process.

The marketing preference experience can then be updated to use the new component.

The difference

There can potentially feel like there is an overlap and can be difficult to see a difference.

Sometimes we might be looking at an experience pattern, but it requires new components to be built.

The best question to ask is:

Are you creating something new that is not seen in Nucleus?

If so, then it will have to start off at creating those components.