Rethinking Our Prototypical Process

Almost exactly a year ago, I wrote about why we prototype. While those reasons all remain true, over time we have learned that it’s not always the best solution for every client. It takes a lot of time and effort, and so on projects that have either smaller budgets or simpler content, layout, and/or interactions, prototyping every page can be overkill. Additionally, HTML prototypes can sometimes confuse clients, leaving them with more questions than they started with—the exact opposite goal of a deliverable.

As my teammate Abby wrote recently, our process is amorphous and custom—it’s almost a project unto itself to decide which deliverables are needed to get from points A to Z. As a team, we work together to decide what the client needs. For the projects we decide against HTML prototyping, we need to get creative to fill in any communication gaps that may be left behind. Here are a few recent deliverables we’ve used to move a project forward.

Content outline/Page description diagrams (PDD)

As I mentioned, HTML prototypes have the potential to confuse some clients. In addressing feedback, I’ve answered questions like: Are we tied to this layout? (No.) Is this real content? (Ideally.) Is this what our website will look like? (Probably not.) The content outline strips any potentially distracting elements from the prototype: no layout, no typography, no links, no things remotely resembling design. It’s just a list of the content that will be on each page in order of its importance.

Ridiculously simple, right? But surprisingly, it tells each team member a lot. The client gets a holistic view of the site’s content and can look at the outline as a to-do list of content that needs to get created and maintained. The designer can identify where content overlaps on pages and start thinking about necessary page templates and how to display content hierarchy visually. The back-end developer can look at each item as a content field in the CMS and begin building the back-end before any of the graphic design has started. It’s the skeleton of the site and something we refer back to again and again until launch.

Functional prototype

Traditionally, the word “prototype” implies an early model of a real thing—not a rough plan for a future product (which is how we’ve been using them for the web). In the past, our prototypes have been quick ’n’ dirty, with code that gets scrapped as soon as we move into front-end development. With functional prototypes, we use production-level code so that once tested, iterated, and improved upon, our efforts evolve to become the final product.

Rather than prototyping an entire site, we identify areas that we think need extra time and attention, from both UX and development perspectives. Some examples of recent things we’ve built functional prototypes for are: complex navigation structures, content filtering, and a complex building/ordering system. Not only do we get a head start on development, but also we can review them with clients long before design begins to make sure they are meeting all the agreed-upon requirements.

Movement prototype

In an internal design review recently, I tried to explain interactions to my team while we all looked at a static image. “This section will stay fixed on a background plane; this will scroll over it and then push this other stuff away, and as you scroll down the page, this will load in.” I was met with blank stares. If my team didn’t understand what I was talking about, the client had no chance. And thus, the movement prototype was born.

We’re used to creating moodboards to demonstrate how a brand will be expressed visually on the web, but moodboards fall short when it comes to demonstrating what it feels like to interact with a site in a browser. Should things bounce into place or fade in slowly? What happens if a user clicks on this expand icon? Beyond the fact that it’s a lot easier to show interactions than merely speak to them, another benefit of exploring animation and interaction is that we are able to test various plugins and techniques. We can browser/device-test them and measure their weights on the page with plenty of time to find alternatives.

____

I like to think of deliverables as a toolbox that I can pick and choose from to complete a project. Sometimes I’ll use all my tools; sometimes I’ll only use two. And sometimes I won’t have the one my team and client need, so we’ll invent a new one.

Back to Top