- 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.
------
Note:
* 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
4 comments:
Mockups are great, but you should still have some form of written-word spec to describe behaviours. OK, on the mockup there's a box showing a picture and some text. There must exist an authoritative text to explain what that box means and where it pulls the info from :-)
Indeed. In most cases, an arrow pointing to the text box (or any other item) and a small annotation to explain what it means and where its data comes from, on the side, is quite enough. In other cases, however, a more complete explanation is needed. However, I believe that a document should never replace a face to face discussion (or telephone, if distance is an issue).
Very hard! (Foarte tare)
I especially like the concept of the mental proof of concept. I think it is a truly revolutionary recursive logic which can only lead to endless constructive debate over one issue and this fosters indeed friendship and bonding among male and female members of a team alike. Don't you think ?
Nope. I don't think so :). I think endless written documentation and hours and hours spent without producing something concrete is the root of all evil. After a mock-up is constructed, instead of wasting time and trying to discover what is wrong with it or, even worse, consider it to be exceptional without even having the slightest feedback because nobody bothered reading my tons of pages, I think it's by far a better approach to have a colleague (or more) look at it. Simpler, faster :)
Post a Comment