diff --git a/define-and-ideate/README.md b/define-and-ideate/README.md new file mode 100644 index 0000000..07de6be --- /dev/null +++ b/define-and-ideate/README.md @@ -0,0 +1,40 @@ +Phase 2 of Design Thinking is **Define**. In this phase, designers gather and analyze all of the information collected during the Empathize phase. By identifying pain points and patterns in the information, a clear definition of the problem is crafted. + +Remember, as we learned in our discussion of the Empathize phase, never simply try to solve the problem as stated ([Don Norman, _The Design Of Everyday Things_](https://jnd.org/the-design-of-everyday-things-revised-and-expanded-edition/)). That issue is usually just a symptom of the underlying problem. Instead, derive insights into the core problem by synthesizing the data collected in phase one, and use those insights to articulate a _meaningful_ and _actionable, human-centric_ problem statement. + + + +
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. +
+
+ +Looking back at our case study, our customer likely presented a problem statement similar to the following: + +      _We need a system to ingest and consolidate road maintenance issues from multiple sources and in many formats._ + +But is that the core problem, or just a symptom? Wouldn't a more **_meaningful_** and **_actionable_**, **_human-centric_** problem statement be something like this: + +     _The citizens in our town need to be able easily report road issues and follow the progress of repairs._ + +
+ +After the problem has been defined, designers can begin to generate ideas for a solution. This is phase 3 - **Ideate**, and this is the place where innovation happens! The team generates the widest possible range of ideas - creativity is key. The solutions will be refined in a later phase. + + + + +

+To transition to the Ideate phase from the Define phase, teams often ask "how might we..." - so in this case our team might ask "how might we provide our citizens with an easy way to report road hazards and see the progress of the repairs?" + + +Here are some additional resources for Ideation techniques (some of them may surprise you, like [worst possible idea](https://youtu.be/XOA6s6YCKnQ)!): +- [Ideation](https://www.interaction-design.org/literature/topics/ideation/) +- [Key Ideation Techniques](https://careerfoundry.com/en/blog/ux-design/what-is-ideation-in-design-thinking)