I’d like to introduce the idea of a mock-up. It’s likely the cheapest prototype you’ve ever made, but it may be the most valuable one on a project.
Mock-ups should be used early in projects, ideally during user-needs research activities. This allows teams to test concept ideas with end-users quickly.
Mock-ups help internal teams during concept-development activities to test ideas quickly. They help speed up your development efforts in creative ways. They allow teams to evaluate multiple solutions quickly so they can determine which path to focus on.
The mock-up is also the prototype that will likely generate the most honest and unbiased feedback from your users. As opposed to a mock-up, when you show users a polished, beautiful prototype, what users see is all the time, money, and energy spent in designing and making it. The perceived investment in the prototype makes them less likely to provide a candid assessment, even if the concept doesn’t address a need or problem they have. With a mock-up, they will be more willing to criticize the idea.
Furthermore, when your development team has spent countless hours making that polished, beautiful prototype, those team members get emotionally attached. Some will mainly hear the positive feedback from users, ignore the bad. Others may go as far as to defend the idea versus listening to their customer.
No one likes calling their baby ugly.
With a mock-up, it’s easier to remove bias and emotions. This is obviously a throwaway prototype.
However, I’ve also witnessed how mock-ups can backfire on development teams when they present them to other individuals without proper context. Or, when a high-fidelity prototype was needed to extract the information required at the time.
So let’s dig into the idea of a mock-up further:
- What is a mock-up and how is this different than a prototype?
- When should you use mock-ups during development?
- How to best present them to your customers to gather the feedback you need?