I like to classify prototypes into:
- Greenfield: The product or feature simply does not exist in our/closely parallel systems. "Build it!"
- Redesign: Re-imagine an existing product, feature, or process to achieve specific objectives. "Re-build it!"
- Enhancements: Achieve specific objectives while retaining a majority of the current product/feature/process. These usually fall somewhere in between "Fix it!" and "Make it better!"
In this post, I wanted to concentrate on one specific aspect of greenfield and redesign projects: how to begin designing the initial prototypes. No matter how many architects and product designers work on the project, I believe the PM is central to this stage.
Also, prototyping is a game of speed - so if your PM can hash this out instead of waiting on an architect or product designer, then you do have a material advantage.
Listing some methods here, as I find these are surprisingly under-utilized by many good PMs.
Please note that these come into the picture only after you attain significant confidence in the problem and the solution. That is, once you are sure that:
- X is a big enough/painful enough problem to solve (eg. sales folks have trouble managing their work)
- Y is the general direction to go (eg. CRM)
Start from the central workflow
The central workflow makes for a good starting point, if it can:
- Define your product/feature's core value, and/or
- Define/dictate most of your architecture or data flow,
Example 1: e-commerce. Take a typical customer's product discovery + order funnel flow happy path. This is a good foundation. Your engineers can later define services, data structures, etc., based on this flow.
Example 2: L1 support. Start with a typical support ticket lifecycle. This can help you nail down all the systems/references/data required for your support team. So you can start to build/buy their tech.
Start from the core data
Building a semi-independent feature or service inside a mature system? Then it may make sense to start from the core data.
Let's say you are launching a wallet or a credit card. You know that the core data structure has to be a ledger of some sort. First, decide on the base logic for this ledger. Then, it gets easier to figure out the data, connections, and states/statuses required. Finally, you can add conversion thresholds, fraud detection parameters, and other high-level logic.
Draw the box
Scenario: You have to enhance or expand a user experience piece. But you have no control over back-end enhancements. Then you have no choice but to start with this end-user task. This is quite different from starting with a workflow, where you have control.
Example: UI to enter trip details to book a flight. Your ideal answer is somewhere in between two extremes: A lengthy, "serial" set of modals and a massively "parallel" text input form. Once you identify these extremes, it becomes easier to box your/your designer's thinking.
Paradoxically, this also helps us do blue-sky exploration: simply drawing the box may help us think outside of it.
Start with an offline equivalent
In some cases, it helps to skip existing "digital" versions of a process. Starting from its older, physical versions helps you:
- Avoid others' mistakes
- Reach first-principles immediately
For example, at enPardigm, we found that insurance salespeople had terrible software. But instead of enhancing or re-making an existing product, I went to folks who used no digital tools at all. This helped me could start from field observations and first principles.
Start as a service
(the other SaaS :D)
This is difficult for those of us who worship scale and low replication costs. Often, it helps to first launch a manual, service-driven, utterly un-scalable version. Simply to understand what works best.
This applies to both:
- Small feature enhancements. At enParadigm, we once opened up direct phone support to figure out how to build contextual help.
- Product extensions/entire product lines. Some of Razorpay's marquee products started as people + excel sheets.
Start with the 'closest match' system
If you are the "Uber of X", then it makes sense to use Uber as a starting point for your product design.
What's surprising is that we can express most non-critical features as "X of Y". Once we open our minds to that, product design gets un-stuck real quick.
Start with a friend
There's nothing scientific about this last method. But it works. Like the Beatles' songwriting, product design also tends to "flow" when you start with a friend. A designer, an architect, or even your friends and family can help get you started.
So, to sum up. Knowing these starting points can help you get un-stuck when starting off with a prototype, or even the product itself:
- Start from the central workflow
- Start from the core data
- Draw the box
- Start with an offline equivalent
- Start as a service
- Start with the 'closest match' system
- Start with a friend