Simple mockups are not good mockups
Disclosure: the writer is Co-Founder of www.ux-app.com, a tool that attempts to offer a complete browser based solution to mockup & prototype your application.
I believe that the “quick prototype” idea is a fad, a fad that will go away as more complex applications will need to be described and teams realize that it’s silly to forgo the benefits of a solid plan (a prototype).
If you only have an initial concept, care deeply about your present comfort and don’t have to worry about managers, workers, or partners understanding your intentions then a quick n’ easy prototype may be right for you. But you can be sure that anyone who touches your creation will want to play with all the bits & pieces that make your concept unique, clicking and tapping everywhere that looks interact-able.
They will get stuck and come to you asking for explanations.
Prototyping thoroughly, and moving beyond linking a few hot spots creates a real solution and gives you time to consider the many aspects of your initial concept and revise less successful ideas. You’ll notice things that don’t make sense and have the time to fix them before awkwardly pitching an incomplete concept while filling in the important parts from memory or making them up as you go. If you want to create a well thought out product, that makes sense to an outsider, then you better put in the time to thoroughly describe the experience you want.
Conceptualizing a gallery — an example
We want to include a simple gallery so we opt for a quick and easy mockup solution. We represent our gallery on the page and position arrows for movement. Nice n’ simple right? What else is there?
Well, once implementation starts you’ll probably run into these questions:
1. What’s the maximum number of slides possible? What’s the minimum?
2. Is the gallery transition automatic?
3. How many seconds should I delay between slides?
4. Should there be any transition animation? What should it be?
5. What happens if a user clicks next? Do I stop the automatic transition or do I keep going?
This is exactly why I decide with my team!
Can you let your team decide on all of the points above? Sure! but do they have the tools you do to make correct business decisions? probably not!
A developer SHOULD look to minimize complexity, but the result will likely be a hard cap on the maximum amount of slides in the gallery, causing departments in the organization to compete for real-estate. A designer SHOULD look to maximize aesthetic appeal, but the result will likely be putting graphic elements in the center instead of your value proposition.
Your team should not be aware of the needs of other departments, the project lead represents those to the team, and where there is a a business case, the project lead will have to overrule and create personal friction when s/he could have been ready beforehand.
Fully prototyping customizable mockups (not PSDs), with a team or by yourself, gives everyone an opportunity to come up with the same questions you’ll run into mid-development before PSDs are laboriously designed. When the train starts rolling before a concept is done, a storm of revisions is inevitable, and that’s weeks, if not months, of wasted time!
