This is Part 2 of a two-part series on the discovery process. To explore the earlier stages of discovery, read The CTO’s Guide to a Killer Discovery Process: Part 1.
Requirements gathering lays a solid framework for a project. Once the initial set is gathered, the developer has a general feel for what their client needs.
The next step is to visualize the solution in a way that allows all stakeholders to understand what it could look like at release.
In other words, it’s time to build a prototype.
Visualizing A Solution
A prototype is an interactive example of the proposed solution. It serves to validate the assumptions gathered from the client and allows for quick feedback.
Reviewing the prototype also gives the developer a better idea of the project’s intended scope.
This phase is just as important as gathering requirements. A well-constructed prototype helps clients fine-tune their requirements earlier, which makes estimates much more accurate.
In fact, solid prototypes are the key to a more profitable development process in general.
Wireframes are useful intermediary steps, but they don’t make very exciting presentations when trying to win over clients.
Software like Invision & Indigo Studio are excellent tools for creating interactive, highly visual prototypes.
Highlight a specific user flow to model the product’s main functionality.
Clients should be able to approximate usage closely enough to determine if there are missing steps or features that need to be added.
Resist the urge to get too caught up in design before the client sees the prototype.
Focus on bare functions at first. Have strong visuals, but don’t spend days on custom art assets that may get cut out as requirements are refined.
Only bring the design team in to polish the graphics after the basic functionality is approved.
Allow time for back-and-forth discussion on the prototype. This is the least expensive time to make edits or alterations, so encourage the client to share any concerns.
It’s also a good point to demonstrate additional features or expansions that could improve the final product.
Once the prototype is approved, create a detailed requirements document. List and detail every feature according to the user story.
Don’t just create a sparse feature grid; using visuals to communicate will prevent misunderstandings later on.
After the details are documented, work with the development team to get time and cost estimates for each part of the solution.
Start with broad estimates and work inward. Leave room for flexibility and changing requirements, but don’t pad the estimate unfairly.
Come up with a range where the developer can confidently commit to delivering the project.
Be clear about what the initial estimate covers and how changes would affect the price. Consider including varied tiers to illustrate what can be added later.
All of this leads to the final presentation. This is where the client is given a document which allows them to fully understand what will be built.
Clarity is essential in the decision-making process to approve the project.
Provide full transparency on what it will take to deliver each feature of the final product, and outline details like cost, processes, and schedule.
Good communication gets the project started with a clear vision for what the end deliverable should be.
Earlier phases should have ironed out the majority of issues, so this is essentially a review of everything that came out of the requirements gathering and prototyping phases.
In other words, it’s “reading back the order”.
A final word of warning: don’t rush through the final presentation assuming everyone is on the same page.
This is a developer’s last chance to wow the client and build confidence in their ability to deliver a killer end product. It will either win the client over- or send them looking for another developer.
Concepta takes a detailed, collaborative approach to discovery that’s proven to deliver products that meet our clients’ most pressing business goals.