Designing and implementing great software is fraught with difficulties. It’s a difficult process to get exactly right, for many reasons. Designers need to have an understanding of the business processes that the software aims to support. They need to act as ‘referee’ between business stakeholders, whose own agenda may differ significantly. The design process throws up questions that need answers. Clarification of detail is necessary. Decisions need to be made. Often, getting past this stage is a minefield in itself – and so, as is quite often the case in this industry, people put the blinkers on and move swiftly to the development phase.
Castles On Sand
Of course, this is often the software equivalent of building castles on sand: requirements aren’t firmed up enough, misunderstandings exist, designs aren’t adequately thought out. The venture is doomed to disappoint. That is, if it doesn’t fail completely. And what do we mean by fail? Failure, in this sense, is anything which doesn’t meet the expectations of the business or the needs of the user. That’s before we factor in timescales, budget and resourcing.
So, to the question posed at the top of this article: why prototype?
Prototyping, in essence, is the building of models to help people visualise something. In our case, a software design. On paper, all but the most simple designs are difficult to picture in our minds. People are generally poor at visualisation based on written descriptions, but very good at using their eyes. We are good at imagining finished physical objects based on scale models, or mock-ups. We can gain a very good understanding about how a thing will be, without that thing having been built. This is the power of the prototype.
In business software, we don’t deal in physical objects as such, but the principles apply none the less: models which illustrate a conceptual system in such a way as to make it easy to imagine the finished system.
Time well spent!
Spending some time designing prototypes of software designs is generally time well spent. The creation of the prototype itself forces the creator to really think about how a system will be used, and how it will fit together. Questions will arise about different aspects of the design and how well it addresses business requirements. Alternative approaches to particular parts of the design can be evaluated and the ‘best’ one selected.
The process of prototyping in itself is powerful, but if we use these prototypes to solicit feedback from the intended users and the project sponsors, we can pass this information back into the design phase and refine our models. Though we hate buzz-words, the word ‘leveraging’ springs to mind – in other words, getting the maximum benefit out of the process.
Doing things in this way, with a number of cycles or iterations, really makes an enormous impact into the likelihood of achieving project goals and meeting expectations. This process can be short or extended, depending on the size and complexity of the project.
The real beauty in this approach lies in the fact that this ‘requirements prototyping’ is an interactive process involving the very people who would traditionally have less input into things. They are given an opportunity to shape the direction and design of the very systems that they require. This process significantly reduces ‘requirements mismatch’ – that is, the difference between what is asked for and what is delivered.
Of course, none of this comes for free – the skilled requirements prototyper is both a technician and analyst, with a liberal sprinkling of consultant and negotiator! To add real value, such a person needs to be able to manage and co-ordinate the entire process so that the design effort is not derailed into endless refinement cycles. This can and does happen, so requires a steady hand at the helm to avoid.
The key here is that it is important to use someone with the right balance of skills. Such people are surprisingly rare, but worth seeking out. At Reynard Thomson, we set out with the aim of allowing companies to benefit from our own experience (and the right blend of skills) at a competitive rate, without our customers having to commit to train and retain their own requirements prototyping specialists.
We could wax lyrical about the other benefits of prototyping in the software development process – but if you’ve read this far you’ll probably already have a good feeling about what makes it worth the effort?
To revisit the question we posed in this article:
Why prototype?
Simply put: if your software project is important then you cannot afford not to!
