“To design responsively, one must prototype responsively.”
– Martin Ridgway, 2013
Quoting myself. A good start. But honestly, the statement above is important. After all, how best to communicate principles of responsive design but to do it as early in the engagement as possible?
However, prototyping should be fast and iterative. As of January 2013, standard prototyping tools like Axure and Balsamiq don’t provide easy interfaces for creating responsive designs that work. Which means only one thing: We need to get our hands dirty with some responsive HTML frameworks.
Responsive frameworks provide a fast, easy way to develop prototypes. All you need is a little HTML knowledge, and the ability to read documentation.
1. Which framework should we use?
I don’t have a horse in this race. I recommend taking a look at the excellent Responsive CSS Framework Comparison Chart and figuring out what kind of features you’re looking for from your framework, and how it fits into your overall workflow. The options presented here aren’t your only choices, of course. But they are probably the frameworks with the largest user bases, and large user base (generally) means better support.
I like all three of the options presented on that chart. Twitter Bootstrap is excellent (and I’m using it to design responsive prototypes on a current project), and is particularly well-suited to web application prototyping, due to its superb default form styles. The other options are good for when you may not want such high-fidelity mockups this early in the design process.
2. Fitting a responsive prototype into your workflow
Good UX Means Good Business
In a world where technology is rapidly advancing and user expectations are rising, it’s no longer enough to have an average user experience; to delight your users and surpass your competition you must strive for the exceptional.
Again, this is a very personal choice. Me, I like to replace static wireframes (that are of a fidelity greater than sketches) completely where I can. I just don’t see the point of duplicating work. Sketching is very different, of course, and is the absolute best way to get ideas down quickly. But once you have a set of sketches, why not move to responsive prototypes? I can guarantee that the sooner you start thinking about your site/application responsively, the sooner potential problems with your design will rear their heads, and the sooner you can solve those problems.
So when should you start your responsive prototype? You know your design methodology better than me. If you’re a sketcher (like me), then try my approach. Just launch right in! But if you prefer to use a higher-fidelity static wireframe as your starting point for a responsive prototype, go right ahead! There’s no right or wrong answer. Like everything on the Web, the answer is a definitive “Maybe”.
3. Benefits of responsive prototyping
I’ve already mentioned one in the previous section, but a full list of the benefits (as I see them) to prototyping responsively are:
- Sets the expectation as early in the design process as possible that this is a responsive design, and provides the interface to demonstrate as much
- Speeds up design, and cuts down on repetitious work (i.e., a static set of wireframes followed by a prototype)
- Creates a consistent user experience across the prototype
- Provides a solid code base from which a development team can work.
Go forth and prototype responsively. You’ll thank yourself later, I promise.