Web Development Design patterns

Design patterns are common solutions to common problems. When you add a slider to a homepage you’re employing a design pattern. When someone asks: “Why reinvent the wheel?” they’re advocating the adoption of a design pattern.

On the Web, the term “design patterns” most often refers to programming techniques, however design patterns also exist within visual design. And whilst solving a recurrent coding problem with the same solution is an efficient approach, reusing a visual design is not as desirable.

Why do we use design patterns?

Design patterns are far less common in print design than on the Web, despite the fact that print design has had much longer in which to devise them. The reason for this is that web design is heavily influenced by disciplines such as information architecture, coding, and usability; all of which embrace the use of design patterns.

Programmers don’t value originality, they value effective, elegant solutions. If you’ve ever written in PHP you’ll know that there are numerous ways to retrieve data from a database, but most PHP coders have one snippet they use time and again. If you’ve written JavaScript you’ll know that there are a variety of ways of looping, but one of them is more efficient, and generally preferable. In fact, most code editors have a snippets function precisely because programmers reuse solutions.

Designers on the other hand, do value originality, and whilst it’s probably true that some designers use design patterns because they lack the imagination (or courage) to do otherwise, most designers are simply adopting a formula that has been proven to get results.

However using a design pattern isn’t natural to the design process, and that’s why you’ll find the most obvious design patterns where coding has a greater influence. Compare the websites designed for mobile apps, more often than not you’ll see they employ the same design patterns over and over: The app is displayed on a phone, aligned to the left or right; next to the phone is a tagline, and a call to action; the background is a blurred photograph usually of a coffee shop.

Do design patterns work?

Design patterns certainly appear to work. They are conventions that evolve over time, and it’s incredibly rare that a design pattern is creditable to a single individual. Like cultural darwinism, those patterns that survive to the point that they’re identifiable as patterns, must be successful.

Design patterns are also probably the simplest route to success for a web designer. They deliver proven solutions that hundreds, if not thousands, of clients have already signed-off on. What’s more, design patterns don’t need to be beta-tested, they don’t need A/B testing, you probably don’t even need to have your Mom try them out, because design patterns are tested across the Web on a daily basis and only the ones that work survive.

Employing a design pattern is the creative equivalent of painting by numbers.

But whilst design patterns (appear) to work for clients, they don’t work for designers. Employing a design pattern is the creative equivalent of painting by numbers. And if we’re honest with ourselves, we’re in this for more than a paycheck. Yes, you have a responsibility to your client to deliver the best results possible, but you also have a responsibility to yourself. If you’re not going to be creative, there are easier ways to pay the rent.

Proponents of design patterns argue that they increase engagement by providing the end-user with a common UI that they are familiar with, ensuring that a design has a shallow learning curve. That however, is an out-dated way of thinking. Sure, if you’re creating a complex app, some conventions will help your users find their way around, but it’s very unlikely that you’ll ever design a website for a demographic that has no experience of the Web.

Back when the Web was new, it made sense to make every link blue. It helped people find their way around. But a common language for links is no longer necessary because we understand where we’re likely to find links. As witnessed by the fact that the blue link design pattern is no longer omnipresent.

The problem with design patterns is that whilst they appear to work in the short term, they also have a best-before date; and no one knows what it is.

Extinction level events

Design patterns evolve like flora and fauna, the best, or perhaps just the most adaptable ideas thrive and propagate. But, like the dinosaurs that never saw that meteorite coming, design patterns encounter extinction level events.

An extinction level event is a change so rapid, that evolution isn’t fast enough to adapt to the change. The T-Rex may have ruled the forests of the cretaceous, but it couldn’t cope with a couple of degrees temperature change as well as that small shrew-like mammal that scurried past it unnoticed.

For many design patterns, responsive design was an extinction level event.

Until the explosion of mobile design, one of the most used design patterns was the holy grail layout (so called because it was considered ideal, but difficult to achieve with the CSS that was available at the time). When the mobile web introduced the need for responsive design, holy grail layouts fell out of favour because whilst they still worked for desktop, they don’t readily adapt to mobile screens.

Problems that designers have to solve don’t exist in a vacuum. The Web is a constantly changing ecosystem, with external influences, internal pressures, as well as seemingly random changes. When we use a design pattern, we’re solving yesterday’s problem, with yesterday’s solution; and we leave today’s problem unanswered.

Solving the problem with first principles

First principles is a method of logical thinking that reduces every problem down to core ideas that cannot be deduced from one another.

When you rely on a design pattern you’re taking on a problem you may not need to solve.

The antithesis of first principles thinking is analogous thinking; design patterns are analogous thinking. When you rely on a design pattern you’re taking on a problem you may not need to solve. If you style all your links blue, you’re solving a usability issue from 2000, but it’s a problem that barely exists in 2015.

By adopting a first principles approach, we focus on the core of the problem that our client actually has, without inheriting unrelated problems that are solved by other people’s design choices.