I have worked with some non-technical people. You have too. It really brings some interesting challenges to the table. They’re clients and stakeholders. They work in finance, marketing, operations, sales or some other functional area. Not in design or development.
Unfortunately, they aren’t versed in software development. They didn’t need (or want) to be. But they have input and often decision authority for a product I was making.
But they didn’t have the imagination to work with wireframes. They even struggle with more polished mockups. They couldn’t read through requirements or wireframes and “get it”. When we went through deliverables, they didn’t have strong opinions. I couldn’t tell if they got it or not.
This is a rip situation for flip-flopping. They agree with a product decision and then later would change their opinion. (later = the worst possible time of course)
Naturally, it would be more common with some than others.
But later in the process, everyone will definitely see the impact of design decisions. Usually during a sprint demo or a beta release. That’s when they would get it and their feedback or opinions changed.
This can be extremely frustrating. But it didn’t have to be.
Enter the prototype
I don’t remember when I started prototyping exactly. But it has become a big part of my process over the years. The format has changed as the tools have changed. But it’s definitely saved me an immeasurable amount of time and effort.
It allows everyone in the room to get on the same page and leave less to the imagination. There’s a saying that’s popular in the startup world that came from IDEO.
If a picture is worth 1000 words, a prototype is worth 1000 meetings.”
If you’ve ever done things the old way then you know, it couldn’t be more true. If you prototype early and often, there will be fewer meetings needed. Period.
How to prototype (in a nutshell)
Making a prototype really doesn’t have to be this crazy scary thing. It doesn’t need to be a massive project. With the amount of tools available today, you can get a lot done with one person working in Keynote or Invision.
Pick an appropriate fidelity
Prototypes can take many different shapes and sizes. I would adjust to where you are in your design process.
Early in your process, I wouldn’t rush through to get a polished prototype. Use a whiteboard or a notebook, take pictures and make those images clickable. That’s plenty to try it out with some users or your team early on. If you have an iPad or tablet handy, don’t be afraid to use it.
If you’re doing visual design and have some comps, you can use a prototyping tool to make it feel more substantial.
Regardless of where you are in the process, you’ll probably find the tool you use will be based on your current needs.
Pick a tool
Don’t obsess over tools. There’s tons of different prototyping apps out there. There’s probably another coming out today on Product Hunt. It doesn’t have to be the most elegant one you find and it doesn’t have to have all of the bells and whistles. Find one that makes sense to you, you can use and serves your purpose.
I’ve been using Invision lately. Other options include: Flinto, Marvel, Axure, Principle, Pixate, Framer, Keynote, Justinmind, Proto.io, Webflow, etc.
I’ll use HTML/CSS/JS for more elaborate prototypes from time to time. If you can code, it’s not a bad way to go. As long as it doesn’t slow you down too much.
Prototype only what you need to
You don’t need to build out the entire app. It doesn’t have to contain real data. It doesn’t have to show every interaction. Especially if you’re iterating on an existing product.
Depending on what you’re doing, your needs have a minimum scope. Find out what it is and stick to it.
Show, Test and Iterate
There will be limitations in any prototype. It’s ok to explain them. How you explain will likely depend on the use case. Your team probably doesn’t need your help but users might.
If you’re user testing, you know you should not lead the witness. But it’s ok to help them out once a user falls into a dead end. Make note of it though. If it becomes a trend, you may want prototype the “wrong” path a little more. This will allow you to see if they can course correct on their own.
You’re not there in the wild to course correct. Remember that.
Hopefully, you’re able to iterate on the prototype. The point was to find gaps, shortcomings, wins and to improve the design. More feedback loops are better. (…to a point of course, don’t get stuck in a perpetual beta state).
What if you didn’t have to explain so much to your clients, stakeholders and team throughout the design process? How much time, effort, meetings, deliverables and frustration would that save? A prototype can save you effort and increase your value.
And remember, a prototype doesn’t have to be as polished as the final product. It needs to get the answers you’re looking for. Don’t spin your wheels on it as much as you would your designs.