We will begin with the information gathering and problem definition phase. As a team, you will collect information about the project, especially in terms of the following:
Although the internet is a good source of information, it should not be your only source. Databases and reference texts such as the World Bank Development Indicators, The Economist Intelligence Unit Country Profiles and others can provide valuable background information.
The following reference materials are among those suggested by the MIT Libraries:
(Note: Here's the MIT Libraries' full list of D-Lab research references, if you're at MIT or have access to an academic library. Most of these are available only with an institutional subscription.)
Most importantly, try to consult your community partners and those people who have helped to develop your challenge. These people will be familiar with the context, needs and users for whom you are designing.
This information will be incorporated into the project background presented at the Ses #11 design review. Each team member should turn in a one to two-page summary of their research findings at the review session.
Now that you have a good background about the challenge, it's important to frame the problem. What aspect of the problem will you be addressing? Who are your users? Who are your customers? (They are not always the same.) What do your users and/or customers actually need? It may be different than what they say they want—they may have framed the problem in a way that suggests a solution. It is important to go back to the basic requirements and build upon that. Think carefully about the stakeholders who are involved in this project, and those that you are including in your solution. Think of several different problem framings and collect more information about each so that you can choose the best one.
Each team should present their problem framings at the Ses #11 design review and describe which one they chose and why.
The problem statement should be a concise description of the design problem and its context. It should include only the functional requirements of the device and not components of the solution. The aim of problem definition is to clearly outline the problem on which the team will focus. Be sure that the problem defined is measurable and observable. Address the following questions:
Don't state the problem as a question or give a solution or cause of the problem in the statement.
As a team, develop a concise problem description to be presented at the Ses #11 review session.
Now that you have an idea of the scope of your project, it is necessary to determine the user's needs and convert them into specific design requirements. Start by generating a list of client needs. When possible, try to get information directly from the people who will be using your product. If this is not possible, then identify several people who are knowledgeable about the topic and get their input. Once you have the list of customer needs, decide upon the metrics (measurement methods) that you will use to determine whether you have met these needs. Assign acceptable and ideal values to these metrics and use this to create the design specifications for your project.
As a team, develop a spreadsheet or other clear document that outlines all critical design specifications, metrics used and acceptable/goal values. This should be posted on the team wiki, and summarized and presented at the Ses #11 design review. Each team should also print out a copy of this document and turn it in at the review session.