Creating a big new feature, or making drastic changes to an existing one, can be one of the most enjoyable and stressful parts of product management. We do our homework on the front end — digging into use cases, business needs, technical constraints. But it’s less common that teams have the time or resources to prototype various iterations of their product with customers — let them test it, play with it, break it — before teams build it. Rapid prototyping is a great opportunity to not only learn things you can't learn from a user interview, but also to build support for a big investment across your team.
Rapid prototyping isn’t a new idea, but it can be hard to take that extra time upfront when the team is negotiating demanding deadlines. Validating an idea does not put pixels on a page. What it does do is save engineering time and churn, an embarrassing conversation during leadership review, and it could reduce or eliminate the need for costly A/B testing — potentially getting your feature to market faster. With a thoughtful setup and focused goals, prototyping can be a modest, and worthwhile time investment. Here’s some tips for setting up a successful prototyping test session.
The basics: test a question or hypothesis. Don’t show users a bunch of pretty designs and see which one they like the best. Have theories about what might work and why and have users interact with the design(s) in a way that tests that hypothesis. This should be basic, and task-oriented tests are the best. For example: “Is it easier for users to find information on their portal when all the information is at a top level, or when that information is organized under headings and collapsed?" Ask your user to find a specific piece of information in both paradigms without guiding them to the answer. The goal isn’t to teach the users an interface, but rather to make note of how the users weren’t intuitively learning it. How did they get lost in the menu? What questions did they ask?
Second: have a clear persona or user group on whom you’re trying to test this hypothesis. A software engineer is going to navigate your site differently than a salesperson. If you’re using really basic prototypes, see who you can tap from your personal and professional circles that isn’t overly familiar with the project, fulfills that persona, and is an appropriate audience for rough working mocks.
Last: bring in the team! It can be really rewarding for engineers, designers, and even collaborators from adjacent teams, to see users interact with proposed features in real time, before they begin building. Partners will often point out things that product may not think of, and giving others the opportunity to see that future state clearly can be really motivating as the team or org begins a big project.
What does this look like in practice? There are so many ways to do rapid prototyping, but here are some of my favorites in terms of cost effectiveness and results.
Cost: low
Ability to iterate: high
Trustworthiness: low
Paper prototypes are harder in a remote-first world, but doable if you’re creative. This is my favorite methodology because it’s quick, cheap, and fun for users and your team. Work with your designer on no more than three different designs that test your central hypothesis. Print out a set of designs for each user test, as well as a few extras that you can use to cut up and “iterate” between tests. Set up 2-4 interviews in quick succession, allowing about 30 minutes between interviews for you and a partner from your team to synthesize what you’ve learned.
When users arrive, set the context if they’re not already familiar with the product and then ask them to complete a task(s) using their finger as the mouse. As they “click” around, you can put down new screens, modals, etc and see how they react, where they instinctively look to complete their task. If you see people struggling, see what their instincts are telling them and ask why? Is there a part of the user interface that “feels” like the place they should be able to complete the task? If you see patterns, you can take the time between interviews to iterate on your designs using scissors and tape.
Cost: med
Ability to iterate: med
Trustworthiness: med
Clickable prototypes follow the same basic principles as paper prototypes, but this methodology is more remote-friendly. You can use those same mocks in a tool like Figma, ProtoPie, etc. I’ve used layers and hotspots in Lucidchart to create an “interactive” experience that changes as layers of mocks are hidden or revealed as users click on different elements in the mocks.
Same as above, try not to guide the experience too much aside from setting some initial context. Just give the users a scenario and a task (“you’re an HR manager looking at an org chart, where can you find salary information?”) and see what they do. Watch where their mouse goes, watch where their eyes go. What are they expecting to find, and are they finding it?
Cost: high
Ability to iterate: low
Trustworthiness: high
This last one is best saved for when you a) already have good direction from cheaper testing and need to fine tune or b) you have a very costly investment with a lot of stakeholders that needs high confidence. Again, the basic framework is the same, execution is just a bit different.
Define your hypothesis, or perhaps a point of contention among your stakeholders (whose feature gets to live in the navigation and whose is relegated to the footer?) and work with your team to decide on the minimum viable product that could in/validate that hypothesis.
Dev environments vary, but my teams have used a test branch to build out a quick prototype with throwaway code, and granted time-limited and/or password-protected access to users for the duration of the test. It doesn’t have to work very well! You just need a believable enough version to test. It can be helpful to timebox your engineering team to a day or two and work with whatever comes out of that. I’ve seen engineering teams have a lot of fun with prototypes because it’s so different from their typically overhead-heavy development cycle, they can build quickly and see results without the fear of breaking anything. It can also be fun to get engineers’ help testing their prototypes, and can build buy-in and trust in your discovery process.
It can be hard to find the time and resources to properly conduct early stage validation, but it is critical for discovery, and ensuring you are making the right decisions. If you and your team don't have that bandwidth, a Fractional Product Manager could be a solid investment to ensure you get the necessary validation while not distracting full time product managers from other critical investments.
Whether conducted in house or by a trusted partner, prototype building and testing can be a great way to validate your investments, drive team bonding and morale, and create longer term buy-in among partners and leadership.
Jen Wulf has a decade of experience in tech, building products for companies like American Express, Better Mortgage and Lucid Software. She loves getting to know what people need and what makes them tick, and rallying a team behind an idea. Outside of work, she can be found in the mountains, climbing and skiing with her two dogs.
