Responsive wireframing

There has been a lot of talk recently on the web about the best responsive design workflow, and part of that is the best way to wireframe for a responsive design. We’ve been wrestling with these topics at Storm ID too, and I wanted to share a little of how we’re working on it at the moment.

What I describe below won’t work for everyone. It may not work for us 6 months from now, but it’s working well for us just now.

Sketching is a great way to get ideas flowing, to quickly illustrate those ideas to colleagues and to get things straight in your own head. I still start with paper and a pen, roughly sketching things out. I probably always will.

It’s useful to remember that we can use traditional tools (if necessary) to generate ideas internally, and then use ‘new’ methods of presenting ideas to clients. Not everything has to be a deliverable; we just have to present deliverables in the right way. Use whatever you want to get the ideas going: paper, Visio, Axure, Balsamiq, Photoshop. It really doesn’t matter. Just remember that it’s okay to throw it away afterwards.

So after I’ve got things a bit clearer in my head by sketching, I move on to HTML/CSS wireframes.

You would be hard pushed to find many web designers today who would argue against HTML/CSS being the best way to present wireframes to the client, but many feel it’s too time consuming. I disagree.

It can be done quite quickly with a system in place

I’ve been developing a system while working on a couple of responsive sites that makes it much faster to create HTML/CSS wireframes, almost like static prototypes. I start with a basic HTML file which we have developed, a bit like HTML5 Boilerplate but tailored to our own needs, including a reference to wireframes.css, a stylesheet I wrote.

View our current starting template and view source
View wireframes.css
View an example wireframe I built for Tramway.org

This stylesheet contains a few basic styles for header margins, link colour (just adjusted the shade of blue) and the main thing: styles for [data-wf="block"] and [data-wf="nugget"]. This allows me to add data-wf="block" or data-wf="nugget" to any element and have it display as a traditional-looking wireframe grey box or white box with grey border. After the wireframing stage I can easily remove the stylesheet and the data- attributes and all the grey styling is gone but the structure remains, ready for the visual design phase. I’ve used data- attributes instead of classes as I found them easier to find and remove.

To add height to blocks without full content yet I just add <br /> tags (don’t panic, these won’t make it to production remember).

Then I start adding layout structure CSS to my other stylesheets. This structural CSS can form the basis for visual design in the browser later. You can use something like Bootstrap if it helps keep things speedy, or you can roll your own grid, as I prefer to do.

At this stage (and most of the way through development) I reference a stylesheet for each media query, instead of combining them. I find it much easier to work with a few files open in tabs than to endlessly scroll up and down one huge stylesheet.

I don’t find that all this takes me much longer than figuring out how to use Axure or Visio or something similar.

The extra time spent is worth it

Yes, it can take a little longer to wireframe in HTML/CSS. But what you lose here, you make up for later by having a solid foundation already in place to start the visual design phase. Some of your output is already done. Some of it you might need to strip out. It also gives our developers something to work with when developing the site while I work on visual design.

Building out your wireframes like a prototype allows you to work out exactly how the layout changes according to different devices. It lets you see if your thinking on paper was correct. It lets you quickly adapt when you find out you’re wrong.

It’s going to give the client the clearest possible picture of what you are proposing. They can view and test a usable web page, with links, javascript and/or CSS3 based interactions, and test the flows through the site. They can test this on any number of different types of devices they can lay their hands on. There is no guesswork needed. This is incredibly important as we support clients who are new to creating for the web, let alone experienced with responsive designs. Often, the best way to explain something is to demonstrate it. You can even set up analytics on these wireframes and get feedback that way.

It’s not supposed to be easy

I’m a designer who codes, but if you’re not, why not get friendly with someone who is. Sketch out your ideas, chat through them with a frontend developer, and have them produce responsive wireframes you can present and share with your client.

No one is saying this is simple. It’s not. It takes a huge change from ‘traditional’ processes and to start with it will take some extra work. However, the benefits for you, your clients and the final work far outweigh the initial pain.

Always evolving

This is what works for us just now. We’re always trying to look at better ways of doing things, for our clients and the agency. I’d love to hear what you think is the best way to work with responsive design throughout the process, and especially any good or bad experiences you’ve had.

Tell the world

  • http://tinnedfruit.com Jim Newbery

    Love this. You’ve nailed a couple of things which I think are really important in the process:

    Firstly, when you talk about early sketching, you say “Just remember that it’s okay to throw it away afterwards.” There’s something to be said about the intention of early sketching is to throw away as much as possible. This is all about creating as many ideas as quickly as possible without bounds, then using those temporary visual documents as a means to have a discussion or do some guerilla usability testing, at which point you start reining in and filtering ideas.

    Secondly, I like the point about designers who do/don’t code. It really doesn’t matter. If you don’t code, collaborate in the design process with someone who does. If you do, collaborate anyway. I come up with far better ideas when I steal them from other people they come out of enthusiastic collaboration. And I’m a developer who designs.

  • http://www.roundedworks.com Wayne McManus

    Thanks for sharing, very interesting insight in to your process and will definitely be taking a few pointers in to my next project.

  • http://www.wizard-solutions.co.uk Fabio

    Thanks for sharing, much appreciated. I like that you have a system in place, it does make the design process faster (overall) in my opinion.