How and Why to Create Prototypes in HTML.

HTML prototypes are a great way to test concepts with customers and speed up development. See how Digital Intent's HTML prototyping process works.

As we've discussed before, you always want to test your assumptions, as early in the process as possible when things are easier to change. And when it comes time to see if functionality accurately reflects the product vision, prototypes are an indispensable step in our validation process. While there are dozens of tools available for creating prototypes, we've found HTML offers a number of strategic advantages.

Meet the HTML Prototype

An HTML prototype is a quick demonstration of functionality previously outlined in user stories or a functional spec. Usually it is based on wireframes rather than a finished design.

HTML prototypes are primarily designed to assess the functional aspects of a site. By linking between pages, you can simulate critical user flows through the site, visualize different states of a given page, and more.

HTML prototypes provide a more realistic experience.

A prototype that's built in HTML allows the client to experience how the site will flow from screen to screen. Mockups and wireframes can be hacked to allow for linking between documents, but HTML prototypes do this more naturally. There's no software for clients to download or install, and they can review the screens using tools they're already comfortable with.

HTML prototypes also get the client used to discrepancies between one browser and another. Since we advocate progressive enhancement, providing an enhanced experience to browsers that support advanced functionality without sacrificing functionality for older browsers, clients can see visually what we mean much earlier in the process.

HTML prototypes make customer discovery more reliable.

Prototypes help us test concepts in front of customers to see if our execution of the product vision will work. It helps us visualize the flow between screens, and identify usability potholes early.

We've found that HTML prototypes lead to much better feedback, which is particularly useful when doing customer development. Showing a mockup generally leads to consistently positive feedback because the customer is focusing primarily on how it looks. By showing them a visually stripped down HTML prototype, the customer focuses on how it works. This leads to more realistic feedback.

HTML prototypes speed up development time.

We build our HTML prototypes using the same front-end standards that are used during the actual development process. We use the same CSS and Javascript frameworks, the same coding conventions, and the same in-house libraries.

This means that the HTML that is approved during the prototyping process can be used during development with a minimum of changes. Since we adhere to full separation of CSS and HTML, the interface can be applied to the site without the developers needing to scrap the HTML and start over. This has saved us countless hours and made our backend developers very happy.

This step also helps us develop unit tests and documentation - we create documentation while creating our prototypes, giving our developers a checklist of unit tests, todos and more. Because the prototypes include multiple states of a screen and the corresponding documentation, developers can effectively use the prototype as their spec.

How to build HTML prototypes

At Digital Intent, we like our HTML prototypes to look nice enough to show users for customer development, but simple enough to avoid getting derailed by conversations of aesthetic. Towards that end, the following are some best practices we use to create our prototypes.

• Use frameworks.

  Using existing frameworks can make the process much easier. We usually use the Blueprint CSS framework to take advantage of their grid-based layout, and we use jQuery to simulate simple interactions like showing/hiding divs, toggling states, showing inline error handling and more.

• Build and link to as many pages as possible.

  Simulating flows is a huge advantage to using HTML prototypes. And since HTML prototypes are so quick to create, we've found it makes sense to build as many pages as the budget allows. When we use prototypes for customer development, we like to identify as many usability concerns as possible - to see where they click, to see how difficult it is to recover and get back on track, etc.

• Create a component library.

  Most sites are made up of similar components - search forms, checkout forms, pagination, tabbed navigation, etc. Rather than creating each of those from scratch every time, you can save your team considerable effort by creating and maintaining a reusable library of HTML components.

  Since you are using a CSS framework and have a standard way of styling elements, customizing components for a given layout is a breeze. Assuming you're using a grid-based layout like the one offered in Blueprint, customization can often be a matter of changing the number of columns used by the component.

• Annotate each page.

  Rather than showing comments or open questions within the prototype, we place them in a tray on the top of the page. This keeps our interface clean for customer development, while still providing clients and internal stakeholders with relevant notes or unresolved issues.

• Create a dashboard to communicate status and provide a table of contents.

  

  We place a simple dashboard page at the front of each of our prototypes, showing when it was most recently updated. As we identify screens that need to be included, we add them to the dashboard with a flag to indicate completion status. This helps everyone know where we're at in the process, and if needed allows you to jump to specific pages outside of the normal flow of the site.

HTML prototypes to the rescue.

While we've had success using a number of other tools in the past, we've found the benefits of HTML prototypes far outweigh the downsides. While they are certainly slower than creating a prototype in Powerpoint or Azure, it's not wasted work - since the prototype doubles as the front-end code for the application, it actually saves time. And the upside of getting more valid customer feedback and better communication with clients makes it well worth the effort.

Learn more about how Digital Intent works.