Sometimes the most effective way for a team to reason about an idea, is to build it. Wireframes are great but a prototype is far more persuasive. Beware however, prototypes have an ugly tendency to morph into the real project or become a blackhole of time. Follow these 10 tips and keep your prototype on track, and most importantly, get the project commissioned.
Setting your self a tight deadline ensures you cut all the extras and focus on what matters. The actual duration of the project is situation dependant, however, I would suggest 2 weeks is ideal. It can be helpful to split the time available in half. Use the first half to focus on the look and feel. Then, in the second half, add as much high value functionality as you can. Never, extend the deadline!
When it is understood from the start that the code in the prototype will never see the inside of a real project, it free’s everyone involved to just make things happen. Maintenance is not an issue as the duration of the project should be far too short to need any!
A prototype should look good but getting the look right can take a very long time. I highly recommended using a template to jump start the process. Getting 80% of the way there right up front is worth it’s weight in gold. If you’re not familiar with it already, go checkout https://wrapbootstrap.com/ for an impressive gallery of full featured and affordable templates.
I feel dirty just writing that sub heading but when it comes to a prototype the normal rules don’t apply. The time frame should be so tight that maintenance will never be an issue. Besides the code will be thrown out on completion so why bother?
Keeping everything in as few files as possible, preferably in one, cuts out needing structure the application. The real saving however, is not having to think and plan how to structure. Everyone knows where the code is and how to find it and it’s amazing how quickly you start to recognise the shape of the content from scrolling up and down it regularly.
When it comes to hooking up functionality it’s tempting to start building real interactions. Stop, don’t do it. They take a long time and are essentially the heart of the real application. A simpler approach is to think in scenes. Define a series of scenes and the trigger you will use to transition between them. Each scene should contain all the ‘data’ needed to set the scene. This ensures the UI looks real and gives the impression of the application working. It is also much easier to define and build.
In true agile style show and tell as often as possible. This keeps things on track and as the prototype starts to emerge it will flush out many of the assumptions that you and the product owner have.
By far the fastest and easiest way to get ideas out is to use pen and paper sketches. Get a photo of them and use them as a reference guide. When things get unclear they are always a handy asset to refer back to.
It used to be that the very first thing I would kick up in any project, prototype of not was a database. Just dont do it. They have a tendency to make you focus on the wrong things. A prototype is all about the outward appearance not about the underlying data structures. Focus on capturing the essence of the idea not the specifics of data. Interestingly enough, this process often reveals a lot about the data structures for when you come to tackle the project for real.
Remember the purpose of a prototype is to be shown and demonstrated. Therefore you can’t ignore deployment. A really great, friction free way of achieving this is to use GitHub and GitHub pages. This gets you version control thrown in, just in case you go to crazy, you can always backtrack. I would also recommend using a simple very low friction team board like Trello. It’s so easy to use that you will probably question if you need full featured project system for your real projects.
I hope you found this lighting guide to building prototypes helpful. If so, why not share it on twitter!
I'm a professional software engineer of near on 15 years. Lucky enough to work for a small but rapidly growing company in London called Redington. They have given me the technical freedom to learn some cutting edge technologies like CQRS and Event Sourcing. Now I'm sharing what I learn here.