Prototype Early and Often
Develop on the Target Platform
A prototype is just that; a prototype. This means that it doesn’t have to work on all devices, it doesn’t have to look pretty and the code can be quick and dirty. However, it should be based on the target platform so that the solutions implemented to get the prototype working can serve as a blueprint or be transformed into the general solution. If the target platform can’t be used it’s a bad platform, it’s as simple as that.
Dedicated wireframing and prototyping software is often fast to produce something that might look useful, but they often fail to capture the intricate interaction models and the result can’t be reused for further development. The problem with paper prototypes and wireframes is that the end user has to be able to visualize the same finished product that the designer has, otherwise they won’t talk about the same experience or even worse; the designer or tester has to explain how it should work and feel. When that happens the prototype has gone from something useful to something that actually harms the process.
It’s much easier to show interaction and layout concepts on a real device than trying to show how a panel swipes or a photo flips using a series of screenshots or sketches. Even worse is when these kinds of prototypes are used as a requirement specification, they are usually too generic and works under ideal conditions which make them more or less worthless. However, under the right circumstances these tools can be very powerful and efficient to quickly show or explain concepts, just as long as everyone that sees them knows the limitations.
Instead of investing time in wireframes it can actually be more efficient and take less time to create prototypes on the target platform using the same tools and techniques that the shipping product should use right from the start. Developing with HTML, CSS and JavaScript in a prototype setting is really fast so there’s no excuse not to use it. The faster something usable is available the better; it can then be used for usability testing throughout the entire development process. By using the target platform the modifications can often be directly transferred to the production codebase and vice versa in order reuse as much of the work as possible and to improve the accuracy of the prototype.
Use the Real Content
By using real content there’s no risk of falling into the trap where the content doesn’t quite work with the design (common result when Lorem Ipsum is used) with the result that the content has to be changed since the design has been signed off and it’s too late to change it. Reversing the mindset allows us to focus on the content, the single most important aspect of any website or app.
For the prototype the content can be static, an alternative to quickly produce a dynamic solution is to set up a local WordPress site that can be used to test different information architecture and content models even if it’s not going to be used in production.