How to judge a prototype
Designing interfaces, particularly complex interfaces, is a task to be done in stages. The interface will look like a building site (the beast) for a long time before it turns into a finished building (the beauty).
If you have hired a designer to design a data dashboard, for instance, there are two possible scenarios:
Designer 1 comes back with a superb design with clear graphics and icons that match your corporate style perfectly. You’re over the moon, because at long last the developers can build something that you’ve had in mind for months.
Designer 2 comes back with a half-baked design with some random elements, wireframes full of empty pages and heaps of questions. You are disappointed because it looks as if the project is not progressing.
At first sight, you think designer 1 has done some fantastic work and designer 2 can be thanked for his services, but the quicker a design is final, the quicker it can go wrong.
If your designer does not come back with questions, these questions will simply pop up later on in the project.
If your designer has anticipated these questions, the project can move forward. If not, the project will have to take a step backwards and that wastes time and costs money.
What if, during the development, it turns out that the data used by the designer don’t even exist? What if it turns out at the go-live that the fancy animations make the interfaces slow and unwieldy? What if it turns out afterwards that people using your dashboard don’t understand how to get from A to B?
Developing interfaces is like building a house. If you start with the finish and you have to adapt the electricity and other utilities afterwards, there is a good chance that you’ll end up on a building site. If you start with the building site, you might have to swallow some dust for a while, but the end result will be good quality.