Skip to content

Code: prototype vs production

I’m a big fan of making prototypes as part of a User-Centered Design process. I even prefer to skip doing wireframes entirely and instead use sketches, (heavily annotated) prototypes (that have been tested with users), and Style Tiles to start work on a Front-end Style Guide. For this work, a designer and a developer need to work closely together, so it can sometimes be hard to do.

I prefer more interactive prototypes that let you do stuff rather than the clickable-hot-spot prototypes that most tools offer. Since I’m a Front-end Developer, I like to make those prototypes myself in HTML, CSS, and JavaScript, rather than using a tool to do so. To make sure that I can make the prototypes quickly, I’ll often use a framework like Bootstrap or Foundation.

Throw away prototype code

This code is written just for testing the prototype, and won’t be used in production, so I let myself be a bit sloppy (e.g. don’t write tests). For the prototype how it works is more important the code quality. Another reason the prototype code doesn’t make it to the live site is because frameworks like Bootstrap and Foundation tend to be quite heavy in terms of size. There are tools like unCSS that can remove unused CSS, but I’ve have mixed results with them. It feels a little like fixing the symptom rather than the problem: I’d rather write less CSS in the first place, and have a simpler code base with lots of reusable modules.

Zurb’s Foundation

Foundation 6, Prototype to Production on the Zurb blog is a very interesting read. They set out a clear set of principles that guide the decisions they make about Foundation for both prototype and production use. The most exciting part for me is the focus on Front-end performance, starting with a lighter Theme and file size:

We’re approaching this problem two fold with Foundation 6 by styling the already minimal framework less from the start and giving users easier tools to strip files themselves.

I’m still not sure I’d use a framework like this for production code, and I certainly wouldn’t want to use my sloppy prototype code in production, but it is awesome to see Zurb trimming down their framework and giving more power to developers to pick out just the bits they want.