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):
- Sketch wireframes on paper.
- Create some neater, more complete wireframes (neat sketches, OmniGraffle, Axure, etc). Throw away the paper from step 1.
- Prototype the wireframes and interactions (Fireworks, Axure, etc). Throw away the wireframes from step 2.
- Design comps detailing layout and artwork (Fireworks, Photoshop, etc). Throw away the prototype from step 3.
- 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-facecombined, 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… read them below or add one }
I really like the idea of mocking things up in HTML/CSS and can definitely see the benefits of doing so. However, I wonder if in your experience you have seen any evidence that doing it this way actually hinders the creativity of the designers and places too much constraints on the final look and feel?
I’m taking a look at Omnigraffle and Fireworks, but can see myself spending too much time architecting wireframes that will as you said, be thrown out. Yet, I can also see myself having to recode the layout once the designer changes things up a bit.
Yeah Brian that’s a great comment.
Potentially, the focus on code could constrain the final results and hinder some creativity. The ideal approach I’ve found is to iterate, and work between paper and code. So use paper sketches to explore ideas, and iterate your code with the best ideas.
Exactly – that’s the issue with Omnigraffle, Fireworks and other tools – you end up throwing out the prototype. But there are a stack of online tools around that speed up the process and are handy for quick client communication, and can be used in place of Omnigraffle, Fireworks and others. While the results from online tools are also thrown out, they’re a substitute for at least part of the typical client conversation. Of these, http://iplotz.com/ seems to be one of the more efficient and practical services.
It’s ok to throw out a prototype, as long as it’s made to be thrown out and has been super-fast to produce. Quick and sketchy – on paper or in tool like iPlotz – usually fit the bill well. Put something together quickly, chat to the client, iterate until it’s right. Then code. Then iterate from there, but the purpose of the ‘sketchy’ prototype is to avoid completely recoding a layout! If designers are involved from the beginning, you can wireframe with them and you can agree on the layout early. Then the art direction can be applied to your coded prototype and avoid too much re-work.
The problem you’ve expressed here is the main one that Microsoft saw an opportunity to address with their Expression tools. The idea was to allow you to design your pages in Expression Design, export them to Expression Web and then finally transfer them to Visual Studio for your developers to add any final back-end coding that was required.
It has a way to go, but already is fairly mature, you can see more here:
http://www.microsoft.com/expression/Default.aspx