I built my first prototype six years ago in a last-ditch attempt to break through one of those logjams that make designers question their career choices. Despite numerous presentations and discussions, I hadn’t been able to secure sign-off because the stakeholders were unable to get their heads around the design. I decided a clickable simulation might erase any ambiguity.
Viewing my presentations, the stakeholders had worried certain elements wouldn’t function as expected. I’d assure them that these were intended to work in a completely different manner. They’d relent — and then lose their confidence, and the cycle would start anew. (I cannot recommend this methodology.)
So, I built a prototype, under the assumption that this was a one-time deal — an extra step I’d take on this one project to sort out a specific problem.
But presenting the prototype was eye-opening. I not only overcame the stakeholders’ skepticism, but found I’d also engaged them in a new way. They were full of helpful insights and observations, allowing the team to move forward with a fresh energy and purpose.
Prototyping has since morphed from “nice idea” to “critical component” in the experience design process. Easy-to-use tools have proliferated, supplemented by plug-and-play libraries of components and interactions. You can now build a prototype more rapidly and with less trouble than ever before with programs like Adobe XD, for example.
Today the question is “How should I build my prototypes?” instead of “Should I prototype at all?” Yet many designers have been burned by hard-to-learn or feature-poor tools, while others balk at inserting another step into already aggressive schedules.
For those of you still in doubt, here’s the case for the user experience (UX) prototype — as well as some thoughts on making the most of this essential tool.
Why you should build a prototype
Finding personal peace of mind and improving your designs
Every article you’ll read about UX prototyping will push its advantages in selling a design or in testing (fair warning: I’m going to do just that below). But few mention how it can help you — the designer — without reference to stakeholders, developers, and a sundry of other folks.
If you’re like me, you have a little movie screening in your head as you design an interface. There may only be static wires or mocks on the screen, but in our mind they are fluid and dynamic, with interactions and transitions connecting one to the next. The ability to create that film is one of our strengths as interactive designers, and we rely on it to guide our design decisions as we craft an interface.
But that movie can be misleading. It’s based on our assumptions (which might be incorrect), our experience-based sense of what will work in a given context (which can be too optimistic), and our confidence in the accuracy of our static designs (which can be wildly misplaced).
Creating a prototype allows you to stress-test your design and find out if your mental cinema is more faux than vérité. Even the most experienced UX professionals can miss the mark, with our missteps only discovered late in the development process. A prototype can help you spot and fix mistakes and poor design choices before you share your work with an unforgiving world.
Capturing and communicating the entirety of your vision
One of the disconnects inherent to UX design is the gap between our usual deliverables (wires, flows, and mocks) and the nature of what we’re designing: something kinetic that changes in response to user activity. Static images, no matter how carefully annotated, are inadequate to convey how a design is meant to work, as opposed to how it might look.
While a simple interface might be fairly reflected by stills, the mismatch between your vision and what traditional deliverables can offer will only grow with the complexity of the design. A prototype can close that distance, allowing you to define your plan with greater specificity and accuracy.
Image by BlacksalmonGetting more reliable buy-in from stakeholders
I’ve already related how a prototype can help better communicate the idea behind how a design is intended to work. But it can also address a more systemic problem. We’ve all had the experience of getting sign-off from stakeholders early in the design process, only to run into frustrating and schedule-disruptive backtracking down the road.
Usually what derails our work is the complaint “that’s not what I thought you were proposing.” This too frequently comes after numerous presentations of detailed wires or mocks, with extensive discussion of how they come together to represent a working design. There will be endless email chains, involving an ever-growing number of contributors, dissecting small (and often peripheral) aspects of the design — but you’ve managed put them to bed. Everyone is finally on board. And then it all comes unglued.
Since many of these last-minute reversals stem from a misunderstanding between designer and client, their likelihood can be diminished by clearer communication during approval stages. Designers need to be good at extrapolating how something will work in its final state from more rudimentary materials — this isn’t a skill possessed by many of the stakeholders who will be reviewing your work. A prototype tugs the design closer to its ultimate form. As a result, your audience will need to make fewer and shorter conceptual leaps to understand what you’re proposing. The consequent sign-offs should (at least in theory) be stickier.
(I’ve also suggested on several occasions that stakeholders should be required to deposit funds in escrow, forfeitable when reneging upon key approvals and redeemable only after documented good behavior. It has been explained to me that this is unworkable for various reasons. I maintain that it’s merely an idea ahead of its time and will be feted with acclaim in more enlightened days.)
Facilitating mid-design user testing
Testing comes in many flavors. You’ve got your input tests (testing an existing interface to locate targets for redesign and expansion) and your polishing tests (testing a new and developed design to find missteps, outright errors, and opportunities for pre-launch refinement). But what often gets lost in the scramble to sprint from concept to release is validation testing that’s conducted early enough to have a significant impact on an emerging design.
The problem is that such testing requires something to test — and you’ll need that “something” well before there’s even a rough version of the developed product. The solution here is a lightweight prototype. If you want input on nomenclature, interactions, flows, and structure, an early or mid-process prototype is ideal for testing. It doesn’t have to be complete — there are likely many parts of the proposed interface that are largely uncontested, so focus on those elements that you suspect would benefit from additional refinement.
Image by BlacksalmonBridging the designer-developer divide
The relationship between designers and developers can be fraught and contentious for reasons too numerous and complex to list here (but like most designers, I’ve got a curated and up-to-date enumeration of these issues in my head). While there may be an element of the Discovery Channel “lions vs. hyenas” struggle at play here, a lot of the friction arises from poor communication.
The fault lies on both sides. Developers often expect more detailed specs and instructions than designers think are warranted, while designers regularly overestimate how much devs can be expected to interpret and read between the lines of loosely defined hand-offs.
Prototyping can help defuse this tension. Even a rough prototype will allow development to point out potential problems and feasibility issues: we can’t do that on this platform; we’d need too much time to build that; that would require expensive third-party solutions that would break the budget. Identifying such issues early on will save time and tears down the road.
Working closely with developers early in the process helps to identify potential failure points in a concept flow, as well as opportunities and solutions that enhance the product. In my experience, this tandem effort has always yielded critical insight as part of what is still widely classified as the design phase. Recently, I shared a prototype demonstrating new functionality for an app I was working on. It just wasn’t hitting where I wanted it to, so I ran it by a favorite dev, whose instincts I trust completely. “We can do all this,” he said thoughtfully, “but there’s a couple of APIs that would be even better here and here.” Successful products require this type of collaboration in their early stages, which is now much easier to facilitate with prototyping before actual development begins.
A few common myths about prototyping
I don’t know the first thing about prototyping
Not to be argumentative, but actually, yes, you do. It’s integral to every kind of design, although we might call it by different names: concepting, iterating, mocking up, etc. Imagine you’re designing something non-interactive, like an ad or a poster. At some point, you need to put something in front of whoever requested the design to get their thoughts.
It won’t be the final product because you want input before putting in too much potentially wasted work, so the images might be for placement only, along with the body text. But the critical aspects will be captured: typeface, palette, general layout, and relative dimensions — enough to communicate where you’re headed so you can get meaningful feedback and shift your direction as necessary.
That’s a prototype. It only differs from a UX prototype in that the latter is interactive, because that’s one of the aspects you need to communicate for that kind of design. But the same thinking that lies behind your poster mock-ups or ad concepts informs building a prototype. And the goals are identical: learning enough, early enough, to correct the course and save time and trouble down the road. You’ve been prototyping all along.
Prototypes are hard to build
I won’t lie: many prototyping tools demand a real investment of time and effort to master, and if you’re part of the gig economy, it’s likely you’ll be asked to use many of them. Yet a lot of the hardcore packages are most appropriate for building data-driven simulations that blur the line between prototype and final code.
Fortunately, there are now many alternatives for code-adverse creatives (like yours truly). These lightweight tools are much easier to learn and generally draw on patterns and approaches you’ll recognize from other software that should be familiar to most designers. Match the tool to the job and push back if you’re asked to use the equivalent of a sous vide cooker to make instant ramen.
Prototypes are too time-consuming and a waste of precious time
As noted above, contemporary designer-friendly prototyping tools recognize that we’re all working under often unreasonable time constraints. So while you may have had bad experiences in the past, I’d urge you to check out the newer options and see if you still encounter the same problems. If you choose the right tool, it shouldn’t require an unreasonable amount of time to build a prototype.
Realistically, some factors can extend your build time. If this is the first or second prototype you’ve built using a particular tool, it’s going to take a little longer than later efforts. But that extra initial time is an investment that will pay dividends in shorter build times down the road.
A complex interface is also going to require extra time for prototyping, both in minutes spent in its construction and in identifying new components and interactions necessary to render it faithfully. But complicated designs should usually have more generous overall timelines, which can better accommodate time set aside for prototyping.
Finally, don’t think of prototyping time as a simple addition to your project’s timeline. This is time that can often be made up down the road, by avoiding additional design cycles to win stakeholder sign-off or by front-loading what you’ll need to hand off to developers. Depending on the tool you employ, there may also be opportunities to shift some of the specification work downstream.
My project isn’t a good fit for a prototype
You’re likely wrong. Yes, there are instances when a project schedule simply doesn’t allow room for building a prototype or for making timely use of feedback from its presentation. And I suppose there may be interfaces so simple and straightforward that a prototype would add nothing of value. But generally, this is a tool that’s both applicable and helpful for the majority of UX designs.
I’m not the proscriptive guy that will tell you you’re a careless designer because you haven’t made room for a prototype in your process. If I’ve learned anything over the years, it’s that there are no absolutes in design, and when all is said and done, trust the judgment of whoever is on the ground. But I do think that you should push yourself to see if prototyping might aid your process.
And finally some words of advice
Find the right level
Don’t go overboard. You’re not building the final app (or even the final design), so try to stay focused on your goals for the prototype. What do you want to demonstrate? What needs more explanation? What is superfluous? It’s all too easy to get lost down the rabbit hole of “this isn’t precisely right” when the whole point of the prototype is to figure out what is right in the first place.
Trying to capture every possible user path or flow at the early stages can be a thankless and self-defeating exercise. Focus on the core user journeys first, building out the bones of the app or experience, and then go back in and progressively add layers of detail as the project progresses. That way, you won’t have to untangle everything as shifts in hierarchies or flows happen.
Image by Adobe XDDon’t try to force it all in a single prototype
Your final interface might involve disparate experiences (such as distinctive paths for different personas), but your prototype doesn’t need to (and probably shouldn’t) try and include them all. It’s better to build independent prototypes for alternative paths — they’re easier to update and can be presented separately to different groups as necessary.
If they need to be user-driven, consider placing them in a shell interface. The initial home screen falls outside of the interface and offers multiple entry points (each corresponding to a particular user path, for example) that allow the visitor to select a journey. Add persistent links back to the home screen and make sure the last step of any path returns the visitor to that starting point.
Think seriously about how to publish your prototype
Your options here may be limited by the tool you choose, but give some thought to how to share what you’ve built. Will you present it in person, with full control and a live commentary? Will you offer a stand-alone experience people can click through on their own? Or will you record a walk-through and make that available to reviewers? Also consider whether instructions and annotations are necessary in the prototype itself and how you’ll gather feedback.
Don’t go it alone
There’s a wealth of information available on how to use prototyping tools, best practices, and tips and tricks developed by other designers. I recommend seeking out hands-on tutorials (like Adobe’s Wire Kit, downloadable here) that give you a project to play with. You can glean a lot from watching videos, but it’s always more effective to roll up your sleeves and actively engage.
A final thought
There are all sorts of sensible and rational reasons to build UX prototypes, but what is the ultimate argument for prototyping? It can be an awful lot of fun. Watching your designs stir to life — and being the person animating them — is deeply and fundamentally satisfying. I’ve never gone full Young Frankenstein and shouted, “It’s alive!” in the grand theatrical manner, but I’ve come pretty close.