Components, Design Patterns, and Creative Solutions To Custom Problems

Posted: 13 Jan 2014 05:30 AM PST

I grew up in a house on suburban Long Island. The house was in the middle of a neighborhood where all the houses were built on the same plan. They were all built from the same design pattern.

Our front door opened into a short entry way. On one side was the living room. At the end of the entry way on the other side was a longer hallway, with entries into 5 other rooms. Along one side you’d encounter kitchen, bathroom, and a bedroom. On the other side was a bedroom and the master bedroom.

Every house in the neighborhood was essentially the same. The pattern was flipped at times. The living room in my house was to the right and in others it was to the left. Some homeowners customized things by adding an additional room. We had a den off the kitchen. A friend had an additional bedroom connected to one of the other bedrooms in the house.

Would these homes have been better had each been unique? It’s hard to say. The sameness made things less interesting, however, building this way was clearly efficient and kept costs down allowing families to own homes. It certainly made it easy to know where the bathroom was when visiting friends.

Better comes down to perspective. In this case what do you as the buyer consider more important in a home. Affording one or having a house custom built specifically and uniquely for you.

I share this story of my upbringing because I want to talk about patterns and modularization, though in regards to web design and not the architecture of one suburb on Long Island. I also think this story fits well with the productivity and creativity conversation I often have here.

The Good and Bad of Components and Pattern Libraries

I’ve talked in the past about modularization and don’t want to rehash everything I’ve said before. You can view posts in the archive tagged modular if you’d like more than what’s here.

Pattern libraries have existed for a long time, probably since shortly after someone discovered they were building the same thing again and again.

When we work with components and patterns we work with larger and fewer blocks. There are still more than enough to form unique wholes.

This past summer Brad Frost posted an article about atomic design in which he talked about developing design systems as a opposed to a collection of web pages. The post also announced Pattern Lab, which as you might guess is a collection of design patterns, in this case, classified under chemical names like atoms, molecules, organisms and so on.

Much like the plan that housed my early years, pattern libraries are created to help develop more efficiently. The library builds reusable components, which are combined into ever larger patterns, which eventually become templates for web pages and websites.

One designer who isn’t crazy about the idea is Mark Boulton. Mark is someone who’s work I admire greatly and so when he argues against designing this way I naturally listen and think deeper about the issue. Mark summed up his feeling about designing component up in this tweet.

I’m not sure we can create great web experiences by designing the bits first and hoping they all come together and work beautifully.

Mark shared more thoughts in his post, Design Abstraction Escalation. He argues we lose something when we design around components. We give up a sense of humanity in our work and replace it with a manufacturing process. We give up creativity in the name of productivity. Mark expects to see a sameness in design that I saw in a neighborhood many years ago if we follow this component path.

However, he doesn’t necessarily have anything against collecting patterns. In fact he does that himself, but he never uses these patterns directly. The act of collecting them reminds him they exist and when he decides to use something similar on a new site he recreates it from memory, ensuring it ends up being unique.

The library becomes inspiration, a starting point for recreating something unique, instead of as a machined part to be assembled.

Punch Cards, Assembly Language, and Higher Level Programming Languages

Computers speak in states. A circuit is open or closed, on or off. Everything is essentially a 0 or a 1. Computers speak a binary language. Human beings can speak it too, but not easily. In the early days of computing you communicated with the computer using punch cards. A spot on the card was either punched or it wasn’t representing one of two states.

As you might expect it wasn’t particularly efficient. Punch a hole where you meant not to and you started again and who among us can look at a series of holes and non-holes and quickly understand what instructions are being given.

Assembly language is a somewhat more efficient way of communicating with the computer, though it also involves a lot of 0s and 1s and it’s written specifically for one type of computer architecture. It’s also not that easy to work with. While it’s a language close to the way the computer speaks, it’s far away from how human beings speak.

Our conversation with computers has evolved to be more in tune with how we communicate. Assembly gives way to higher order programming languages and humans are better able to write programs. It continues as we build reusable patterns we know work to handle low level details like memory management.

Programmers can then move up the abstraction chain working to solve higher order problems while the lower level details are dealt with by the pattern. Nothing prevents you from recreating that pattern anew for a specific project should you desire, but not having to allows you to solve higher level problems.

Patterns, Constraints, and Creativity

It’s hard for me to disagree with Mark’s thoughts above. I prefer custom solutions to unique problems over cookie cutter solutions to lots of problems. I want creativity. I want interesting. I want the custom and unique.

At the same time I understand not every problem is entirely unique or needs to be seen as unique. As I talked about last week, different clients have different needs and wants. They’re going to seek different solutions. Many can’t or won’t spend what’s necessary for the unique solution. Good enough is good enough and here patterns can help us keep costs down to serve a section of the market.

I also don’t think all creativity is lost when we fall back on patterns. In fact I don’t think much, if any, has to be lost at all. Creativity and productivity aren’t as opposed as we sometimes think.

Every website is a combination of components. Designers combine blocks to build something larger. Each block can be the same as others or it could be unique. They can be different shapes and size and color. Blocks that look the same can be developed in many different ways. Design is how we combine these same and different blocks into a whole. Many different wholes can be formed from even a few similar blocks.

When we work with components and patterns we work with larger and fewer blocks. There are still more than enough blocks to form unique wholes. Larger and fewer blocks don’t negate creativity. They don’t prevent the creation of something custom or unique.

There won’t be quite as many different combinations, but isn’t removing possibilities something we do all the time? Don’t we start a project by defining constraints in order to eliminate an infinite amount of possibilities, reducing them a manageable few?

Working with fewer and larger blocks doesn’t mean we have to lose creativity and custom. Perhaps it increases the odds of sameness, but that’s just one more challenge we get to overcome.

Grids are Patterns

What are grids? They’re patterns of space. They reduce an infinite number of possibilities to a manageable few in the name of order, logic, and efficiency. They’ve also been accused of leading to a sameness in layout and design.

A grid doesn’t suggest there’s only one location for an element, however. It allows for a variety of different locations for any element and provides far more combinations for the location of all elements. A grid is a constraint in the same way a component or pattern is a constraint.

Nothing, of course, requires you to use a grid or even place every element on the grid should you use one. Nothing requires you to build from components and patterns or from using a particular component or pattern even if you do use them.

Summary

Components and patterns are a form of constraint. They combine small blocks into larger ones and reduce the number of blocks we play with. Fewer and larger blocks do reduce the total number of possibilities, but not to the point where we can’t still build creative, custom, and unique wholes.

Yes, it increases the likelihood of sameness, but it doesn’t require it. Sameness is not always a bad thing either. Not every design needs to be custom. Sometimes good enough is all that’s required for the specific problem.

In exchange for the ease and efficiency components and patterns give us, we take on the responsibility of knowing when sameness is ok and when a custom solution is preferred. Creativity and humanity are lost only if we allow them to be lost. Neither is dependent on what kind of blocks we play with.

If you liked this post, consider buying my book Design Fundamentals

The post Components, Design Patterns, and Creative Solutions To Custom Problems appeared first on Vanseo Design.