How HTML prototyping improved our design process

The days of a designer labouring in Photoshop and then handing a pixel-perfect design mockup to the development team are long gone. And good riddance to those days. As a designer, it never felt right to be making pictures of websites.

Static pictures (mockups) only communicate a small aspect of a design, when you are creating responsive layouts and interactions for modern web apps or websites.

HTML prototypes allow us to design responsively, with interactions to simulate what it's like to use a real, responsive application.

What is a HTML prototype?

Put simply, a HTML prototype is a design that's created in HTML and CSS, and viewed in the web browser.

Uses for HTML prototypes

Usability testing

A HTML prototype is fantastic for usability testing. Once you have designed your prototype, put it in front of users to get valuable feedback and iterate on the design. A HTML prototype is more versatile than using mockups for testing, as you can simply send someone a link to view it in their browser as an actual, working interface.

Client and internal presentations

Clients love seeing HTML prototypes early in the design phase. It gives them the chance for feedback on something that feels real. The word prototype suggests that it's not the finished article, i.e. it's not a real, functioning interface yet – merely a demonstration. This point of it not being complete is important to clarify to clients who sometimes think the application is done when they see a prototype in the browser!

Designer-developer communication

The prototype is also useful as an internal tool for bringing the team to a shared understanding of a feature, which is essential for a smooth design and development process.

User interface designers have a choice on how to communicate their designs to the development team.

1. Create mockups in a design app such as Sketch or Figma, and then hand them over to the developers as images, specification documentation and individual assets, or
2. Design interfaces and hand them over as HTML and CSS.

Let's say you take option 1. You design your interfaces in a design program, and then hand them over to a front end developer to build. You are helpful – you give them detailed specs, or even use a collaboration tool such as Zeplin for the developer to copy and paste CSS directly out of your design files. That is an improvement over supplying only static mockups, but this method of delivery can still raise many design-related questions for the developer:

• How does the design scale between the mobile and desktop versions you provided?
• What about hover states and interaction of elements?
• Did you notice the font renders differently in Chrome than in your design mockups?
• Why is this component sized slightly different to the one on the other page? Was that intentional?

The list goes on, but there's a common theme here. The developer has been asked to build something that hasn't been fully realised and communicated by the designer. A design that ends up on the web should be living in a web browser before the designer considers their job done.

So, you choose option 2 – to build the interfaces as a HTML prototype using HTML and CSS. Great, designing for the web, using the languages of the web!

This doesn't mean designers say goodbye to their design apps. You can still use Sketch, Figma etc at the beginning of the process to experiment with layout, typography, colours etc. Then, once you are done experimenting and want to fine-tune responsiveness, micro-copy, user flows and interactions, you use a HTML prototype to design those remaining aspects of the feature.

Integration with the design system

Established apps and sites benefit from a solid design system, normally called a pattern library. The pattern library is a living style guide built in HTML and CSS.

If you have a pattern library, your HTML prototypes can use the exact CSS and HTML patterns directly from your pattern library! This feels like magic as a designer – access to all your base styles and components while designing in the browser. You can use those puzzle pieces to assemble interfaces quickly, using the language of your app.

How a HTML prototype fits into the design process

Perhaps the designer experimented with an idea on paper or as a design mockup. Deciding when to turn the idea into a HTML prototype can be tricky.

When is a design ready to translate to a HTML prototype? The answer is different for each project and also the team's preferences. We tend to transition a design to HTML when we feel like (a) it's going to be faster to work in code rather than a design program, and (b) when the static mockups aren't telling us anything new. Although that's a vague answer, that normally happens after the initial experimentation phase has played out, and we have some shared understanding of the feature.

Sometimes a designer might go from a sketch or written interface directly to HTML prototype. If the feature is for an established app, the UI components are also established, so designing the interface or workflow can be a matter of choosing the right configuration of components and writing micro-copy. Multiple design options for this type of feature can be quickly created on paper. Then you can build it directly as a HTML prototype, skipping the design app altogether.

A prototype shouldn't be production-ready

A HTML prototype should never be considered production-ready. The prototype is still in the design phase, so you can take shortcuts with the HTML and CSS to get it done quicker.

The point is to illustrate an idea as best you can. Production ready code happens when the feature is being built in the app.

That being said, front and back end developers may find the prototype to be a very handy reference point for writing the production code.

Tools for HTML prototyping

WYSIWYG builders

There are site builder applications which output HTML and CSS. This may bring back horrible memories of Dreamweaver for some veterans, but the current crop is a marked improvement on that. Webflow is one app that seems to be used quite widely. The problem I have with this kind of tool is that you are limited by its feature-set. If it can't output a grid layout or interaction you want to achieve, you're stuck.

Handwritten HTML and CSS

You can use a text editor such as Sublime Text to hand write your HTML and CSS. This is a great way to prototype a small feature. But what if your app has 50 interfaces, each with common elements such as a header or a footer? You don't want to repeat that header on every HTML file. What if something changes?!

This is where static site generators can help…

Static site generators

This CMS Wire article defines a static site generator as one that "combines content and templates into static HTML files. Generation occurs once and the files can be hosted anywhere without server-side languages, frameworks or other dependencies."

The most useful feature of a static site generator for HTML prototyping is the concept of "partials". We use partials so we can define commonly-used elements such as a page header, then include it on each interface. This means you're not repeating yourself, and can make changes to common sections of the layout in one place.

Static site generators also bring many other benefits to the table such as variables, using real data, compiling Sass, or different base layouts for certain pages. But you can just use partials to start with, and add features to your prototype as you find the need for it.

Our static site generator of choice is Middleman, but there are several great options to choose from.

One caveat is that static site generators require using the command line. This might put some designers off. If that's the case, just stick with plain HTML and CSS to begin with and get used to running project-wide find and replace for changing HTML in multiple files. It's still a huge improvement over designing static mockups.

Front-end frameworks

Front-end frameworks such as Bootstrap or Foundation can be useful for prototyping, as they have pre-built components and styles to use. Assembling interfaces can be like putting together a puzzle using the pieces the framework provides, similar to using your own pattern library. Where possible, we use the pattern library as the base for the prototype, so a front-end framework wouldn't add much value.

Our preference is to build a design up from scratch using only the parts it needs, so using a framework adds bloat we prefer to avoid.

Summary

• HTML prototypes allow us to design responsively, with interactions to simulate what it's like to use a real, responsive application.
• A prototype can totally replace static mockups, or be used as an addition to them.
• A prototype is useful for usability testing, client presentations, designer-developer communication, and integration with your pattern library.
• A prototype is a manifestion of a design, not production-ready code.
• Static site generators make creating HTML prototypes efficient and maintainable.