Nathan Curtis – From PDFs to HTML Prototypes

Podcast: Play in new window | Download (Duration: 32:14 — 16.8MB)

Subscribe: iTunes | Android | RSS

Prototypes help, be they paper, wireframes or PDFs, to exhibit a design idea. They allow you to communicate your idea visually and test aspects of the design. As effective as they are, they have their limitations.

Nathan Curtis of EightShapes uses HTML prototypes in his team’s design process. Using HTML, they test functionality and interactions in ways that are impossible while using static PDFs. During his virtual seminar, From PDFs to HTML Prototypes, Nathan discusses how his team uses dynamic documentation and design thinking. This has improved communication among the team and enhanced their process. Nathan wasn’t able to answer all the questions during the seminar. He joins Adam Churchill to address those remaining for this podcast.

Here’s an excerpt from the podcast.

“…There’s clearly start-up costs for creating an HTML prototype that are heavier than creating a wireframe PDF document. Honestly, we’ve been working with InDesign for years. As a company, we’ve got out system down for how we churn out good ideas quickly, via wireframe PDFs. And so for us to open up InDesign, open up a template, open a couple libraries, through all those things onto a screen, produce a PDF, you know, you could have a wireframe in five minutes. From just the start of a project.

But with an HTML prototype, you’ve got to set up all your folders. You’ve got to copy all of your libraries. And then you have to start marking up the semantics of your HTML to describe what the structure of your idea is. And then start layering on that CSS. And then start getting into some of the JavaScript to make those interactions happen. Suddenly, that’s not a five minute process. There’s certainly a start-up cost such that it’s almost like you’re a diesel engine.

You’re going to get out of that starting gate a little bit slower. But I’ve also sensed that, once that start-up cost has been paid, whether it’s a day of prototyping or even a four hour chunk here, a six hour chunk there. Then things start to really move quickly. That’s in part because our ability to re-use and re-factor different things becomes a lot easier. As opposed to, “Well, you want to make the header twice as large.” In HTML we just change the height from 50 pixels to 100 pixels.

But in wireframe, suddenly we’re caught going into 16 different files, having to move everything else on the page down, and all of those seemingly subtle changes end up costing a lot, too. In wireframe PDFs. So my instinct is that, yes, there is definitely a start-up cost that’s greater for HTML wireframing. But the overall cost once you start getting your engine running, and you start gaining the momentum of where the design’s going, it actually nets out…”

Listen to the podcast to hear Nathan answer these additional questions:

• Are your prototypes HTML, Flash or image maps?
• How can prototypes be successful with distributed teams?
• Do you start your designs with sketches?
• Have you ever tried to merge HTML and wireframes?
• If a designer can produce production-level code, are they more of a developer at that point?
• Do you produce production-level code in your prototypes?

Do you have experience integrating HTML into prototyping? Share your thoughts or experiences with us in our comments section.

Recorded: May, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Transcript Available ]