A Transcript of the podcast…

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.

Adam Churchill: Welcome everyone to another episode of the SpoolCast. Earlier this spring, Nathan Curtis joined us for a special EightShapes online seminar, From PDFs to HTML Prototypes. Wireframes, PDFs, paper. There you have just a few examples of prototypes. They help create, communicate or test design ideas. Those and others like them surely have a plethora of success stories. But one of the things we've learned is that they also have their limitations. The team at EightShapes are thought leaders in design documentation.

This seminar, their story, is their journey to where the documentation, in this case prototypes, has evolved to reflect richer interactions and more dynamic user experiences. Nathan Curtis, a founder and principle at EightShapes. Is leading the charge of his team to integrate HTML prototypes into their process. And during the seminar, he showed us how and why. So he's offered to come back and tackle some of the questions we didn't get to address in the seminar. Hey, Nathan. Welcome back.

Nathan Curtis: It's good to be back. Thanks for having me.

Adam: Now folks who didn't listen to this particular seminar, you can get at it at UIE's User Experience Training Library. There's 60 recorded seminars there at this point, from experts just like Nathan Curtis and Dan Brown from EightShapes. Nathan, for those who weren't with us that day, can you give us an overview of the presentation?

Nathan: Yeah. We spent about an hour and a half talking about a range of aspects that described our journey as... EightShapes, we're a user experience design firm that has used PDF wireframes. Those big PDF documents that you iteratively review to get feedback on your design. And we've been transitioning to using HTML prototypes to replace that. It's been a journey for us. And so, in the first of three segments of that virtual seminar, we talked about the contrast of the two artifacts. We have these PDF documents.We have these HTML prototypes. When is one better than the other?

Actually, often times, how do we balance producing both of those artifacts to greater or lesser degrees? Based on the needs of the project or really the spirit, or the tone, of culture that we're designing within. And then the next or second of the three segments... We focused in on the actual skills. Once you make that commitment to produce HTML prototypes, it's really important to have the skills to do HTML, CSS, and even JavaScript. And those coding skills are required, they're table stakes, to produce those things.

But you don't necessarily have to be a production level coder and an expert in all those technologies to produce a prototype and share a design idea. We try to clarify that distinction and set those expectations right. Then at the tail end of the virtual seminar, really that third part, we began to explore some of the changes to the process that we realized. How is it different to get started with HTML prototypes, versus starting a PDF document?

How do we set our client's expectations around what we're going to produce? How do we collaborate with people differently? For example, the relationships of me, as a user experience designer, with my UI tech on our design team. With the developers that consumed our designs, to actually build them out. All of those relationships changed. And really, why did they change and how do we need to be able to adapt to those changes, over time, in our process? Those are the three segments that we covered. It was a lot of fun.

Adam: It was a lot of fun. We had a great audience that day that asked a ton of fantastic questions. You've gone through and picked some out that we want to tackle today. Let's get to those. There were some folks that wanted to know more about your prototypes. Are they HTML, Flash or image maps?

Nathan: Actually, that's a great question. Because there are a ton of ways that you can produce prototypes. And in fact, one could argue that the PDF documents, those wireframes in there, themselves are prototypes. A precursor to the actual, finished design. Usually, in the user experience community, when you're talking about prototypes, there's a range of different tools that folks use. There are some very popular and really effective ones.

Axure comes to mind, for example. There are also those that have some Flash experience and may use Flash Professional, or even the new Flash Catalyst, to produce prototypes. So while there's a range of different choices that folks have, we've begun to narrow to using HTML for our prototypes. Actually, hand coding the HTML. And so people ask us, "Why don't you use those tools that produce flash based prototypes?" Because Flash affords you all of those nice transitions and UI effects to express your design ideas in a very fluid way.

And we found that those are pretty hard to actually maintain over time. While they do give you that nice suite of interactive tools and a baseline to code them all up, it doesn't end up feeling as natural either. Because it's still bound into this Flash movie that's within the page. Rather than, when someone's experiencing your prototype through a browser, they're actually experiencing the whole page. So that problem of it still being somewhat of an abstraction of what a page design that's ultimately built in HTML will feel like.

Plus the maintenance challenges that that has really drifted us away from using those Flash based tools. And the same things goes for something like Axure. And other tools that, while they may spit out HTML as an exported artifact that you end up using. At the same time, if you want to, say, move a header up and down, you have to go into all these different pages. And move these objects around the canvas.

