Creating Interactive Wireframes: More Code, Fewer Comps

Inspired by Matt Griffin's article on A List Apart, "Responsive Comping: Obtaining Signoff without Comping", my agency recently implemented a process for creating interactive wireframes and using a version of Style Tiles.

In our most recent project (a company website), our process looked like this (not including check-ins with the client):

Sketch Wireframes

After deciding with the client what types of content they were going to have, a member of our team, Jake Johnson, sketched out the wireframes for the site. By the time I got these sketches, Jake had already been through several drafts on his own. We then chatted a little more about the site's structure and made a few more changes as I entered into creating these wireframes with code.

Mockup Up the Wireframes with HTML/CSS and Deploy to the Web. 

Creating interactive wireframes that respond to different screen resolutions allows you to catch organizational problems early. We have added many internal discussions about the importance, or irrelevance, of the "fold," but we all seemed to agree that the most important information should come earlier in a page. Interactive wireframing allowed us to get a better sense of how a page's content would flow.

I used Bootstrap to speed up the wireframing process. It is nice to have elements already styled when you need them. That said, there was a lot of Bootstrap that this project didn't use.

I found Matt Griffin's strategy for deploying your wireframes to Heroku very helpful. This is what our process looked like:

  • Set up a git repo for the entire project (and commit your changes along the way)
  • In the root of repo, create an index page where you can post links to the different versions of your site and any other documents you want to store on the Web. This will give you a landing page for you and your clients to go to review your deliverables.
  • Create a subdirectory in your project for each version of your wireframes (v1, v2, v3 etc)
  • Every time you have a new version, duplicate the previous version's directory and work from there. (I wasn't super happy with this process. Duplicating code didn't feel right when you are already using version control. In the future, I think I will look into using a submodule for each version. That would have the added benefit of having more granular control over which version a developer can access, which might be nice if you are, say, only doing a sites front end development.)
  • When each version of is ready, deploy your code to Heroku and end up with the URL structure that Matt Griffin mentions. One thing to keep in mind: I had it in my head that I wanted to create these wireframes with 100% static HTML/CSS. It turned out that you can't deploy a project to Heroku that is just HTML/CSS. The solution was to create a single index.php file in the root of the project that had an include for the main index.html file I mentioned above. Once the php file is present, Heroku deployed the project with no issues.

Using all HTML/CSS turned out to not be a good idea for all the reasons you might imagine. At first, it was amazing to turn back the clock on Web development and just code like it was 2003. Seriously, it was a good time. Then, I remembered the hell of having to repeat code. I didn't want to use even the most basic programming to include common elements (like headers or footers) because were going to hand off this code to a partner to integrate with a CMS. So, I wanted to send them clean HTML ready for creating templates rather than have to remove lines of some other language. Because of this decision, if the header changed a little bit, I had to make that change across multiple files. That meant some changes would take ten minutes rather than ten seconds. It wasn't a huge deal, but made development a little tedious. In the future, I will look into other solutions. For me, the best of both worlds would be able to use some programming to eliminate repetition, and then compile the code to create static HTML locally using something like node.js.

Review the New Interactive Wireframes internally

At this point, we also made more decisions about how content stacks at different resolution. For example, if you have one column of content on mobile, and two on desktop, what content will you present in the left column? If you need to rearrange columns and you are using Bootstrap, you can push and pull columns using the LESS mixin:


Apply the Visual Vocabulary/Style Tiles to the Wireframes

While I worked on the HTML/CSS wireframes, our designer, Audrey Na, worked on the visual elements for the site. This particular project had a more than a dozen different page layouts, and based our previous experience, laying out each of those for phone, tablet, and desktop resolutions would have taken and lot of design time. So, Audrey instead created a few sets of static comps at desktop resolution. As she finished a page, I could start applying the visual elements to our wireframes. If I ran into a layout or element that I wasn't covered by the three or for layouts she already created, Audrey would return to Photoshop or Illustrator to think through that particular part of the design. While this process is not streamlined as Brad Frost's Atomic Design process, it worked well for us.

Would I Want To Do This Again?

I think so. However, there is one main thing I need to wrap my head around. If we are getting away from giving clients pixel-perfect comps, how "done" do we want the the interactive wireframes + design to be. For this project, we basically had all the front end work completed. (Albeit, the CSS needed some cleaning up.) Is this the logical place to end, or is there an earlier stage where you can still get the client to approve everything, without you having to basically deliver a finished-looking static site? For that matter, does it matter? If you have check-ins with your client throughout the process, having the markup/css and some JavaScript completed earlier might be a good thing.