I’ve been prototyping in Fireworks for years, and it’s great; until I need to iterate the prototype. In an effort to find a fast iterative prototyping method I’ve finally settled on Blueprint. It’s efficient, easy to use, and above all, real. Nothing beats real code. Read on to discover why mocking up with markup is a good idea.

Here’s the simplest view of a typical agency approach to user-centered website production (sans research, content strategy, and lots of other important bits):

1. Sketch wireframes on paper.
2. Create some neater, more complete wireframes (neat sketches, OmniGraffle, Axure, etc). Throw away the paper from step 1.
3. Prototype the wireframes and interactions (Fireworks, Axure, etc). Throw away the wireframes from step 2.
4. Design comps detailing layout and artwork (Fireworks, Photoshop, etc). Throw away the prototype from step 3.
5. Code it up. Throw away the comps from step 4.

Why this is broken

The most obvious issue is wasted effort. Spending so much time doing what is essentially re-work to get to a coded design means less time on  critical user experience elements like interaction and user journeys. Essential UX devices such as page-specific call to action design and bespoke content layouts can’t be achieved without a fat prototype and stack of design comps, which takes (too much) time.

The best approach? Get a mockup coded and into the browser. Not a semi-usable prototype. A prototype that feels real enough that it could be an un-styled website. If you ran out of cash for artwork you could launch it. That’s how real it should feel. Use real copy and a full IA. Iterate, iterate, iterate. In the browser, with code. Then design it.

Andy Clarke recently gave a must-see presentation on why the old approach to web design sucks. Aside from the obvious issue of wasted time, Andy highlights some other shortcomings;

While static visuals are useful for conveying look-and-feel, they are less than useful in conveying how a page will look and function when implemented in markup and CSS. Without a great deal of effort and perhaps multiple design files, static visuals cannot demonstrate:

• the effects of liquid layouts
• what will happen when text sizes are changed
• the font stack
• browser inconsistencies
• simple interaction such as :hover and :target
• JavaScript behaviors or dynamic AJAX content

Worse still are the expectations that static visuals set in the minds of clients, particularly when designers use these visuals as a method to get sign-off for a design. Is the fact that so many web pages are fixed width and centered a direct result of clients signing off fixed width design visuals?

How we can fix it

The quick answer is to skip from step 1 (paper sketch) to step 5 (code), iterate, and add design elements and artwork as the prototype matures.

Get working code online, test, iterate, and add some design elements as you go along. Think of it as a repeating loop, not a step by step design process.

This approach highlights issues with the mockup faster and allows more time for critical user journeys and bespoke site templates. In Andy Clarke’s words:

When I spend more time designing and developing than I do managing, my clients get a better job and I am more satisfied with the result. These are some of the areas that have made a big difference to me.

• Coming up with new and better workflows
• Designing in the browser
• Learning to live with constraints
• Designing systems, rather than sites

In summary: Achieve better user journeys faster by mocking up with markup.

How to do it: Hello, Blueprint

Methods for iterative prototyping are receiving good airplay at the moment. There’s been some good discussion at IxDA on the best approaches, Konigi is assembling a promising framework and Todd Zaki Warfel has penned a new book breaking down the options. Amongst the chat Blueprint is typically well regarded. Importantly, I’m fairly sure the world-beaters at Clearleft and Blue Flavor sling Blueprint-inspired code whenever they can, so that speaks volumes to me.

I’ve done some wrangling in Blueprint, and it’s great. If you know some basic HTML and CSS – and hey, if you’re a web pro of any flavour, you should – you’ll get a handle on Blueprint fast enough. Montoya and co have done a lovely job with the online demos; I poked away with Firebug for about 15 mins, copied the demo code and had some (rough!) mockups hacked together inside an hour.

How I work with Blueprint

I sketch on paper first. Paper sketches are limited to 5 minutes each, and are usually done within 2 minutes. I sketch a few different ideas, then take the layout that feels most successful and put it together with Blueprint. I try a few different approaches – I continue to sketch with both pen and paper and code. I’ve found time taken to mockup with Blueprint is comparable to mocking up with Fireworks, if not faster. The initial layout takes longer, but testing and iterating is way more efficient. And testing and iterating is where you should be focusing your time anyway. Fireworks is still great for interaction design, but when I’m mocking up and need to create real prototypes, Blueprint’s the clear winner for me.

Re-using your Blueprint prototype

I assume at least a few smart peeps are integrating frameworks such as Blueprint into their development workflow to avoid re-coding. There’s also a method for cranking Blueprint code into a WordPress theme (using a child Sandbox theme, for the WordPressers out there). So there’s definitely some possible code re-use, which is great. In any case, the prototyping results from using Blueprint are well worth the toil. Mocking in markup lets you identify problems faster, iterate faster and gives you the chance to re-use your prototype.

Beyond Blueprint

Meagan Fisher’s 24 ways article on mocking up in markup has me all riled up to learn some better front-end development skills. Here’s why:

In the past we’ve put up with Photoshop because it was vital to achieving our beloved rounded corners, drop shadows, outer glows, and gradients. However, with the recent adaptation of CSS3 in major browsers, and the slow, joyous death of IE6, browsers can render mockups that are just as beautiful as those created in an image editor. With the power of RGBA, text-shadow, box-shadow, border-radius, transparent PNGs, and @font-face combined, you can create a prototype that radiates shiny awesomeness right in the browser. If you can see this epic article through to the end, I’ll show you step by step how to create a gorgeous mockup using mostly markup.

Wow. Again, iteration efficiency wins:

Making color changes is another groan-inducing task when working in Photoshop. Finding and updating every background layer, every drop shadow, and every link can take forever in a complex PSD. However, if you’ve done your mockup in markup with RGBA and semi-transparent PNGs, making changes to your color is as easy as updating the body background and a few font colors.

Awesome stuff.

If you’re mocking up in markup, what’s your approach? Have you found a clever way to integrate your prototype and development workflow to minimise re-coding?

{ 3 comments }