Just Build It: HTML Prototyping and Agile Development

In: Columns > View Source

By Garrett Dimon

Published on March 6, 2006

Chances are, you use some sort of prototyping to illustrate Web interfaces for clients and stakeholders, and rely on those prototypes for approval. Whether you’re using visual design comps, wireframes, site maps, process flows, page description diagrams (PDDs), or a combination of these, your goal is always the same. You want to mitigate the cost of making changes.

Unfortunately, the traditional design documents don’t always save us time or money. In some cases, they’re actually more expensive because they fail to accurately account for all of the factors involved in building a Web application. Additionally, due to the static nature of the documents, they present a challenge when representing highly dynamic pages that rely on DOM scripting and AJAX.

They say a picture is worth a thousand words. When you think about how many words it would take to describe a dynamic Web interface with multiple actions and outcomes, it becomes clear that a complex mixture of words and diagrams are not solely capable of representing your final product. Unfortunately, the less accurate that representation is, the more likely it is that there will be a misunderstanding. Naturally, those misunderstandings will lead to a need for adjustments, and these changes are precisely what you want to avoid.

While the traditional documents provide value in certain contexts, in order to create real-world interfaces, it sometimes helps to scale back the role of these documents and move into the code sooner. Clearly, jumping into HTML sooner isn’t always the answer, but it is a perfectly reasonable option that clearly deserves consideration. Determining whether it’s right for you and your project depends on many different factors.

Prototyping does not have to be throwaway work

You need to temporarily suspend any notions that prototyping is always throwaway work. If you approach it as throwaway work, it will be. However, if you approach it with the intention of keeping it, you can create modular code that can be reused.

The idea that rapid prototyping in HTML equates to throwaway work is a poor one. I propose that if you follow good coding practices and build with the notion that you will keep, update and ultimately use the code in the finished product, you’ll be satisfied with the results. In fact, you may find that it can actually be easier to change well-written modular code than it is to update a batch of wireframes or process flows. The key here is to embrace the fact that things will change and plan for it from the get-go.

On a related note, if you’re really worried about throwaway effort, you might want to take a moment and think about what happens to those detailed design documents when the project is over. If nobody ever looks at them again, then you’re already doing throwaway work. Why not just spend that time going straight into building your interface and simply work from basic sketches instead of deliverable-quality design documents?

Paper prototyping isn’t necessarily faster, easier, and cheaper

As a result of the misconception that prototyping is throwaway work, you’ll often hear that it’s faster or easier to create a wireframe or other document than it is to actually write the HTML, CSS and JavaScript. In this case, that’s a fairly accurate statement. However, the real reason that it’s faster is because it ignores factors that can have a significant impact on the final product.

At some point, you’re going to have to invest the time to document issues like security, error messages, page flows, and other related topics. So, while this lack of up-front fidelity may be acceptable in some situations, the static documents are only creating the illusion of speed and ease.

Another problem with this approach is that these factors are usually documented separately and out of context of each other. For instance, the wireframes might describe a page layout, but the page flow might be documented separately in a process flow or site map. Additionally, the security might be documented in a security matrix. When it’s all said and done, your documentation is fragmented, and it’s difficult to pull together a cohesive picture of the end product.

This might be an acceptable challenge for a technical team, but to expect a non-technical client to interpret and understand a collection of documents such as this is rather unrealistic. When faced with the expectation that they need to approve them, you’re invariably going to run into miscommunication, and that miscommunication can quickly turn into changes later in the project. However, if it’s all there in a working screen from the get-go, you’re speaking a language they understand, and you’ll get a better response every time.

Paper design documents can be better for clarifying ideas

One situation where paper is significantly safer than agile development is when you feel like you may be way off target. In this situation, it’s often helpful to create a rough draft and check the direction before you take off. However, if you have a pretty good idea of the direction you’re going to follow and have experienced coders, then it’s relatively safe to get into the code and build something very basic that you can easily extend as needed. The important idea here is that the paper is only serving as a rough draft to get your ideas out. Keep it fast and simple, and you’ll be getting better value out of your time.

In a situation where you’re confident of the direction, or the potential margin of error is small, it’s often a trivial and pointless exercise to create wireframes or other deliverable-quality documents. Usually, sitting down and having a conversation with your client over pen and paper sketches is enough to find that direction and get started. If you go this route, you will have actually saved yourself time because you didn’t create a slew of unnecessary design documents.

Large specialized teams need the documentation

Another area where design documents shine is with large specialized teams. For instance, if your information architect won’t be writing the HTML, sketches probably won’t have enough detail for the engineers. You’ll have to document the wireframes and pass them along. Similarly, if your engineers aren’t copywriters, they’ll need the copy for each and every error message in the application. You don’t treat error messages as an afterthought, do you?

This is more of a problem with large teams than it is with agile development. By creating a large team with highly divided specializations, you’re creating a need for additional communication and overhead. And for anyone who’s ever played the childhood game Telephone, you can probably guess what that means for your project long term.

The benefits of HTML prototyping

Working applications and HTML provide some intangible benefits that may not be readily apparent. While the challenges of static design documents are problematic, it’s the benefits of a tactile interface that really make HTML prototyping shine.

It bridges the communication gap

