Why We Prototype

Originally posted on Cognition

Making a website is more complicated than it used to be. We have to work around unanswerable questions, like at what dimensions the site will be viewed or how many pages it will have. As websites evolve and their list of variables and technical requirements grow, they become harder to define. Static wireframes and site maps can’t always capture this necessary level of detail without mountains of paper or endless annotations. Enter—stage left, waving like Miss America—the HTML prototype.

The prototype defines

First and foremost, the prototype defines the meat of a website: its content. Whenever possible, we use real content in our prototypes, which forces us to assess our content needs early on. Once the content is in place, we can better evaluate its purpose and fit. Does the hierarchy accurately represent the site’s goals? Does the copy feel right for the brand? Is the copy simply so long that it distracts from UI components?

The prototype not only defines our content, but it also defines our process. Building a prototype modularly in a browser forces us to structure and design the site in a way that can be assembled piece by piece, culminating in the final product. Once the prototype is finished, we have a holistic view of the site’s essential templates and the work that lies ahead. We can decide how many unique page layouts need to be styled and which modules can be designed independent of layout. Similarly, we can identify areas where content can be syndicated and reused, allowing our clients to practice the adage “create once, publish everywhere.”

It moves

We started building prototypes because responsive websites are fluid, and static wireframes are not. Wireframes aren’t a comprehensive deliverable if they can only represent the site in one of its many states. A prototype shows the site as it is meant to be seen—in a browser, on any device. We can define how elements change at different screen sizes, and we can add in movement and interaction so that the site is tangible—something users and our clients can actually experience like a live website. We can test user flows and observe how people interact with the site. Since the prototype is a low-fidelity artifact, we can take what we learn from usability testing and iterate rapidly until we get it right.

It starts conversations

Prototypes encourage our clients to interact with content earlier and in a browser. Instead of seeing a page as a static, single entity, clients are able to discuss all layers of a site. They can evaluate things like whether pieces of functionality serve their purpose and if content priority remains intact across screen sizes.

I feel a great sense of pride when a client understands the nature of the website before graphic design starts, and when they can give feedback with both a better understanding of how responsive web design works and our process for designing websites.

Also, by creating a live artifact, our team is able to observe, discuss, and mitigate potential challenges that lie ahead. We are reminded to ask questions such as, “Does our navigation work across all screen sizes?” or “Can we reuse or consolidate module types?” Having these conversations at the beginning of the project allows time to come up with the best solutions.

It informs

We refer back to the prototype in all phases of the project that follow. It suggests to our designers what content should be displayed and how a user will interact with it. Though we don’t use our prototypes for production code, our front-end developers use our prototypes to evaluate content hierarchy and see how the presentation of content changes across screen sizes. We usually don’t draft a sitemap artifact until the prototype is well underway, so back-end developers can refer to our prototypes to see how the site is structured and how pages link together.

For many of our projects, an HTML prototype may serve as the sole UX deliverable, but its influence lives on beyond the UX phase. It is the one deliverable in our process that ties together all the others—requirements gathering, content strategy, design, and development.