Because the canvas ends up being, still, relatively static. Rather than something that flows the page down, like actual, natural HTML does within a browser. That's what it's meant to do. Finally, we just felt really strong about getting into the medium of the material of the pages themselves that we design for. And by understanding HTML and CSS and JavaScript, we're not just choosing that as the way to prototype. But we're heightening our skills and understanding what those technologies are.

So that we understand what their capabilities are. We're more familiar with what their limitations are. And the conversations we have with the engineers on our projects can be much more fluent and effective. So, that's really how we settled on HTML based prototypes and manually coded HTML prototypes as the direction we went. But we still see a lot of value and, honestly, will use some of those other technologies or techniques, from time to time, too.

Adam: Carissa asked a question. She wants to know how prototypes can be successful with distributed teams. And you and I were kind of wondering, well, is Carissa looking for help with the people that are actually creating the prototype? Or is it the people that they're creating the design for? The very specific clarification we got back was, "Yes, both." So she's got a situation where she's actually thinking about both ends of that question. Can you speak to both of them for us?

Nathan: Well, sure. Actually, I'll start with the teams that produce the prototype first. And then I'll talk about those other folks that end up consuming the prototype that gets built. For us, at EightShapes, we actually work in a distributed environment. And that forces us to hone our skills on how to share our design ideas remotely, from one another. I think her question got to the root of the fact that they have UI designers, content strategists and developers, visual designers. They're all distributed in different places. And her clarification also amplified that those folks still aren't the people producing the prototype.

Instead those types of disciplines are still trying to communicate with an engineering staff that are going to actually build the prototype itself. That's actually not something that we work with. Because our teams, our designers, are the folks that we're charging with, "Build the prototype yourself. Express the design yourself." So a lot of the challenges that she may run into in that communication between design staff and engineering staff or development staff to build a prototype, those are often the same kind of challenges you're going to have to build a final product.

The actual challenge that I found a little bit more interesting about her question was, well, if you had multiple designers collaborating on a project to create an HTML prototype specifically, what are some of the things that are going to enable you to communicate better? Clearly, since you're going to be sharing a code base, you're going to be authoring HTML and CSS and JavaScript together. Having that start-up meeting where you're setting up your roles, who's going to building what. You're chunking out that work.

You're setting up baselines so that you have a good naming system that you'll all share is going to be important. And that you're all using those same kits to get started. Like, "OK. We're all going to use JQuery." Clearly can't have one designer using JQuery and another designer using YUI as their JavaScript libraries. And just wanting to mesh all of those together, because that doesn't make a lot of sense. The next thing is that we talk a lot about our disparate or distanced designers sharing their files. We use Dropbox.

There are lots of tools that enable you to share files back and forth. But almost trying to replicate that spirit of paired programming and think about it as paired prototyping. Where we may sit together and share our screens. And try and construct various pieces together. More often, we may end up just being more disruptive to each other. For example, I'll sketch out an idea, take a picture of it with my phone and then I'll send that picture to another teammate of mine.

And queue him up and say, "France, I've got this picture in your email inbox. Do you have five minutes to talk about it? Because I want to translate this into the prototype." And maybe the conversation goes for 15 or 20 minutes. But it's not too disruptive and by the end of it we're actually starting to get into the code to prototype the actual behavior and then I can move on and continue. And France retains that sort of continuity with understanding where the design I'm working on is moving towards.

The other part of her question had to do with, how does this really improve the nature of your communication to those that consume your prototype? I want to contrast that with the nature of this remote collaboration that you'll have with people who are consuming a PDF document. You know, there are pros and cons to that. The nice thing about a PDF document is that it helps you tell a story to the people consuming your design in design reviews or trying to understand it later when you're not there. You can really frame a lot of the narrative around your design and what your design intents were. And what some of the specs were. And in document form, it's a lot easier to read through that, as if you're reading a story.

But at the same time, prototypes yield more direct understanding of what the experience is. At least from the outset. And so by trying to establish an understanding of the experience during those design reviews, we try to start it with, "Here's where the prototype is. Go here. Here's the URL." So that they can experience that prototype, not just during the design review. Or really as you're walking through and sharing your screen, they may want to open up a browser and follow a different path. But at the same time, they'll always know where to bookmark it then, too.

And retrieving it through their browser, where they spend a heck of a lot of time, probably, over the course of their day, is probably a more familiar place for them than Adobe Acrobat. Where they may not spend that much time or may not be that well versed in all the different nuances of how to navigate documents in a PDF viewer. Lastly, clearly, if you're remote collaborating and that remoteness includes testing users, there's no comparison.

Having a prototype there is absolutely essential to get feedback, relative to some PDF document. Because you're not going to walk someone through your PDF specs to get user research outputs out of that.

