How to utilise recognised patterns to create new interactions

The elements we place on a screen in a digital product are very much akin to the words on a page in a book. Individually they have their own function, their own meaning. When multiple elements are placed next to each other in a specific order, they begin to form a broader picture and provide a narrative which a user can understand.

Take a simple text input for starters.

A screenshot of a First Name input field

Just by looking at this single input accompanied by its label, we understand that it is asking us to enter our first name.

Now let's add to that first element.

A screenshot of a collection of form input including First Name, Last Name, Email and Password

We have added 4 elements that are very similar to the first. Based on our learned behaviours, and the context of each element, we know that we have to enter our last name, email address, and a password alongside our first name.

What does this look like to you? Have you seen this collection of elements somewhere before? It may have been slightly different in the way it looked, the way it was worded, but you know what this collection of elements means in terms of context, but it's still missing something.

A screenshot of a complete registration form

We add a button to the bottom of the form and the purpose of this collection of elements is now obvious, we have a registration form with all of the common inputs and an action button to submit the form.

Understanding through learned behaviour

The reason why we recognise this collection of elements as a registration form is through learned behaviour. We have seen this pattern, and slight variations on it, across so many websites, applications and services, it has become an easily recognised interface.

The same goes for most of the interface patterns we see in the digital world every day; search functions, navigation, video players, image galleries, and so much more.

I learned from Mr Joe Leech that these are referred to as design axioms.

Design axioms are a statement or proposition which is regarded as being established, accepted, or self-evidently true.

If you're looking for a search input, you tend to look to the top right of a page, and the same goes for a shopping cart or the ability to change language (which can also be commonly found at the foot of the page). If you want to go back to the home page of the site, the logo is usually clickable and fulfils the purpose of a home page link.

If we're looking for the navigation on a website, we tend to look to the top or left of the page. However, with the advent of mobile devices and responsive design, we had to look at ways in which we could incorporate larger navigations onto a much smaller screen. There were a number of different approaches taken to solves this problem, but one became far more infamous than the rest; the hamburger menu icon.

When the hamburger menu pattern was introduced, nobody had any idea what it meant. It was steadily implemented across other applications and responsive websites as a solution to reduce the screen real estate that a navigation menu would take up and was the best solution that could be made at the time.

Interaction design evolves like language

Collectively user spent a lot of time getting to learn what the hamburger icon represented and what it did when they interacted with it. As this pattern was implemented in more and more interfaces, more and more people would see it, use it, and understand it. As more people understand it, the more it is used, and the more it becomes part of the interaction design lexicon; part of the language we can use as designers to effectively communicate how someone should interact with our interfaces.

As a father with children of school age, I am all too familiar with the rapid evolution of language. I am constantly introduced to new words picked up in the playground, or more likely from their favourite YouTubers or streamers. I am in the same position my parents were decades ago when I was picking up and using new words and phrases.

Just like everyday spoken language, the interfaces we build and create will evolve and will become successful through a Darwinian-like form of collective selection. If a pattern is implemented by a tech giant such as Facebook or Google, and it works, we can quickly see that pattern propagate throughout various interfaces across the broadest of spectrums.

We will also see new patterns that only work in a given context thrive in some environments, and fall flat in others. As with all aspects of interaction design, if something we create does not effectively communicate how a thing should be used, it will fail at its primary purpose; helping the user to solve a problem.

So what happens when you come across a new problem that needs solving, and there is no accepted answer, no design axiom, no pattern that covers what you need a user to be able to do?

Evolving your interface with context

In this situation, where a tried and trusted pattern that solved similar problems don't cut the mustard, we have to look to innovate on what exists to more effectively deliver a solution that helps the user to complete their task.

The way we do this is to iterate and evolve existing patterns that are successful in similar contexts to deliver a more effective solution in your specific context. In real terms, these manifest as small interface changes that make more sense for a given context.

An example of this from some of my recent work revolved around the GDS pattern of the task list. At the time, this pattern had not been thoroughly tested, but it was the closest fit to the needs we had on our project. We needed to surface all of the parts of a long and complex application form so that the user could see everything that they would need to complete to submit their application.

An image of the GDS task list pattern from February 2019

As per the image above, the task list only had a tag alongside a link to state when a section was completed, and the tag was simply absent where a section still needed attention. For our users' needs on our project, we needed to guide the user through the process more specifically by telling them what was next, and by informing them when some sections were not required.

We based our new pattern on the original task list and began to introduce new elements in the form of these new tags, to convey the relevant information to the user in this particular context. We added a 'NEXT' tag when a user needed to be guided to the next section that needed completing in order, and a 'NOT REQUIRED' tag to show that some sections needed no attention, as you can see from the image below.

An image of the task list with design iterations based on user needs within a specific project

Looking at the task list pattern on the GOV.UK Design System today, you can see how some of these evolutionary steps have now been incorporated into the pattern, with different tags to show the status of different sections in the task list.

An image of the task list pattern as it exists in August 2020

The changes we made to this pattern in our specific context, combined with the changes similarly made by other teams in their specific contexts, have slowly become integrated as part of the pattern on which those iterations were originally based.

In conclusion

The evolution of interaction design patterns stems from an iterative approach. By taking those existing patterns that have been proven to work in many circumstances, we can make small changes to fulfil the specific needs of a given context, feed that back into the original pattern and see if that iteration can have a positive effect in other contexts.

The creation of new patterns of interaction is rarely successful with a 'big bang' approach. People are essentially averse to change. How often do Facebook users voice their dissatisfaction of a big interface update? As they continue to use the platform, they will eventually learn how to navigate the updated interface, but this is a case of exception.

The cast majority of long-standing and successful digital products tend to slowly evolve. Small changes are made to interfaces that improve the user experience, if only slightly, on a continuous basis, over a long period. Users are more open to accepting these kinds of changes as improvements as it is not as jarring a transition from the experience they are comfortable with to a more effective interface that helps them complete their tasks.

As the tortoise and the hare demonstrate, slow and steady wins the race.