Top 5 mistakes developers make when prototyping

Any good developer knows that the prototype is an essential part of the overall product development cycle even though its features and functionality are relatively limited. Saving time and money is the immediate benefit of using prototypes, whilst key insights and an awareness of the needs and expectations of development activity ahead will have unrivalled importance in the long term.

 

One way in which Prototyping is particularly useful is that it acts as an intermediary, helping the developer, the client and the end-user to share the same vision and work forwards in unison. The scope and nature of your concepts, ideas and approaches can be visualized and better understood by all involved including the developer themselves. This space of understanding encourages constructive feedback which leads to necessary modifications being made.

 

Prototyping helps developers to reduce the risk of failure by providing a space to make mistakes and errors before narrowing their design down to be the best it can be. Mistakes are, of course, the best teachers. Software development is not a process of getting it right first time; it should be a repeated process of having one good idea and a lot of bad ones.

 

If prototypes are, at least partially about letting you make mistakes before you finally hit on your killer idea, is it possible to talk about ‘mistakes when prototyping’? We think so!

 

Five Common Mistakes when Prototyping

 

1. Perfection

Steve Jobs once said that “Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.” For us, this is one of Jobs’ most inspiring quotes as it is very easy to forget that prototyping is just one part of the design process.  Always remember that if prototypes were supposed to be perfect then we wouldn’t need them in the first place. Developers are very often perfectionists, trained to seek out every single bug in pages of code. Letting go and being prepared to make a lot of mistakes (and admit when you’re wrong) is vital. 

 

2. Time = value

Time is money and it must be budgeted accordingly. Too many developers undervalue their spare time and use their resources to try and get a product right the first time and on the market as soon as possible. This can backfire when errors are discovered late, potentially racking up large costs and vast amounts of time to fix. The value of a prototype is its ability to arm a developer with the means to act in a proactive manner. Do not build more than is necessary.

 

3. Experience

Jakob's law of the Web User Experience states that “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.” This can be interpreted in many ways but the main point is that users typically fail when a developer deviates from their expectations, especially when regarding something as simple as UI controls or navigation. Remember, it is not your intention to disorientate your users, but to have them use their cognitive skills in a far more useful way.

 

4. Understand requirements before you prototype

Communication with users and stakeholders can create a situation where the end user may want to see features implemented which were not intended in the original user requirements. This can cause a situation where the users want a product which differs greatly from the prototype and increases both the development time and costs. Prototyping can be a slow process when features and goals are not clearly defined from the outset.

 

5. Inconsistency

Keeping the previous versions of your prototypes is vital to ensure you are consistent with your design and don’t end up with a subtle mistake that you don’t recognize until it’s too late. Reviewing prototypes may lead you to make some changes that you want to revert later so these earlier copies will help you to implement features you may have since altered or deleted.

 

A successful developer will use prototyping to construct a strategy for implementing the needs of the interface, behaviors and functionality of their new software. It is much easier to make drastic changes at this stage than it would be if problems were discovered at a later stage in the development cycle. It is also a lot more cost effective than the alternative as long as excessive time isn’t spent focusing on specific parts of the system at the expense of others.

 

Refocus your energies

 

Even the best developers will make mistakes from time to time. However, if we avoid making some of the more common errors highlighted in this post, then we can begin to refocus our energies on making better prototypes.

 

And don’t be too hard on yourself - remember that while end users will blame our technology if it doesn’t work for them, Sir Tim Berners-Lee himself once said, “we can't blame the technology when we make mistakes”.