Adam: Tell us a bit about how the design process starts at EightShapes. Do you typically start your design with sketches or sharpie sketches?

Nathan: Yeah, we've been doing that for a number of years now where, when we start off projects, we'll get the blank paper, we'll get our sharpies out and we'll just start sharing a lot of our ideas. We've gotten to the point where, when we're with our clients, as an inny or an outty consultant, this applies either way. You really have those design tools, those materials in front of you. Just to start cranking away on ideas and gaining consensus understanding. Even in kick-off meetings. It's all about sketching.

We even run actual sketching studios that create scenarios that bring people together for rounds of sketching. Where we present and critique our ideas. And really move fast. What surprised me, during this move to HTML prototyping, was the degree to which sketching became more important for me, as an individual and as a communication device with other people on the team. If you want to chunk out the time in a PDF document-like process, you might think, "All right. Let's spend 5%, 10% sketching and then we'll move into Adobe InDesign and we'll start creating our wireframe PDF documents."

The remaining 90% of that time is spent with me working through those designs in a software tool like Adobe InDesign. But when I'm doing HTML prototyping, it surprised me how much I actually am working through the code. And at the same time, I'm always sketching on the surface of my desk to figure out what those ideas are. And the degree to which I conscientiously or rigorously go through that sketch. Rather than sketch something and I move into InDesign and start doing it as a wireframe.

I've realized that if I don't think through it as much in the sketch, I'll end up spinning in the code. And end up drifting off into solving some other problem. It just doesn't all fit together. So while sketching is meant to be quick, it's meant to be rapid and it's meant to exchange ideas. It also has become the way for me to work through some of those ideas without investing too much in the code before it's time to do so. So sketching ends up happening throughout the project timeline. In tandem with the maturation of my code base of HTML prototype.

Adam: Nathan, there was a comment by one of our attendees that basically higher fidelity prototypes do take up more effort than wireframing. His question was, doesn't going this way make for more re-work and more resistance to trying different directions in the design?

Nathan: It depends on the project. 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." And suddenly we're... 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. The last thing is really, how are you measuring effort?

Because the start-up cost, in part, can be based on how you're making that prototype interactive. Whereas, with a wireframe PDF, it's not really interactive. It's a static picture. You're actually gaining on your communication earlier on, with your stakeholders and with those you're collaborating with. Like an engineer. Such that that understanding's already gained, rather than, with the wireframe you might share the picture, then you're doing the specs and you're doing lots of deep specs. Then you need to iterate.

Those conversations take a lot longer, to describe how to fade after a delay. And all those kinds of details and nuances of the design take time to explain. Rather then, everyone sees it, immediately agrees. And suddenly, that's effort saved, too. So you really have to look differently at when the effort takes place. And acknowledge that, if you're going to do some HTML prototyping, be prepared for that start-up cost that happens out of the gate.

Adam: Have you ever attempted to merge the two deliverables? In other words, taking an HTML prototype and either a wireframe or documentation like a wireframe?

Nathan: Depends on what you mean by merge. I've had a lot of people ask us... Because EightShapes is a firm that's known for using InDesign. We use a lot of different tools, honestly, in house. But we do a lot of Adobe InDesign produced PDF and user experience documentation. So people ask us a lot, "Well, InDesign has this export tool for HTML. Do you sometimes export your designs in HTML?" We're like, "Oh my gosh, no. We never even played with that." Because it just seemed too crude.

And then I would wonder, "OK. How are you actually taking that HTML prototype and integrating it into your design documentation that's, maybe, in PDF?" Yeah. We've done some of that. But honestly, it's just screenshots. You can do the same thing working with a production site or working with a comp. It's taking a static picture and putting it into your document. But, you know, we've thought about this. And we've thought about, instead of trying to bring all that interaction communication into the PDF, what if we were to bring a lot of the storytelling we do with the PDF and try and form our prototypes, or build the way we prototype. Such that that HTML artifact we produce, that people go to and immediately experience, the design with. Suddenly you can reach through that to get at some of those notes through the HTML. Or how could you take that HTML prototype and compare two pages side by side, without actually just opening up two browser windows and comparing them side by side? Or how can you step somebody through a flow of pages in an HTML prototype? Almost this meta-layer on top of the prototype design that says, "You're on step three. If you're on step three, here's what the person's thinking about. Here's what they already know. Here's the next interaction they click on to move on to step four."

In particular, the big challenge for us, recently, as we've been doing more HTML prototyping, is, what does that prototype experience look like when you land on a prototype? Do you just open up the site's home page or the registration sign-up page?

