Research is “[t]he systematic investigation into and study of materials and sources in order to establish facts and reach new conclusions.” (source, 27 March 2013)
Research is about generating or finding information, which is always done for a specific purpose. To make sure you're doing the right research, you need to understand very clearly (and document in your design journals1)) what your purpose is.
The output of a research task will be needed at various points in the future (for subsequent tasks; for report writing possibly in a relatively distant future) so it's vital to document you research. This includes not only the questions that drove the research and the answers you developed, but also the methods by which the research was done and the sources where the information was found.
In designing, any task that leads to questions is a natural predecessor of a research activity. These tasks include, for instance, kickoff meetings, and after constraints have been established the specific values of which you cannot set immediately, or at the beginning of concept design.
The results of research tasks feed forward to subsequent tasks that cannot be executed until questions raised pre-research have been answered. In design, examples of these post-research activities include documenting product strategy and ideating embodiments.
To do research effectively and efficiently, you need to identify, as specifically as possible, the questions that the research will answer.
There will likely be several questions to be researched to address some specific design issue. It makes sense to divide those questions among all the members of your design team2). That way, you speed up the research process by parallelizing it. Also, you reduce the possibility of duplicating the specific research tasks (outlined below) thus minimize wasted effort.
It is likely that some questions will be harder to answer than others. Be aware of this when you divide up the questions among your team members. One member may get two easy questions to research, while another member may get only one question because that question is harder than the other two.
To keep the project on schedule, make sure your team agrees to a reasonable but hard deadline for completing the research.
There is nothing wrong with basing your design on existing technologies and devices, so long as you give due credit to that “prior art” in the field. In real life, one would have to worry about intellectual property and whether you can use existing work without getting the designer's/inventor's permission. This is a legal matter, and doesn't concern us in learning environments where the subject is design (rather than law). Nonetheless, proper attribution of the work of others is absolutely necessary - not attributing the work of others properly will lead to charges of plagiarism.
The obvious way to search for existing answers to your research questions is via the web. By some estimates, Google has indexed over 55 billion web pages as of March 2019 - if it's out there, it's likely that Google can find it. There are, however, several potential problems with searching the web.
Patent searches are another way to quickly discover “prior art” in design. A patent is a legal document describing an invention. Not all patents are good ones, but sometimes one can find very interesting ideas in them. While Google and other search engines can search patents (usually only American ones) for keywords, you can also directly search online patent databases for free. Here are some links to patent search engines.
A subset of web-searching is searching of online catalogues. For instance, ThomasNet - aka The Thomas Register - is an online collection of catalogues including over 500,000 companies. Because the items described in these online catalogues are not “popular” in the general population, it is unlikely that they will show up in conventional web searches. To get a sense of how many catalogues are available online, try this Google search.
Another source of information about existing designs is the Consumer Reports website, which can help identify good and bad products, albeit only in the area of consumer products.
A more “old-school” approach is to search actual stores in the real world. Depending on the nature of your design brief, this may not be possible. However, if it is, then you should take advantage of it and visit at least a few different stores that sell products or services that are related to your design brief. Interview employees if possible. It is often the case that if you explain you're doing background research for your coursework in university, store managers and other employees will help you. Being able to touch, feel, and maybe use a product directly is far more useful than just reading about it on the web.
Another “old-school” search method is to go physically to the Ryerson Library. There are subject matter experts on staff at the Library that can help you quickly find material - both in hardcopy and online - relating to the questions you have.
A related search technique involves speaking with “experts” in fields relating to your design problem. This includes friends, relatives, and team mates who may have useful experience.
No matter where you search, do not only search for the obvious things, but recognize that good ideas may come from “left field.” Consider similar problems in other places. For instance, if you have to design a way to re-stock shelves in a grocery, investigate how warehouses, docks, ships, and aircraft are restocked too. This is called analogical reasoning and is an important way that design problems can be addressed.
If you cannot find the answers to the questions you've posed yourself, you would normally refer the matter to a domain expert - a scientist to determine the nature of physical phenomena, market researchers to determine business cases, anthropologists to study human behaviour, and so on. However, consistent with the Pareto Principle, it is possible to find some information on your own. It may not be the best possible quality, but it is sufficient to get some answers.
You can interview prospective users to discover what problems they have with particular products. The advantage of interviews is that they are interactive, and the interviewer can ask follow-up questions to particular answers given by the interviewee to drill down into the details of specific situations. The disadvantages of interviews are that they can be very time-consuming, and that the interviewer may inadvertently introduce biases that will alter the interviewee's responses.
You can also quickly generate online surveys (using, for example, free services like SurveyMonkey) to gather information from arbitrary people. The advantage of surveys is that they are faster tools to use to reach more people than interviews. The disadvantage is that the answers may not really be that truthful.
You can conduct surveys and polls on various social media. Reddit is a particularly interesting one because, if you post in a good subreddit (like /r/SampleSize), you can actually expect fuller, more detailed, and legitimate answers.
In all these cases, however, you don't want to ask non-specialists (prospective users, for instance) what they want, because they will rarely know. By asking prospective users what they want, you are in essence asking them to design something - but that's your job, not theirs. Users rarely know what they want till they already have it3). Users are, however, experts in telling you what they don't like about the current situation or product that they are using. Thus, when gathering this kind of information to answer research questions, you should focus only on what users find to be issues and problems with the way things are.
There are many conventional tools that can be used to estimate quantitative values.
For instance, say you need to estimate the average commuting time in Montreal, but you have not been able to find usable data with Google search. You can actually work out a reasonable estimate as follows:
Assuming different aspects of research were conducted by each member of your team, you will end up with a collection of relatively disconnected results. Many of the truly useful results of the research exercise may be only implicit because of their disconnected nature.
So it's important to integrate the results of your research into a meaningful whole once the research is completed.
Once each team member has done their part of the research, hold a team meeting where:
It makes sense that before this meeting, each member shares their results with the rest of the team - via email or a shared Google Doc - so that all team members can quickly review everyone's results and come to the meeting ready to discuss all the results and collaborate to integrate them.
One result of situation scans is a list of questions arising from thinking about the design brief. These questions are usually quite broad and their answers will provide your team with an overview of the situations for which you have to design an intervention. That is, at this point, you are only trying to understand the design problem as a whole.
Key areas on which to focus your research are described as a situation scan). You may, of course, find other research issues specific to your project that you should also investigate.
Also, make sure to not just present data but explain its relevance to your project. For instance, if you report on literacy rates, make sure to indicate clearly the impact that literacy may have on various aspects of your project. See the deliverables section of this page for details.
Once an initial product requirements specification has been created, most teams will find it necessary to conduct research. You can think of each requirement as a question that has to be answered to develop a good design. You probably will not know enough about the question to answer it directly, so you will need to conduct research to get the information you need to satisfy the requirement.
In real-world settings, this research may involve changing the membership of the team to ensure that the right kinds of experts are involved. In educational settings, however, this is rarely possible. Still, the Pareto Principle tells us that even students can discover most of the important information necessary to satisfy the requirements.
Obviously, we do not mean here questions about product structure, form, materials, etc. Instead, we mean questions regarding the nature of the constraints and performance metrics defined in the PRS.
Consider the example of designing a powered cordless screwdriver: What does “comfort” mean with respect to a powered cordless screwdriver? What characteristics of the product might be limited (constrained) in order to ensure “comfort”? How would comfort be measured (i.e. what performance metric(s) would we use?) In order to answer these questions, background research is usually recommended.
Every term occurring in your requirements must be framed with respect to your specific design problem. “Comfort,” in the example above, is defined with respect to the design of the screwdriver. Clearly, if we were designing a chair, or a space station, or a can opener, the term “comfort” would be defined differently.
This kind of research is particularly useful for associating values with constraints.
Assuming you have documented all your research in your design journal, you only need to include a carefully written summary of the research in your project report.
For the summary that goes in your project report, you need to:
You can write your summary in extended point form.