- One of the main requirements of any software package is usability. The interface should be simple to use and intuitive and therefore, after a mental movie and a mental proof of concept are created and some ideas scratched down, developers should proceed with it right from the start. If the concept cannot be easily fit in a fake screen shot, then there might be something wrong with it. If the mock-up is not explicit enough by itself (and some side, contextual, annotations) then it might be too complex (and difficult to understand and use) and should be rethought.
- A UI mock-up provides an early feedback on whether the design is consistent. In the process of making the mock-up, one usually reviews its whole mental movie and his/her design notes and tries to blend them together in an accessible format. This way, elements that don't fit very well or don't provide enough value are discovered sooner.
- A mock-up is by far a cheaper validation tool than a full implementation, allowing you to spot a lot of the possible issues, very early in the process.
- A mock-up can be a great starting point for a debate or a brainstorming session.
- Unlike functional diagrams, mock-ups usually do not contain implementation hints. The construct is based only on what the user / player sees and, therefore, allows the programmer to choose the best architecture possible without any algorithmic suggestion. What I've seen is that programmers tend to take design specifications as architecture specifications, blocking opportunities for extensibility, clean code, better algorithms - UI Mock-ups are a step away from this danger.
- Mock-ups are simpler to grasp and provide better visibility to the design intentions.
- Product validation is easier to do when testing against a pre-made mock-up. It's there or it's not there - more difficult to forget features.
- Nobody likes to read lists or long documents. If ever read, long docs are read superficially and, again, some details can be lost and never get implemented. Such a missing feature is hard to discover during validation.
- Most of the time, lists and other types of documents have to the reader a different meaning than that intended by the designer (nobody understands exactly the same thing and everybody ends up with another mental image of what's required). If mock-ups are not on the paper, they are constructed differently in everyone's heads, leading later to arguments, difficult and costly implementation changes and frustration.
- The process of verbally explaining mock-ups triggers ad-hoc brainstorming sessions and clarifications. Communication and knowledge transfer is fostered as is friendship among team members.
* by UI - mock-up I mean a user interface design suggestion or a fake screen-shot of some relevant in-game (in-application) element or moment, polished to some degree