Phase four of Design Thinking is Prototype. This phase is all about experimentation. Prototypes are created per the ideas generated in the Ideate phase. This lets us iteratively narrow down ideas (based on user feedback) so that further testing can be performed as the solution evolves.
A prototype is a simplified version of the solution. Even a simple pencil & paper prototype can help teams to discover whether they're on the wrong track. Each prototype is investigated and either accepted, improved and re-examined, or rejected on based on user feedback.
The following four factors are important considerations in Prototyping:
- Form
- Interactivity
- Lifecycle
- Fidelity
As the process continues, prototypes generally go from lower to higher fidelity.
Remember, one of the main reasons for prototyping is to fail fast. Be careful to avoid the common pitfall of spending too much time and money on a prototype!
Read more about Prototyping here:
We've reached phase five, Test! But keep in mind, Design Thinking isn't linear, and the results of your testing will usually send you back to a previous phase to continue improving your solution.
In this phase, users interact with the prototype and provide feedback on the experience. The team also observes this interaction and uses their observations to inform decisions going forward.
The intricacies of user testing are beyond the scope of this course, but remember - test early and often!
Revisit the Case Study
Consider this example scenario: a municipality has an aging infrastructure and an archaic system for managing road crews. They receive numerous phone calls and verbal complaints reporting road issues. These issues are then recorded in spreadsheets or email threads before a road crew is dispatched. Many issues are never acted upon and citizens often call with complaints that repairs have not been completed.
The customer requests that a software development team provide a solution that ingests and consolidates data from multiple and varied existing data sources (email, spreadsheets) and then provides a daily report of new issues.
The true solution however - the most meaningful result - might be to provide a free mobile app that allows citizens to easily report a road issue (pothole, debris, etc.) which loads a centralized queue for dispatchers. The app allows the road crew to report real-time status of repairs.
In this example, the customer's identification of the problem is influenced by the immediate pain point of having too much incoming data in too many formats. The designer, however, delves to the root problem and envisions a more innovative solution. One that not only addresses the unmanaged data, but provides real-time feedback to the citizen, dispatcher, and road crew so that nothing falls through the cracks and everyone is accountable for the condition of the roads.
In our case study, the team may have started with a web application that provided a detailed form for citizens to enter data about a road hazard they encountered. However, experimentation (prototyping and testing) led them to a more elegant solution - a user-friendly mobile app allowing citizens to drop a pin on a map with the exact location of a road hazard. This simple experience led to more engagement from citizens, with later iterations of the solution providing real-time tracking of the progress of repairs.
Consider how far that solution has evolved from the customer's original request: "We need a system to ingest and consolidate road maintenance issues from multiple sources and in many formats." 🎉