Prototyping traps & how to avoid them
When the opportunity to develop a prototype arises especially for the first time, its really important to get it right. The mission when first given this opportunity is to prove its a worthwhile process and show the benefits it brings to the business so you can continue to do it in the future. Its a luxury not everyone gets given and its a worthwhile tool to validate various decisions around implementation & design.
I have been involved in many prototyping opportunities and they have all had varying success which was typically caused by a few traps the team fell in to.
Because of this I have attempted to document these to hopefully save you from falling into the same traps and ensure your next foray into prototyping is a success.
Find the question.
One of the factors of a successful prototype is knowing why you are building it in the first place. Usually there are some underlying questions we are wanting answers for. Examples of these could be…
“What would an improved workflow look like?”
“What graph alternatives could we implement?”
“What if we tried implementing our application architecture using another language?”
Other times we use prototyping to test new business opportunities. You may have already developed the idea and you are wanting to turn it into a tangible visual or interactive. Usually these questions are closer to
“Is this something a customer might want?”
“We want to build something that does X, is it possible?”
The key thing to take from these questions is the understanding that what we are prototyping is to answer a question. This will help align all development or design decisions to the overall purpose.
Time box & plan.
Set yourself a time box. Be it a ‘sprint’, a week, a month, whatever is realistic to answer your overall question(s).
Once that is set spend the initial stage discussing tech you want it to turn out on. Images, HTML, video, paper, etc. Whatever it is, be clear that at the end of this process, you know what form it needs to take.
Understand what this prototype is going to be used for. If it is to be used as a sales tool for example to ‘test the market’, the prototype is going to require a higher quality ‘feel’, the focus will be on a bit of ‘wow factor’ so keep that in mind when coming up with a timeline and how you intend to build your prototype. If it is going to be used to test a workflow, then make sure your focus is on trying various workflow alternatives and not worry necessarily about the data that appears on the page needing to be ‘real’.
Once you know the tech and feel comfortable where the focus areas need to be, start sketching. This may seem silly to some, however, this is not just for your individual clarity, but for group understanding of what the final output might look like, or at least what our current ‘thought’ of what it will look like is. This sketch is then used to validate with your team and you can check that your tech chosen will support this ‘sketch’.
Now start planning how you are going to tackle this sketch. Start considering responsibilities, start thinking about how this can be implemented in a fashion that would encourage rapid prototyping. By that I mean, you need to be able to change anything, and any stage, with minimal fuss. If your tech stack you have landed on doesn’t support this, iterate & reconsider.
Know when and where you expect an ‘output’ worth being tested and what that might look like and stick by it. Treat it like you would any other project.
Iterate, Validate, Iterate.
After you have a roadmap and some time expectations, set milestone points to validate where you are at and allow the time to iterate. The more the better. Identify key stakeholders who’s feedback you trust and respect. This may be through user testing or simply a group or individuals who’s input you value.
Before showing the prototype for feedback make sure it is ready to avoid the feedback of “it doesn’t work”. If areas are not expected to work, tell the people viewing to frame what you are looking for feedback on.
Keep all the versions of the iteration cycles available for reference in the future, this will not only allow you to look back at where you have come from to show progress, but also show how many ways you have tried to tackle the question for future feedback sessions.
Watch the clock.
One big trap I have fallen into in the past is being convinced that a particular iteration ‘should work’ and ‘should answer the question’. An example is this. Lets say you want to build a component that enables the fastest way for someone to enter time on a task. You want to try and see if you can do this a) without using a mouse, and b) with using as little input information as possible. I spent days trying to get this thing to work. The problem was, I was so determined to ‘make it work’ that I lost sight in the overall objective.
Trying as many alternatives as possible means if its proving to hard, don’t force it, if it doesn’t work make a note and move on. Not every iteration can and should work.
Be Inclusive
It may seem a bit silly to put this as a key area of concern when you try out or take on prototyping, however it is important to show your work throughout the process. Prototyping is usually of interest to a very wide audience. Make your prototype accessible to anyone who wants to see it at any time they want to see it.
Document what the intention of the prototype is and how you are attempting to answer the overall question. The audience who will participate in this may offer feedback outside of your usual ‘core feedback group’ and outline areas you may have missed. They also tend to bring a bit of excitement to the whole process. By showing progress and opening yourself up for feedback around the work you are doing can have really positive outcomes for the wider team and company as a whole.
The important thing to remember when prototyping is the questions you are trying to answer are always front of mind. As developers & designers it is easy to get into deep implementation of a certain component because ‘thats what you are used to doing’, but by maintaining the overall question in the front of mind, you can really question implementation detail at any stage by asking “does this help answer the overall question?”
Prototyping is a luxury that not everyone has the chance to do, its a great process that allows you to try new ways of doing something and find multiple solutions to the same problem. I personally love the challenge and the opportunities it brings to a team so I hope bringing forward traps that I have fallen into in the past to light, helps your next prototyping work become a valuable purpose driven and fun experience.
