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?
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. [pullquote]Employing a design pattern is the creative equivalent of painting by numbers.[/pullquote] 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. To paraphrase Wikipedia’s superior example: All browsers are buggy; Safari is a browser; Safari is buggy. The third statement is unnecessary as it can be deduced from the first two statements. Elon Musk is a devotee of first principles thinking. Last week, VentureBeat reported that Musk’s company, SpaceX, built a space rocket for around 2% of the usual cost, simply by applying first principles thinking. [pullquote]When you rely on a design pattern you’re taking on a problem you may not need to solve.[/pullquote] 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.
Design patterns offer effective short-term solutions to common problems. However, the more prevalent the design pattern the more established it is, and the greater the likelihood that it’s approaching an extinction level event. Instead of comparing solutions, and deriving answers from other people’s answers, we should be focusing on our clients’ current problems. The Web is constantly changing around us, and design continues to evolve, by adopting a first principles approach we can produce work that is robust enough to survive online. Who knows? You might even get to be creative.
Ben Moss is Senior Editor at WebdesignerDepot. He’s designed and coded work for award-winning startups, and global names including IBM, UBS, and the FBI. One of these days he’ll run a sub-4hr marathon. Say hi on Twitter.