How Design Patterns And Component Libraries Create Unity And Context

Posted: 16 Jan 2014 05:30 AM PST

Earlier in the week I offered some thoughts about components, design patterns, and pattern libraries. In that post I shared some things about the house I grew up in and how it was built on the same plan as other houses in the neighborhood. I want to talk a little more about the neighborhood and how it created a context for each of the houses within.

Note: This post includes an audio version. If you don’t see the audio above, Click here to listen.

A few years ago my brother passed by our old house. He noticed how much the owners had changed it and the next time I was in town we both drove by to have a look. The owners had customized the house a lot.

The changes certainly gave the house a unique look within the neighborhood. It wasn’t a complete rebuilding from scratch, but it might as well have been. They added a second story, gave it a very different paint job than most of the other houses, and redid the landscape of the front yard.

If I showed you a picture of the house when I lived in it and one after the changes, you probably wouldn’t recognize it as the same house, unless you could also see the houses on either side.

Because of the changes the house stood out, though not in a good way. It stood out in more of a sore thumb kind of way. It wasn’t that the house looked bad, but it no longer fit in the neighborhood. Move it somewhere else and it might look great, but not in that neighborhood.

It broke the expectation set by the context of the houses around it. It doesn’t fit in the neighborhood anymore because it veered so far away from the original plan. The plan might have led to some less than exciting homes, but it did create a consistent pattern and context.

Creating a Unified Context Through Components

Components and patterns help create unity. They help create a consistent context. It’s why Mac apps look different from Windows apps. Each is designed to work better within the context of a specific operating system. Each is designed to fit within its own neighborhood.

It’s also why Apple and Microsoft create APIs and developer libraries. A large part is to help make it easy to develop for the platform, but those libraries also exist to help create a consistency across each operating system.

Like the houses in my old neighborhood, component and pattern libraries might lead to more of the same interfaces, but they also lead to increased usability. In the case of a living in a house that increase might not be a big deal. You have plenty of time to learn your way around your house. It’s something to keep in mind though, when designing and developing websites.

I’m guessing most sites you create have some buttons. Maybe not all, but buttons are likely a very common element on the websites you design and build.

Odds are you don’t create a new button from scratch every time you need one. You probably design a single style and apply it to a button element or maybe to a button class that you apply to a link. When you need a second button you add a new button element or add that same class to another link.

If a button needs to be a little different, for example blue instead of a default red, you reuse your button styles and override the color. Even with a different color, the buttons retain mostly the same style so that each fits within the overall context of the site and buttons on the site. On a single site you might call this a style guide, but it’s also the beginning of a component or pattern library.

From Style Guide to Component Library

You can extend your button style beyond a single site. You’d need a greater variety of buttons if you’re going to use them on multiple sites and yet the buttons you create from site to site probably share a lot in common.

Each has a shape. Each has a color. They include text inside as well as a border, even if that border is 0px wide. Each button should be clickable and change over the different states of a button. Maybe the color changes on hover and the size transforms when clicked. Perhaps your 0px border becomes 1px wide in one button state. You might even give your buttons a realistic appearance that makes them appear pressed in when being clicked.

There are a lot of different ways to design and develop a button, but the truth is most of the time any button you design is going to share a lot of similarities with buttons you’ve designed before.

I know it’s that way for me and those similarities come from my own design tastes and my own development practice for creating buttons.

When choosing the color for a button I choose from my preferred color palette. If I round the corners there’s a minimum and maximum amount of roundness I’ll use. If something is going to transition over time I’ll use my judgement as to how quickly it should change over how long a time span.

Every site is different. You wouldn’t design the same buttons for a bank and for a children’s site. Every client is also different and they’ll come with their own set of preferences. However, the first button I present will likely suit my tastes.

My preferences form my design palette and they cover a large enough range of options that I can choose something from within the palette that works for the given project, but it’s still my palette that comes from my preferences, judgement, and experience. It’s my context as a designer.

I think this is how a designer or developer creates his or her own style or voice. By choosing our palette and reusing our components we add our style to a project.

Some might argue we shouldn’t be imposing our style on a client project, but I think it’s inevitable we’re going to do so. None of us has skills for an infinite number of possibilities. We choose constraints on projects and while most should come from the specifics of the project some will always come from us.

Our style will find its way into a design whether consciously or subconsciously and given it’s going to happen anyway, I’d rather it be a conscious choice. By using component libraries that choice can be more consistent with other choices. It can be part of a larger consistent context.

Components Don’t Have to be the Same

What you save as a component for a button doesn’t require that every button will look the same on every site. For example any button you create likely includes shape, size, color, and type.

Think about all the variety that can fall within and across those 4 items. There are probably millions of different combinations of shape, size, color, and type.

You can create a component that includes all of the above, but allows their specific values to vary on each button or group of buttons. You can make different buttons unique while still using the same component to build them all.

Components and pattern libraries can lead to greater similarity across elements. That can be a good thing at times in that it creates a unified context. Similarity doesn’t have to mean sameness though. There can still be more than enough variety to keep things unique.

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

The post How Design Patterns And Component Libraries Create Unity And Context appeared first on Vanseo Design.