I wrote this piece when new tools like Moqups and Macaw were coming out. They allowed non-coders like myself to easily create prototypes that mimicked a full web or app experience. I’m including this old piece because the current AI tools coming out make it even easier to create prototypes. The overall message is more valid than ever: “Earlier feedback. Fewer surprises. Happier developers.”
When your job is to make something for someone else (like a client), you go through a series of clearly-defined phases. Let’s take digital projects as an example — a website, an app, or a web app:
- Discovery: What is this project all about? What are the goals?
- Design: What is it going to look like? How are users going to interact with it?
- Development: Give all of this to a developer and have them build it.
- Testing and Release: Work out all the bugs and release it into the world.
Sounds pretty straightforward, right? It is. But this all-too-common list of steps leaves out a key part of the process: reviews. Internal reviews, client reviews, and other stakeholder reviews.
Digital Difficulties and The Print Mentality
A lot of people still have a print mentality: they see a design and it’s pretty easy to imagine what it will look like when it’s finished. As in, it’ll probably look exactly like the design they’re looking at.
In the print world, that’s generally true.
But in digital, showing someone a design of an app leaves out most of the experience. The design tells you what the app might look like — but often crucial questions are never even asked:
- What happens when you click (or tap) on a button?
- Are there any hover states?
- How does this look on mobile?
- What is the user’s mental state when they’re on this screen?
What Winds Up Happening
Here’s a simple example: an email subscription form with a search button beneath it. Simple enough. But:
- Is the form going to validate that an actual email address has been entered when a user hits subscribe, or when they move away from the field?
- If a user hits Subscribe without entering an email address, what do you show them? What is the message, if any?
- If a user does enter all the information, what do you show them? Another page? A message right there? Are we tracking this event in analytics?
- On the search form, how do we want to organize our search results? What is the logic?
There is a lot going on under the hood of even a simple design.
Here’s what happens when nobody thinks about this stuff until everything is vetted and approved: chaos. Because when it gets to a developer, they don’t care what it looks like. They will focus on what’s happening under the hood.
If a developer estimated it would take four weeks to build something from the time they get the final designs, and they have to stop what they’re doing to ask a bunch of questions — the timeline gets screwed. And if those answers have to be vetted by the client? Your timeline just got smoked.
The Feedback Loop is Broken
Human beings are reactionary. Give them a picture of a digital project and they’re going to react to the picture.
But give them a prototype of a digital project, and you’re going to get the most valuable kind of feedback you can get: feedback on the actual experience of clicking and navigating through the thing.
That’s the kind of feedback you want to get as early as possible.
Prototypes to the Rescue
Prototypes allow you to make something that’s actually representative of what the digital project is going to be. They become especially important since most web projects are now responsive and many clients are still relatively new to what that means.
So instead of building a picture of a website to get reviews, build a prototype as early as you can and get feedback that way.
The goal — admittedly ambitious — is to give a developer everything they need to build your project without asking a single question.
A Few Tools Worth Knowing
Prototype on Paper (POP). You start by drawing a simple sketch of an app on paper. Download the app, take pictures of each screen, and use the simple interface to wire up the buttons to other screens. Working app prototype, no code required. Great for early-stage thinking.
Moqups. A good tool for creating wireframes quickly. Easy to use, feature-rich, and can output interactive PDFs that serve as prototypes for virtually any kind of project.
In-browser prototyping. The goal is to go straight into code. You experience the prototype in the actual browser, which is where the website is going to live. In a perfect world, you can re-use the code as the starting point for the actual project.
Building a prototype early allows you to be proactive in acquiring feedback from stakeholders and clients. You probably won’t be able to answer all the questions that will come up — but you’ll put yourself and your project in a much better position by building something that’s closer to the actual experience.
Earlier feedback. Fewer surprises. Happier developers.