Online Surveys = Ongoing Insights

Working With Design Patterns

Working With Design Patterns

Howdy folks, Chris Coyier here from the UI team at SurveyMonkey. I worked on Front End Development stuff for Wufoo before our glorious merging. Now that our teams are together out here in the Palo Alto, California office we are learning from each other and bringing the best ideas from both teams to both products. This post is going to be about web development, in other words, probably only of interest to other web development nerds. Fair warning!

One of the things I think we did well at Wufoo is how we handled CSS (Cascading Style Sheets, the files that control how a web page looks). I recently gave a presentation that touched on much of that. The part I’d like to focus on is design patterns and how they can work in a web app environment.

What is a Design Pattern?

A design pattern is a standardized way to handle a user interface scenario. Say there is more content than is possible or practical to fit in a particular area all at once. A design pattern to handle that is “tabs”. You separate that content into logical groups and then have clickable tabs for a user to hide/show those groups.

A simple “tabs” design pattern in use on

There are lots of design patterns. For example: buttons, loading indicators, breadcrumb navigation, search fields, and dropdown menus, to name a few. Yahoo has a design pattern library and Patterntap is another good resource for research and inspiration.

Usage of Design Patterns in CSS

The word “pattern” is appropriate. It implies that the design is repeated. That jives well with CSS. The whole idea of CSS is abstracting away design from content. So the best CSS you can write is CSS that is highly reusuable. Let’s say you write one section of CSS to style “tabs”. Then you have one page on your site which has three sets of tabs in different places on it. That CSS applies to all three tabbed areas. Repeated areas. Reusable code. Pattern.

Making your CSS highly resuable has some pretty swell benefits:

1) Speed – the more reusuable your CSS is the less of it you have to write. Smaller files load quicker.
2) Efficiency – write once, use it everywhere. Don’t waste time re-writing code you’ve already written.
3) Consistency – gives your app visual consistency which helps users learn how to use it faster.

Basic Usage

If your app is pretty simple, you might just have one global stylesheet (CSS file). You might organize the CSS file to have sections for each pattern:

/* Tabs */ .tabs { list-style: none; } .tabs li { float: left; border-top-left-radius: 5px; border-top-right-radius: 5px; background: #ccc; margin: 0 10px; } .tabs a { color: #333; } .tabs li.current { background: #333; } .tabs li.current a { color: white; } /* Another pattern */ /* Another pattern */

Growing Pains

The above simple technique of having one global CSS file might work great for you. If you have a fairly large app (I would consider Wufoo and SurveyMonkey to be fairly large apps) this may start getting problematic. Two reasons: 1) That file might be humungous and hard to navigate 2) That file might have lots of stuff in it that any particular page might not need (i.e. bloat).

An example of the in-progress set of SurveyMonkey design patterns.

We can solve problem #1 by splitting all of our design patterns into different files, like:


That feels good. It breaks our CSS into logical mental blocks. It’s nice when a digital workflow can accommodate our brains whenever possible. But now we have lots of little files. Even if we only load the ones we need on each page, that’s still not particularly efficient. Each of those files means an additional HTTP Request, the biggest killer for page loading speed.

Advanced Usage

The solution here is to keep our design patterns in separate files but to do some “resource concatenation” so those files can be combined and served as one single file. Best of both worlds.

One way to do this would be to use a “preprocessor” for CSS like SASS or LESS which, in addition to concatenation, do lots of other fancy things to extend CSS.

At Wufoo we’re toying around with LESS but haven’t started using anything in large doses in production yet. But we do keep our design patterns in separate files. We have rolled our own on-the-fly resource concatenation stuff that works for us.

In general, I think a good method for “large apps” is to load two CSS files per page:

  1. global.css – Loaded on every page of the site which contains things used on every page like structure, typography, and the most common design patterns. This makes maximum use of browser cache.
  2. site-section.css – This is for CSS specific to a particular section, and less common design patterns.

However you want to concatenate the files is up to you and the needs of your app. At Wufoo, for example, our concatenation function also adds a version number into the file name (e.g. style.12459.css) that increments as we push out releases to the app, which breaks browser caches and makes sure users get our latest CSS.

Sneak Peek

I’m happy to say that while these ideas are not yet implemented on SurveyMonkey, we are actively working it. Our design team is working on lots of new stuff. This new stuff is going to be quicker to develop because of this shared library of design patterns. Nobody will be replicating work that is already done and things will be consistent across the app.

When we finish up our design patterns (well, this type of work is never “finished”, but when it’s ready enough for production) we’ll share the work here. But for now, sneak peaks!


What do you fine front-end folks think about the idea of design patterns? Have you used the idea of keeping them in separate files in your own projects?

  • Pingback: Web Design Weekly #17 | Web Design Weekly()

  • LESS is less. I have spent the past three years working with SASS and LESS and I can say without a doubt that as you try to advance the application for your needs, LESS will not provide the support you are looking for.

  • As you Chris pointed out at the beggining section of the post, the Yahoo team seems to be doing design pattern things that they call ONE (One Network Experience), and I think they are doing pretty well.

    I recommend you guys a book by Nathan Curtis called ‘Modular Web Design’, in this book Nathan dive us into the design of reusable components. In there, he goes quite far by taking the whole process from sketching to the final production version and also tackles documentation. Documentation in design patterns is huge!.

    I now know that this is a worth and well rewarded thing to do, but it also has a total shift in the way you think and the way to approach web design. It´s hard to implement in a team, sure!, but I believe the benefits are wonders.

  • Pingback: Link-urile săptămânii 17-23 octombrie | Staicu Ionuţ-Bogdan()

  • Harold Whitiker

    Hey, great stuff Chris. What do you think about the Assetic asset manager which has a lot of functions to handle much of what you’ve discussed here? Do you ever intend to publish more information about your homebrew scripts for asset management and versioning?

  • Pingback: Working With Design Patterns | SurveyMonkey Blog | CSS Chops()

  • Pingback: Working With Design Patterns | SurveyMonkey Blog |

Inspired? Create your own survey.

Make your own survey.

Sign In  

Sign up to get started.

PRO Sign Up   Sign Up FREE  

Get expert survey help

Get expert survey help

Best practices for planning expert surveys

Planning makes writing your survey easy.

Download eGuide

How many responses do you need?

Use our sample size calculator to find out!

Calculate now

Analyze survey data like a pro

Learn to slice and dice data using the Analyze tool.

Download eGuide