One of the biggest sources of frustration that can be felt by both web development teams and clients / stakeholders in a software project arise from poor communication of the product requirements, or the willful misinterpretation of those requirements by the design and development team.
Without adequate preparation, it’s easy to start designing and possibly building a system that doesn’t fit the needs and expectations of the client, and has a high probability of failing as a product.
This preparation should start with a comprehensive discovery phase.
From the very first meeting or phone call, some discovery has begun. This part of the process is all about eliciting use cases and aspirations for the product from the stakeholders, and becoming acquainted with the client’s business domain as intimately as possible. If designers understand the sector the client operates in and their day to day processes, their design decisions will be better informed.
Software architects and web development leads will often have a high level of confidence in their own ability to design and implement a product. Human nature will often lead designers down familiar paths, adopting trusted solutions that have shown to be successful in the past. This is a reasonable strategy, but care must be taken to identify when a previous solution is being favoured for convenience rather than because it best solves the problem in hand. The discovery phase is extremely useful in highlighting these situations and avoiding making wrong or lazy choices.
What will discovery look like?
Discovery can take the form of structured workshops but will be largely conversational.
It should be informal, and collaborative in style. The purpose of this phase is to get things out of the product owner/client’s head and into the designer’s, and to document these findings. There should be lots of discussion around details - these are not presentations. Don’t be afraid to challenge, or make suggestions along the way. It should be an exchange rather than a lecture.
Discovery should be focused, but also prepared to explore ideas that may fall outside of the scope of the current phase of development. Knowing what’s happening elsewhere in the business that may bear relevance to the product being scoped is useful to the designers to avoid making short-sighted decisions that may need be refactored at a later date.
Of course, a sensible balance needs to be struck between spending too much or too little time on discovery, particularly when there are tight time and budget constraints.
It’s also helpful to engage different members of the client organisation with the discovery phase, and at different levels within the business. A big part of this process is about accidentally finding out things that could be key to the success of the product, and being alerted to possible pitfalls. Always discovering with the same one or two people may result in details being overlooked - what one person thinks is important to the business another may not be aware of. Meet the team and cast the net wide.
Discover within the business premises if you can. You’d be surprised at the amount of insight you will gain by chance this way, and how much more communicative client product owners are in a familiar environment. It also helps combat the myth of the lead developer or software designer as an immovable force unwilling to compromise or listen to design concerns.
To anticipate problems before the development stage in order to save time and money, and increase the chances of a successful outcome.
It’s a widely-accepted fact that if you look at the map before you set off, you will probably get there more quickly and with less interruption. Admittedly, since the advent of sat-nav, this analogy bears less relevance to our car journeys - it remains a reliable truth when it comes to software projects, however. We are familiarising ouselves with the terrain ahead.
It’s important that the benefit of the discovery process is communicated to stakeholders and that this process is given adequate consideration. It’s not uncommon for those paying for a project to want to ‘see something’, and having multiple meetings before even producing any kind of specification document can seem like a waste of time and money from outside the process. It isn’t. Identifying design flaws at this stage is far less costly than once development has begun, or the product is in acceptability testing.
One of the most beneficial discovery phases we have collaborated on to date was for a highly complex energy management auditing web application. The discovery phase lasted several weeks and had run into several days of meetings before any design or specification was produced. Along the way, several ideas were considered and scrapped, long before a single line of code was written. Managing the expectations of the board was a challenge for the internal product owner, but the outcome was, and is, a well-designed, robust and complex piece of software, that has required very little revision since its first release.
Discovery isn’t about big design up-front
Discovery is a very early part of the process, and will eventually lead into wire-framing, specification and prototyping.
Understandably, development teams and clients might lack faith in their collective ability to accurately identify the complete set of requirements of a product. This can lead to a fear that committing to a comprehensive discovery process will end up with them being locked into something that they can’t deviate from when it comes to build time. It doesn’t.
The discovery phase comes long before design, specification or implementation, and is about removing as much risk as possible from the project as early as possible. It’s about seeing bumps in the road before it’s too late to avoid them.
Economise on the discovery and you will pay later, and it will cost more.