Or whatever the user sees first? How can you create an index page on top of that prototype that explains the range of things that you have within your prototype, all the different pages you've designed. Where to start, even start different types of flows. Then ultimately, as we review this design over and over, what's more relevant to our consumers then, you're looking at this prototype, you're looking at our design artifact. What are we covering today? What's different about this then when I saw it before?

And all of those kinds of conversations are really important. Not just about, what are we going to put in a PDF document, versus what are we going to render in HTML? But really, how are we as designers going to explain our design solutions and recommendations and ideas in a way that's really effective and efficient and answers the questions that those in the design reviews have of us?

Adam: Nathan, any software you can suggest or tools that you use at EightShapes that would be successful there?

Nathan: That's a great question. I would contrast the production of PDF documentation with the production of HTML prototypes. They feel very different from a select-your-tool perspective. With PDF documents, you pretty much select your software, whether it's Vizeo, Omnigraffle, Adobe InDesign, Fireworks from Adobe or some other tool, Keynote, for that matter. You choose your tool, then you render your artifact. And pretty much, if anyone else is going to update that or collaborate with you on that, they're in the same tool too. And so selecting tools can be controversial. It can be emotionally charged.

Particularly when some members of your design team have a lot of experience with Omnigraffle, whereas other people really want to use Fireworks. And suddenly you have to bring them together to produce stuff as a team. And let them start to duke it out. With HTML, we found it was a very different conversation. As a business owner, I want to invest in common tools that people have. But you know what HTML and CSS and JavaScript are? They're text. So it really came down, in our learning group that we had talked about in the virtual seminar, the first class we came together for, we talked about tools.

We talked about Dreamweaver. You know, it's part of the Adobe suite, might have a very familiar UI. It's got that visual editor that compliments the code view. It has great code hints, for example. But that probably wasn't for most of us. We talked about a range of different text editors on Mac, like Coda and TextMate and Text Edit and others. And what we realized was, you know, TextMate really works for Nathan, it really works for France. And Coda really works for somebody else.

But we're all producing HTML and essentially all of those different editors interpret the language in the same way. Of course there are nuances. There are investments in bundles or customizations that you make and so on. But we found that actually the mantra was, "Find the tool that works best for you." And it felt great, because we could all use different ones and still work on the project together.

Adam: The middle section of your virtual seminar, you talked about the skills. And you used a bunch of examples of folks at EightShapes that answer that question, "Yeah, I know HTML and CSS." Which led us into a discussion about the production code and the prototypes. If you have a designer who can produce production level code or designs, is there a perception there that they're a developer and not a designer, at that point.

Nathan: It's funny. Why do you have to put a label on them? But in fact, we have a member of our team I talked about in the seminar, his name's France, where he is a UI tech for some projects. Which means, and what we refer to as UI tech, he's doing the UI tech to produce HTML, CSS and very light JavaScript templates that give the engineers a place to start in wrapping all of that front-end code in the actual application. But you know what? France's official job title is User Experience Designer.

And he is a designer by heart. He has a design degree. He's very accomplished at doing both of those things. There are a lot of people out there that have that range of skill sets, to greater or lesser degrees. In terms of the perception, why does the perception matter? Because, if someone knows a lot of the front-end code and can do it at a production level, is that going to reduce the credibility of someone who makes better design decisions? I'd argue probably not. If they're coming up with great ideas and they're contributing to the project then who cares?

On the same front, I would wonder if there is a prejudice or stereotype that some designers don't know that. And so if you're a designer and you don't know HTML and CSS and JavaScript very well, will you not have the credibility with some kind of engineer? Then maybe that is a problem. And that's one of the rationales for some of us, at EightShapes to actually improve our skills there. So that we will be more credible, that we'll have those better conversations with them.

The other expectation that we often run into is, well you guys are producing HTML prototypes, what does that do from the sponsors' perspective? Those stakeholders that see the design and they think, "Oh my gosh, it's real. This is the real thing I'm going around in a browser and it looks absolutely perfect. Why isn't it being shipped tomorrow? It's going to work just like this. This is wonderful." And so, there's two problems with that. The first problem is, there's a lot of heavy lifting left to do to refine the design. There's a lot of engineering that needs to be done to integrate it into a CMS, for example.

But there's also this separation now of building a prototype to prove a design. Which is what we're trying to do. And then building front-end code that we're going to give to engineering to wrap the application around. Which comes later. And actually there's some steps in between, like, we need to do a usability test. We need to finalize the visual design. We need to actually build the front-end templates that aren't necessarily the same code, with all the short-cuts we took just to prove the design in the prototype.

