It's Alive: Prototyping in the Browser

My career, the Internet, and their relationship to each other have all evolved significantly since 1998. As I grew into my role as a designer, I spent much of my time designing the page-level interactions of a web project in the form of wireframes. Front-end technology and mobile devices have since become much more advanced, and the web is no longer served on one screen size or one type of device. Now, documenting these interactions through a robust wireframe document is no longer an effective or valuable use of time.

I strive for my design artifacts to feel close to the product that I am designing—something I can easily test and something upon which different collaborators can painlessly iterate. Being able to design page-level interactions in a way that enables immediate trial and reaction is now a must. I’ve tried WYSIWYG HTML editors, web-based mock-up tools, and even desktop software specifically designed for prototyping to create these artifacts. I struggled to find a piece of software that had the right balance of features and flexibility, and after repeatedly allowing the limitations of these tools to constrain my designs, I decided to seek out another solution.

Design is the tool. Browsers are the medium.

We design sites, but what we build ultimately lives in a browser to be accessed on a myriad of different devices. I see this as an opportunity to treat the browser as a medium instead of strictly as a framing mechanism. We can take advantage of the browser’s unique characteristics early in the design process by testing and iterating on things like flexible width and height, horizontal and vertical scrolling, mouse/touch events, and media queries.

The rise of front-end frameworks like Twitter Bootstrap, HTML5 Boilerplate, and Zurb’s Foundation helped renew my passion for front-end development. I tinkered with a number of these frameworks and realized that building prototypes using my old friends HTML, CSS, and JavaScript was actually more efficient, easier for clients to understand, instantly testable, and more valuable for my project team than creating a robust deck of wireframes. I also found that hand-coding my prototypes afforded me infinitely more flexibility than wrestling with prototyping software.

A prototyping method

Building something real, testing it, and iterating on it isn’t a new concept. The “way it should be-ness,” a phrase coined by Charles and Ray Eames, expresses when a design works so well its very existence is secondary to the user’s purpose. To ultimately achieve this quality requires a trial of the realized design in some form. At Happy Cog, the iterative prototyping process described below aims to create that form.

Start broad, then refine.

Before one letter of HTML is written, it’s important to have an idea of what the entire system will look like even at a very broad level; it’s nearly impossible to accurately define “pages” before knowing their contents, so I like to collaboratively sketch key features and establish key pieces of content with project team members. These features can be defined in a requirements document, through a design workshop, or maybe just evolve organically. Wherever their origin, exploring and documenting these components is essential before (and throughout) the construction of a prototype.

Get setup to build, collaborate, and re-build.

There are several ways you can set up your system to construct and iterate on your own prototypes. If you’re comfortable in the command-line, Ruby, Git, and coding in text editors, these tools might serve you well:

• Beanstalk – At Happy Cog, we use this as the version control system for most of our production code, but it also works well if you have multiple people collaborating on a single prototype.
• The Serve gem – Serve is a lightweight, local web server that allows us to use partials and layouts (just like in Rails!). With Serve, we can create and share modules across pages, establish basic page logic, and export a static version of our site in plain old HTML for easy hosting/sharing with clients.
• Sass & Compass – Allison Wagner wrote a fantastic post about the benefits of using a pre-processor like Sass. Additionally, I like to prototype with Compass (a framework for Sass), because it comes preloaded with common design patterns and speeds up development time.
• Susy – Susy is a responsive grid framework for Compass. It lets a designer easily establish a grid system and include breakpoints in a semantic-friendly way.

Create a feedback loop.

After I present work to peers and clients, I catalog and prioritize feedback from all channels in one place to help me focus on delivering the next iteration of the design while keeping the project in-scope and on budget. I create a master spreadsheet of items to address and flag those that are at risk of not being incorporated into the next iteration. This way, the entire team has a transparent view of how the prototype is progressing and what the potential blockers are.

Like any process, there is always room for improvement. This is only the beginning of a greater collaboration between design and development. It yields a higher-quality product, because there is more opportunity to refine what is being built. How does increasing the areas of overlap between these disciplines shape your process?

Back to Top