The first and most obvious benefit is that it’s tangible. That means your clients can understand it. When discussing how it works, you’ll both be speaking the same language right off the bat, and they don’t need to interpret design documents or try make sense of unfamiliar territory. That leads to better communication and more appropriate feedback that you can quickly build out to receive the next round of feedback. With that taken care of, you’ll find that you spend your time focusing on the right problems and using your time more wisely instead of trying to plan features and requests that the clients are making because they’re missing the big picture.

It’s more engaging

Another benefit of a tangible application is that your clients or stakeholders can click, touch, type, and interact to their heart’s desire. Once again, this will only lead to better and more extensive feedback, and, in truth, a working application is the only true measure of progress and success.

It’s more thorough

Many variables get overlooked when creating wireframes or other paper documents. Factors such as state, security, error messages, level of effort, page flow, DOM scripting and other dynamic elements can be ignored or misrepresented. This goes back to the claim that HTML prototyping takes longer than a simple design document. Of course it takes longer. You’re doing significantly less work, and those oversights will come back to haunt you.

It’s a reality check

When creating a wireframe or other design document, it’s very easy (and in some cases, downright tempting) to turn a blind eye to the reality of implementation. Things such as response time, ease of implementation, and other factors may prove that a particular idea may not be as good of an idea as it looks on paper. This may make you reconsider the reality of a particular feature or even encourage you to create a better all-around solution.

Whether we like it or not, user interface design isn’t just about what you see on the screen. It’s the entire experience. That includes response time for queries or AJAX updates, cost of long-term maintenance and challenges interfacing with third-party products.

It helps you avoid document debt

Since you’re not investing unnecessary amounts of time in design documents, not only are you saving the time creating them, but you’re also saving the time you would have spent maintaining them. That can add up to a heck of a lot of time. On projects with smaller teams and less bureaucracy, this may not amount to much, but with large teams the potential savings could be huge.

Imagine sitting down with programmers and showing them exactly how something needs to change instead of updating a document and letting them know to go look for the changes. Not only are you avoiding the time sink of updating the documents, but the direct communication can only help create better results for the overall experience.

Talk is cheap

Tangible results are the best true measure of progress. It’s easy to hold meetings and create design documents, but getting down and dirty is where the real problems rear their ugly little heads. It’s those little problems that you didn’t expect that invariably hurt your estimates or timelines. The sooner you uncover those issues, the sooner you can get a serious grip on how long a certain module will take you.

Of course, we can’t ignore the fact that clients and stakeholders love to see results. You can’t blame them either. Would you rather see a document describing what’s eventually going to happen or see the end result? The sooner you have something real to show off, the happier everyone is going to be.

The stipulations

Expect and embrace change

Flexibility is the competitive advantage here. Whether it’s re-factoring code or accommodating new business requirements, this method will fail miserably if you’re not expecting and embracing change. This has one major prerequisite. You know that requirements will change and people will change their minds, so you have to expect and plan for it. It can be frustrating when clients ask for a change they could have asked for last week before you made modifications. However, with a working interface, you’ll find that the quality and sanity of requests goes up dramatically because they can visualize and understand what you’re doing.

Writing good code is imperative

For this to work, code must be easy to change, update and adapt to changing requirements. Don’t repeat yourself. Separate presentation and content. Don’t take shortcuts or get lazy. Always write code as if you have to hand it off to someone else tomorrow. That means do it right up front. The easier it is for you to make those changes, the more likely you’re going to end up with a satisfied client.

Start small and easy

Avoid trying to boil the ocean right off the bat. Build only the pieces that you know, and let the rest of the functionality take form around that. Your first incarnations may be extremely crude and basic, but you’ll be amazed how quickly that foundation can evolve into a fully functional application right before your eyes. Build what you know, and let the rest grow as you go.

Varying levels of detail are appropriate

One situation may encourage that you build all the tiers of your prototype and create a vertical slice that cuts across presentation, business logic, data access, and your database. Another may be basic enough on the back-end but require a lot of client-side scripting. For the latter, it’s probably more important to focus on the front-end experience than the back-end. Just be careful that you’re not ignoring how the two will be integrated later. Use your judgment in determining the right amount of detail for your project.

Don’t replace planning and documentation

One of the mantras of agile development is to focus on delivering working software over comprehensive documentation. So, agile development isn’t about ignoring documentation, it’s about focusing on appropriate documentation. Similarly, it doesn’t advocate ignoring planning. It just encourages planning only what you really know and discovering the unknowns as soon as possible. Ideas still need to be hashed, they just don’t have to cover every single base and be deliverable-quality. You’ll be covering your bases and creating a deliverable as you build the application. By spending the time where it matters, you’ll be amazed at your results.

Summary

Creating wireframes, PDDs, site maps, storyboards, process flows, and other tools for developing user interfaces is a lot like working in a vacuum. You’re ignoring many of the significant factors that influence your final product. These documents have their place. There’s no questioning that. However, it is important to understand when a design document might not cut it. HTML prototyping and full-on agile development of Web applications are increasingly viable options that help minimize communication gaps and assumptions and deliver more accurate results sooner. If you haven’t considered it, now may be the time.

Related Topics: Information Architecture, Web Design, Information Design, HTML