That has ended up tripping us a couple of times. Not in a really bad way. But it's caused a few somewhat difficult conversations with stakeholders that have said, "We thought you were going to be done because we saw the HTML." And it wasn't done. That's just more about expectations than anything else.

Adam: Right. Let's talk a bit more about that code. There were a bunch of folks that were really hung up on the code. And wanting to know, do you produce production level code in your prototypes or does the code that you create for your prototypes ever become the real code or the end code for your final product?

Nathan: Sometimes. But not yet, really. If there's a member of the EightShapes team that is capable of doing production level code, there may be a project where there's an upcoming usability test. We're about, let's say, 50% of the way through the project. And we've got a design, it's starting to mature. We've got some comps, they're looking really good. We're going to run through a cycle of usability testing, but we're not yet creating the HTML templates.

Well, in that case, if the front-end expert that's going to create those templates at the end of the project is also the person that's going to create the prototype for the usability test, they can make some pretty good judgments around, "OK. I'm going to create this prototype with that end in mind. With that delivery of templates say four weeks from now or six weeks from now, in mind so that I don't have to recreate everything from scratch." And in that case, yeah. They are setting their bar to make more refined decisions as opposed to just "crank out something because you've got to get the tests executed."

There are other projects and, in fact, I'd argue most of our projects where we're prototyping very early on. The design is very unstable. And many of us doing this HTML prototyping aren't necessarily experts at doing production level front-end code. But we're still proving the design, right? You ask the sponsor, "Do you want me to do a prototype where you can see all these rich interactions in the real and we're doing them in the browser? And we could use that for a usability test?

Or do you want me to work in wireframes and do a PDF documents that just registers them all static? It might take about the same amount of time. Which one do you want?" And they'll say, "Well, the prototype." And then you say, "But it's not going to be production level code. Is that OK?" That, in itself, is kind of a stupid question. Because you're already proving the design in something that's richer and more real. The fact that it's production level or not shouldn't matter, assuming that the cost is no more than what it would have taken you to do the wireframe PDF anyway.

Adam: How do you judge when the consumers of your documentation are ready for less spec?

Nathan: That's tough. Because, most often, the generation of spec is organizational. You know, you have this history within an organization that they're used to getting particular kinds of artifacts. And that doesn't justify them. But it does speak to the fact that there is a process that they've invested a lot in, to get to where they are. So that everybody knows what the hand-offs are and what they can expect at different steps. And also, there's a fluency, right? Some engineers are very fluent at reading specs and using that to construct their test cases and build around them.

But, at the same time, they may not be fluent at looking at a prototype. And looking behind the covers and seeing everything that's underneath there. And knowing what all the details and design intents are. So one thing that we do, if we're starting to consider not producing a spec for the project is, first off, we clarify that at the very beginning. Say, "OK. Our final outputs are going to be this. And we're going to assume that we're going to make all these judgments in these particular ways." And the conversation around that is the initial proving ground that everybody nods their head and understands what the deliverables are going to be. And also, you start testing that in the conversations, during the design reviews. To make sure that those things are being understood. The next thing is, really, the collaboration around the emerging design, as it starts to mature and stabilize. That, engineers, are they asking the right questions? Are they asking more and more detailed questions that are just sort of poking around the edges of a design that everybody seems to understand?

Or are they asking questions that express that they don't still really understand a lot of either the core design intents, or a lot of the patterns that you've talked about over and over again, already in the prototype? If they are not understanding those patterns, those expectations of how a menu works, or about how the validation for a particular field's going to behave. Then that might be pointing towards they're not ready for a spec-less kind of delivery. The only final proof is really what happens with the final product.

That's where a relationship over releases with an engineering team is going to bear out whether or not it can produce, and the process can produce something without the spec. I had a project I talked about on the virtual seminar, where a menu that I had worked pretty hard to refine what the mouse-out behavior of the menu was... When the mouse left that real estate of that big menu at the top of the page, we'd pause for a half second. Then, after that, we'd fade out the big menu at the top for another half second.

It ended up feeling pretty elegant. We talked a lot about it in the design meetings. The engineers were there. But the final product, mouse-out, immediately hiding the menu. No pause, no fade, no nothing. In that environment, that's the kind of missed detail that can be really important. And maybe missed because you're not specing things. So that's the final proof that we saw.

Adam: Nathan, thanks so much for joining us today. And to our audience, thanks for listening in. And for your support of the UIE Virtual Seminars and the special online seminars that we're producing in cooperation with the folks at EightShapes.