“The new site was supposed to go live last week, but got delayed because the checkout process was glitchy on mobile.”
Sound familiar? How about …
“Marketing said their copy didn’t fit in the template, so the designers modified it, but the developers said they’d have to redo all the code because of the change”?
Or …
“Have you seen the mock-ups that we finally received? There’s only 6 layouts for approval, but the site is supposed to have over 200 pages.”
If you’ve dealt with a project that employed the traditional “page design” approach to website development, chances are, you’ve experienced some or all of those situations, or variants thereof.
Fortunately, there is a better way, and it’s called rapid prototyping. Here’s a glimpse of a few of the benefits that rapid prototyping can deliver on your team’s next web project:
Uncover actionable insights on both user experience and development, quickly and consistently.
Reduce the risk of critical last-minute glitches and reworks.
Save your team significant amounts of time, money, and anxiety.
Sound good?
Great. This post will explain exactly what prototyping is, how it works, why you should use it — and when you shouldn’t.
What a Web Prototype Is (and Isn’t)
There are a few different approaches to web design, of which the two most significant ones are the linear stages method, and the iterative design method. The former tries to build a website in one swoop from start to finish, while the latter takes the method of incrementally building and improving things, layer by layer.
Rapid prototyping is a subset of the iterative design toolkit, and its superpower lies in helping a project get to the prototype stage, rapidly.
But what exactly is a web prototype, anyway?
Everybody knows that a prototype is an initial or early version of something, based on which future versions are built. When it comes to web projects, however, there seems to be little agreement on what a prototype actually is. Confusingly, terms like prototype, wireframe, and mock-up are all used interchangeably. Each of these is a different tool with a different set of strengths, best suited to a different stage of the development cycle. So, let’s clear up the confusion, shall we.
Humour me for a moment with a tangible, physical-world example. Say you go to a tailor to get yourself a bespoke suit. They’d invite you to try on a “basted suit”, before giving you the finished version. That basted suit is essentially a prototype of the final suit.
Even though the tailor takes your measurements beforehand, there may still be details that need fine tuning. How that specific fabric stretches and folds around you, for instance, or how the fit requires a few millimetre-level adjustments to perfectly… er, suit your posture.
Now, the thing to note is this: the basted suit isn’t perfect, but it’s still a basic suit. It isn’t an artist’s sketch of a suit, a schematic diagram of a suit, or a miniature scale model of a suit. It’s an actual, rudimentary suit. Sure, it isn’t yet error-free and doesn’t yet have the buttons, lapels, and linings as the final suit, and you might get strange looks if you wear it to a dinner party, but you can still try it on and see how it feels.
And that’s exactly what a web prototype is: a basic and partially-functional version of your website. It isn’t yet polished error-free, but it lets you actually try the site out. You may not want to unveil it to the public just yet — it isn’t a beta site — but you can get your team to browse around, see how it feels.
Pretty simple, right? Yup. That’s all there is to web prototypes. Except for the benefits of using them — there’s a whole lot more to that. To really see those benefits, however, it helps to first take a look at the old-school web development workflow.
The Pitfalls Of Traditional Web Development
Here’s what page-centric web development that doesn’t employ rapid prototyping typically looks like:
You ratify the brief and scope of work to the agency.
The agency design team sends you a wireframe for the “main” pages.
You’re not sure of how it’ll look or work (Is that a drop-down menu? Does it open on click or mouse-over? Does the login link surface a form on the same page or does it take the user to a new page?) You seek a few clarifications and changes.
They send you a second set of wireframes, this time with much more detail, and an explanation that it’ll be a lot easier to understand once you see the “comp”. Each page has dozens of states and break points. How is this going to look on mobile you wonder?
You approve the wireframes to get things moving along.
The design team sends you a comp.
It looks nice, but you’re still not sure what happens when a user clicks on an image in the carousel, or resizes their browser window. It’s now several days into the project. You approve the comp with a few changes.
The developers take the comp and work out a “page template” for each of the page types. This has placeholders for text and images.
The copywriters — either yours, or the agency’s — provide the copy. Some placeholders turn out to be too small, some, too big.
The developers work on the changes (in extreme cases, the project may go back to the designers for modification) and start putting in the features. They send you the updated version with real copy, buttons, forms, and calls-to-action.
Now that your team can actually see what the website is like, it becomes clear that there’s something missing. (Eg: “Users need to have a way to share their wishlist with somebody else!”)
The requirements go back to design to flesh out the menus and screens.
The developers work on re-coding significant sections of the site to incorporate the updates.
The site is almost finished, but there isn’t enough time to really do enough usability testing.
The site is taken live with little or no testing.
Bugs are found. Analytics indicate some changes are required because users aren’t traversing the site exactly as expected.
There’s little budget or appetite left for another development cycle, so all but the most critical glitches are ignored / shelved for later.
TL;DR: Old-school web development is a process fraught with constraints of time and clarity.
To be fair, some amount of iteration and back-and-forth is to be expected in any creative endeavour. It isn’t as though rapid prototyping — or any other method, for that matter — will help you get from start to finish in a straight line.
Rather, the whole point of the rapid prototyping method is that it accepts and embraces change as a necessary part of the creative process. Many agencies try to avoid “jumping into the code” until everything is settled upon, because, “what if there are changes?”
In theory, the decide-first-develop-later approach saves time and money. In practice, it does anything but. The secret of rapid prototyping is that it alters the paradigm from changing less to changing faster. Strangely enough, this often ends up leading to fewer changes required overall.
What’s more, rapid prototyping prioritises diving deeper into the details that are important first, while queueing more superficial features for later in the process. Doing the hard stuff first lets us iron out any potential speed bumps or surprises early in the process.
Here’s how that works.
The Rapid Prototyping Workflow
The most common reaction to web prototyping is, “Making a functional prototype of a website sounds expensive. If the prototype looks, feels and works like a website, doesn’t it involve nearly as much work as making the website itself?”
This is a pertinent objection. And, depending on how an agency approaches prototyping, it could also be true. Many agencies like to use special tools to develop “throwaway” prototypes. That is, once everything is finalized, the prototype is cast aside and the real website is coded from scratch in its image.
They make throwaways mainly because they want to show the client multiple “high-fidelity” options, which would take too much time to develop as real sites. They want to present high-fidelity versions because they’re afraid that the client won’t “get” simpler, early-stage versions. And they need multiple options because they don’t get the client involved early enough, so they must try out many things to discover what works best.
It’s a vicious cycle.
At Simplicate, we do this differently. There are two secrets to this.
First, setting expectations and parameters. Before we start on the prototype, we have an exploratory discussion to help the client discover what it is they’re really looking for. We do this by showing them several varied websites and asking them to rank their choices. We then analyse their ranking to pinpoint the attributes that matter most to the client. By the end of this exercise, we usually have two to three sites that are “in the neighbourhood” of what the client is looking for in terms of style.
Since we’re already aware of the features important to the project, and now we’re clear on the “look” that we’re aiming for, we combine the two to arrive at a clear set of expectations. With that in place, it becomes so much easier for us to serve up our second secret sauce, which is getting customers involved in the development process very early.
In our experience, presenting early versions to the customer has never turned out badly, especially when they’re confident that we’ve understood their expectations. Then, it’s easy for them to see the prototype as a stepping stone towards an expected end point, rather than something that they need to compare against an expected end-point.
As we work with the client to iterate on those early versions, we like to check with them frequently to see if they like the direction in which things are shaping up, and that they’re comfortable continuing down a certain path. These questions let us present quick proof-of-concept ideas and make small adjustments based on regular feedback.
This lets us transition from sketches and wireframes, to prototype to site skeleton very quickly, without the need for wasteful, throwaway prototypes. (This is one of the reasons why we like Craft CMS so much — its versatile content modelling tools let us smoothly transition from prototype to final site.)
Here are a few of the payoffs of our approach.
Quicker iteration. Starting very rough and incrementally adding layers of design, content and functionality, means you can start seeing something tangible very quickly, rather than waiting weeks or months for “design” to happen.
Greater alignment, faster decision-making. Getting to see your website take shape within the browser and letting stakeholders and team members actually navigate through pages like they would on the final website is a drastically different experience than reviewing and approving PDFs of designs. Since everyone is clear where the project is and what it needs next, there’s very little friction in moving forward.
Better collaboration. This approach allows all parts of the team — design, development, content, marketing — to work simultaneously on the project. Nobody needs to wait for someone else to “finish their part” before they can begin working. And it’s so much easier to see what’s important and what needs to be improved, and solve conceptual disagreements, when you’re actually using something, rather than looking at pictures of it.
Greater attention to detail. You get to test out things like animations, motion, transitions, and potentially even page load times, way earlier than would otherwise have been possible. Having a prototype site earlier also makes it possible to perform user testing earlier, and get real world feedback.
Superior discovery. Uncovering when a small change to a design can have a huge impact on user experience, or figuring out how long something will take to program, becomes a lot simpler. Designers and programmers come to a faster understanding of what’s possible and what’s easy or difficult.
Enhanced flexibility. Since rapid prototyping involves constantly layering improvements, if a deadline changes and we suddenly have to rush to launch, it’s easier to polish important features and hide less important ones to make a deadline, and then the other features can be brought online when they’re ready.
Improved quality, time, and cost performance. Uncovering insights and improving decision-making early means that there’s still plenty of time and budget left to make sure that the important discoveries get included in the first phase of the project. That’s way better than launching a site, and only then realizing all the things that could have been improved, and pushing them into a later phase (more time, more budget).
When Not To Use Prototyping
By now, the benefits of rapid web prototyping are pretty clear to you, but you might be wondering: what’s the catch? No tool is perfect, so it can’t be all good, right?
Well, we’re pretty hard-pressed to think of any significant drawbacks to rapid prototyping. (That’s why we use it, after all.) But there are some scenarios where its value as a tool is diminished.
For instance, if your project involves building a microsite with just two or three pages, transitioning directly from sketch to building the production site might make sense. The same is true if you need a site that’s practically an exact replica of an existing site (a new “country site” for a company present in many territories, for example).
Also, if you’re working alone and developing a website all by yourself, prototyping is much less useful since it’s primarily a tool that improves collaboration.
Next Steps
If rapid prototyping sounds like a good fit for your next web project, why not drop us a line? We’ve worked on projects of all types and sizes, and we’ve been told that we’re pretty fun to work with.
Alternatively, if you’d like to learn more about how you can cut down the development cost and time on your next web project by 50% of more — even if your website has hundreds of or thousands of pages — check out our article on component-based web design.