We help you get
closer to your customers.

Reflections on a pattern based web

These days, I am encountering more and more sites focused on providing a library of pattern based user interface models. Sites like UI-Patterns , Yahoo! Design Patterns and the design focused Konigi are some interesting examples. There is also a much anticipated book, targeted for release this month, specifically aimed at explaining Web 2.0 design patterns . All this movement on the UI pattern front makes me wonder; in a world where competition is king, how should designers balance the newest and coolest interaction models with the tried and true patterns that their competitors may already employ but their users are almost guaranteed to understand?

Below are two of the many reasons that UI patterns, in my opinion, are a great addition to the web community without affecting our individuality as interface designers.

Providing an “interface designer in a box” for developers without access to design resources

We all know the (internet)age old tale: Company X wants a web application, awesome developers know how to build the desired web application, but no one designs said web application, beta web application is launched and users are unsure how to use web application. In these all too common cases, most user interface decisions are made on a few principles

a) Get it done: what UI can the developer come up with so that the function works?
b) The bottom line: what is easiest and fastest to implement?
c) The boss’ white board: how did the stakeholder design it?

By gaining access to UI patterns, developers (and stakeholders) are quickly able to read about design options and rationale for those options. This may lead Company X to make a better overall UI decision without the help of a UI designer. In cases like Yahoo! they can even gain access to the source code to get the desired interaction.

Working together to raise a more learn-able internet

While differentiation in the marketplace is important for the key functionality and content of your site/application, there are some features which are utilitarian in nature and can be looked at from a UI pattern angle without concern for becoming “too Vanilla”. Carts, Logins, Pagination schemes, and Date Range Picking are great examples. If a user has to figure these features out on a unique basis for each site they visit, we are lowering their ability to learn that interaction model, and complete their task faster and with more ease. By working together to provide consistent treatment for these types of features we are really relieving a large percentage of the user’s burden of use and instead allowing them to breeze through to the more interesting features (i.e. what your site/application actually does) that they came for in the first place.

As we quickly approach the cross-road between design individuality and the use of UI patterns, I think we should remind ourselves of a simple fact. In order for a pattern to become a pattern, someone has to design it the first time…and that someone could be any of us.