Prototyping: The Best Way to Get Rapid Feedback from Users
Prototyping: The Best Way to Get Rapid Feedback from Users
How prototyping helps and how you can do it right!
Welcome to the 41st edition of The Discourse. The ODNC1 cohort at On Deck is coming to a head and in the coming week, we'll have the capstone showcase. If you want to catch up with the previous 9 weeks, you can do it over here.
With that said, let's talk about Prototyping.
“Don't tell me the moon is shining; show me the glint of light on broken glass.” — Anton Pavlovich Chekhov.
My first experience with prototypes was in 2015. It was like a gateway drug to product management.
I loved taking part in case competitions. And in those, I used Invision and Marvel to simulate the functioning of two products - a Carpool app (pre-Uber pool) and a disaster management app.
Since then I’ve used it often in the last 5 years. And prototyping tools have gotten so much better!
Jobs-to-be-done of Prototyping
You want to hire prototyping to solve two main jobs:
Simulate interactions in your product to make sure all cases are covered
Get rapid feedback from users/customers on new features and enhancements
Let's unpack these two points:
Simulate interactions in your product to make sure all cases are covered
Designs are static and don't give a sense of the flow. When you're designing individual screens, it’s very easy to miss out on elements that are required as part of the interaction. There is a whole field about this known as interaction design.
It especially helps iron out kinks in the flow. For eg you will come to know if you are missing hover states, confirmation states, error states, or empty states. For e.g. if you're designing a new payment flow — you might miss out on an error screen, confirmation screen, retry screen, and so on.
You can simulate most of these in prototypes. I talk about how in a later section.
Get rapid feedback from users/customers on new features and enhancements
Feedback from users can help in 2 ways:
Knowing what to build:
Prototyping gives us an insight into what users value ahead of time. This saves hours and weeks of development time.
Besides, prototyping is the best way to start a conversation with the user.
It gives them a sneak peek into what's coming up and gives them the impression that you are co-creating with them. The IKEA effect holds strong here.
Knowing how to build:
It also sheds light on the features that aren't clear and obvious when we first design them.
This allows you to rapidly fix it in design before building in code.
Addressing common arguments against prototyping
Prototypes are not the real product — users will not know what to do
One way to address this is to give a heads up before sending the prototype. So the user knows that this is a prototype and expectations are set. A few pointers about how to go about using the prototype. Teach them about hotspots.
Since the prototypes are not the real thing, we will get invalid feedback
The quality of feedback lies on a continuum. At one end of the spectrum is the shipped product. On the other end is a few words describing the feature. Prototypes lie somewhere in the middle, and often towards the side of the product.
Not everything can be prototyped
While that's true, a good extent of most features can be prototyped. Libraries like Anima make even sound prototype-able.
Should we just build and test directly?
Building code has opportunity and maintenance costs associated with them that often go undiscovered. If you build a feature that no one wants, you will still have to maintain that feature in the long run.
Prototyping is a cost-effective way to test new features with no overhead. And especially useful for testing features that don't have a known high impact or confidence.
How to prototype it right?
I'll explain these points with the help of an example. My designer friend, Apra worked on this prototype for an internal company podcasting app.
Figure out all the interactions that are likely when building a prototype
In this example, it was important to test out listening to a podcast and creating a new podcast.
Set up all the back-flows
Each screen should have a clear way to go forward and to go back. So that if the user is stuck anywhere, they can reset to the main screen.
For e.g. here the back, cancel, and start now flows are created.
Configure all the micro-interactions
The prototype should contain all micro-steps and interactions that will take place in the actual product.
For e.g. here we allow the user the option to record again, in case there was any mistake. That button takes the user back to the start of the recording.
You can extend the functionality of prototypes further with plugins like Anima.
Tools to Prototype with:
If you want to build something more advanced than a prototype but not yet ready for code, consider using no-code tools to bridge that gap.
Prototyping solves the jobs that it's hired for. More teams should prototype features to convert prospects into customers, build a rapid feedback loop with users, and become a high-performing product team.
📘 Read of the week: Writing is Networking for Introverts - Byrne Hobart (5 min)
That's it for today, thanks for reading!
Do you prototype features at your work? Reply or comment below, and I'll reply to you. Give feedback and vote on the next topic here.
Talk to you soon!
— Kavir
Press the ♥️ button if you liked this edition.
👇🏽