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 journals¹⁾) 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 team²⁾. 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.

• Authority. It's easy to find information on the web. It can be, on the other hand, very difficult to find robust, accurate, and reliable information on the web. Be careful to check the reliability of any information you find on the web.
• Primary source. There is a lot of duplication on the web; the same information will appear formatted differently in different websites, all of it taken from some other source often without proper attribution. A primary source is the original one from which all others copied, with or without attribution. Try to find primary sources whenever possible.
  • Wikipedia deserves special mention here. Wikipedia is a wonderful free resource, but because of its editorial model - where anyone can change the content - it is possible that articles contain errors. While there is some evidence that Wikipedia has fewer errors than even the Encyclopaedia Brittanica, errors tend to be concentrated in certain articles, and it's not clear which articles those are.
  • In any case, Wikipedia is at best a collation of primary sources and is not itself a primary source. This means that Wikipedia may be a great place to start conducting research, but your research should really then proceed to the actual primary sources usually listed in the References section of a Wikipedia article.
• Incorrect ranking. Search engines like Google rank web pages according to algorithms that are not necessarily useful to designers. Sometimes, search results that are very interesting to you may not meet the search engine's criteria; those results will still appear, but not on the first page of search results. Take the time to look through several pages of hits (including skipping to the 30th page of search results, for instance) to look for results that might be very interesting to you.
• Irrelevant search hit descriptions. Sometimes a good hit will be described in text by the search engine in a way that doesn't communicate well to you. One way to lessen the odds that you will miss something useful is to search for images rather than just web pages. Given an interesting image, all the popular search engines will let you then follow the image link back to all pages in which that image occurs. Image searching is not a perfect technology yet, but it may produce very interesting results and should not be ignored.
• Suboptimal keywords. Sometimes, you can't search the web for something because you don't know what keywords to give the search engine. This is a catch-22: you can't find the information without knowing the right keywords, and you can't find the right keywords without knowing some information. It's still rather a bit of an art to search the web effecively and efficiently. Students are referred to the following web pages, that provide tutorial-like information on how to search the web with Google:
  • How to use search engines effectively: Google and beyond
  • Google Guide: making searching even easier (PDF)
• Too many cat pix. Google searches everything on the web, and you may end up with many hits that are just irrelevant. Google Scholar may help in this case. Scholar is a service that searches only academic literature and technical information including patents.

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.

• Canadian patents
• EU patents
• Japanese patents
• US patents

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 it³⁾. 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:

• Identify 4 or 5 typical residential neighbourhoods in the Montreal area.
• Identify 2 or 3 locations where you expect people will work.
• Use Google Maps to find routes from the residential neighbourhoods to the work locations; Google Maps will tell you how long the trip will take. On desktop, you can also tell Google by what time you need arrive, so you can force it to calculate time spend during rush hour.
• Average your results.
• Document your method, data, and analysis.

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:

1. each team member briefly reports on the results of their individual research efforts, and
2. the team works collaboratively to document all the research results.

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:

• integrate all the research of your team into one sensible whole;
• organize it so that it's easy to read and flows sensibly; and
• focus on specific facts and information that you need to for your specific design solution.

You can write your summary in extended point form.

• Exploratory methods describe further many of the methods described above for gathering and generating research information.
• Some may be interested in my notes on conducting academic research although they apply more to post-graduate research on design rather than the kind of research that is done during design.