Adopting Pre-Made Design Patterns Doesn’t Help With The Toughest Parts

A well-built design pattern library is an extremely valuable tool for highly productive design teams. It ensures the designs they create feel like they were built by the same folks. It helps everyone on the team understand how things get put together. When combined with a component library, it can shorten development time by using common code.

Building a library takes time and effort. Many teams look to short cut that effort by using one of the many pattern libraries available on the web. Their thinking is why invest the effort of building something someone else has already created.

Many of those libraries are well thought out and filled with useful patterns. It makes sense to want to adopt them as a starting point or even as a their entire library. However, we’ve found that adopting the patterns from a pre-made library doesn’t help teams with their design for several reasons.

The Devil’s in the Application-Specific Details

First, the patterns in the library are often simple, generic design elements, such as a menu or tree navigation. They are things that you’ll find in every application. That’s great, but those aren’t usually the design elements a team struggles with.

Say a team is building an application for discovering a course schedule and registering for classes in corporate training. The generic menus and navigation isn’t what’ll make designing that application difficult. It’s the application-specific stuff that’ll keep the team the busiest. What should a course listing look like? What are the key components of the registration process?

None of these application-specific elements will appear in any third-party generic library. The team will need to build them anyways. Because there aren’t plentiful models of these things already in the world, there will be lots of debate about how to do it right.

Generic Doesn’t Look Right

Second, the third-party library won’t take the application’s look and feel into account. Using those patterns will create generic looks and behaviors. In this day of mult-device design, we often have to decide which elements take on the look and behavior of the device and which stay common to all of our platforms. A well-designed library can help us with this, but pre-made libraries usually don’t tackle that.

Building the Library Also Builds A Connection To It

Third, there’s real value to having the team members build library elements themselves. The process of creating a description of an element, even if you’re using a condensed format, makes you look and think about that element differently.

We’ve met teams who ask their members to contribute one or two elements to the library to get it bootstrapped. They pick something close to their own passion, something they are particularly proud of, that they’d like to see used right everywhere.

Some have a small ceremony for putting something into the library. It gives them a chance to make everyone aware that the library is growing, while giving the team members a change to talk about how the new element will be used.

Using a third party library doesn’t get the same level of investment from everyone using it. It’s cold and distant – just one more piece of documentation they need to deal with.

That doesn’t mean you can’t borrow some of those generic library elements for installation into your own library. However, I’m betting you’ll quickly find that even that won’t be worth the effort, as they won’t be written to match your library’s format. It’ll be easier to create your own from scratch.