When creating a new feature or product there is a lot of stuff to figure out.
Diving straight in and building something isn’t always the smartest thing to do. You need intermediate steps, you need to gain confidence. Is what you are building, or going to build, the best way to help a user achieve their goal? Is it feasible to build?
This is why we sketch, mockup, prototype and iterate. Each step we learn about our problem and solution, each time we gain confidence and reduce risk. Each of these steps takes time. Are we playing it too safe, at cost of progress? Should we sketch, mockup or prototype everything, in favour of reducing risk?
An interesting way to look at this is by using a fidelity curve. I got to know the concept from a post from Ryan Singer at Basecamp. In his post The Fidelity Curve: How to weigh the costs and benefits of creating UI mockups he explains the concept as follows:
I like to look at that trade-off economically. Each method reduces risk by letting me preview the outcome at lower fidelity, at the cost of time spent on it. The cost/benefit of each type of mockup is going to vary depending on the fidelity of the simulation and the work involved in building the real thing.
Depending on the feature you’re working on, these levels of fidelity take different amounts of time to create. If you plot them in terms of time to build versus confidence gained, you could imagine something like a per-feature fidelity curve.
A fidelity curve could look like this.
The time to achieve the confidence level of actual implementation is reduced significantly. At the same time we already have assets ready to start developing the feature.