A Guide to Writing a Design Context Review in Bioengineering Design

These materials were developed for BIOE 451-452 by Deborah Ausman, Maria Oden and the Cain Project in Engineering and Professsional Communication


 

This guide describes a process to help your team collect, organize, and structure background information on your project into a focused design context review. The steps are as follows:

  • Educate yourself about your project
  • Analyze your aims
  • Determine your problem statement
  • Develop a design context map
  • Outline and write the design context review document

You will produce three documents during this process:

  • A Need to Know list generated using the Accelerator for Analyzing Design Aims (as part of step 2)
  • A design context map (as part of step 4)
  • The written design context review (3,000 words maximum, created as part of step 5)

Seven accelerators (examples, tips, and interactive forms) speed this process:

    1. Examine how another team educated itself
    2. Analyze your team’s aims to generate a “Need to Know” List
    3. Find the parts of problem statements
    4. Watch a context map being constructed
    5. Learn to recognize a problem-focused outline
    6. See how to lead with assertions
    7. View poor and high quality versions of an argument

These accelerated techniques will assist you with this assignment. They will also help you organize complex information in other situations. 

Step 1: Educating Yourself

Projects in Bioengineering Design require your team to become experts on complex technical, physiological, and business issues. To fully understand your team’s mission and begin to articulate a specific problem that will drive your project, your team will need to review literature in your project area.

Your self-education will be more extensive than the information you will ultimately provide to your readers. That’s because your readers are interested only in the problem you plan to address and the reasons it should be addressed. To make your case, you will need to arm yourself with a broad range of information in your project area, including

  • The physiology of the disease area or characteristics of the health application or process with which your project is associated
  • Descriptions of current technologies that are similar to your planned design (or information on current treatment methods or procedures used if no similar or competing designs are in place)
  • Theories or technical approaches/methodologies that apply to the implementation or construction of your design
  • Potential professionals who will use your design (their preferences, how they will use it, price/construction considerations, etc.)
  • Concerns and potential outcomes for patient populations or secondary beneficiaries (other than users) of your design
  • Business, regulatory, environmental, or cultural issues that affect how your design will be used and implemented

Examine information that another team gathered to educate itself by consulting Design Context Review Accelerator #1.

Step 2: Analyzing Your Aims

The product of the first step in the design context review—references, notes, and amassed background information on your project—can be intimidating. An inefficient approach to the process is to dive immediately into writing. Drafts begun at this stage often focus too much on the background, telling readers everything you found out about your project. We have developed an accelerator to help your team explore the characteristics of your design opportunity. You will generate a Need to Know List that suggests issues you need to explain, given your aims. It also helps you pinpoint information you may not have collected or issues you haven’t thought to explore.

Generate your Need to Know List by consulting Design Context Review Accelerator #2. NOTE: You must be ON Rice campus or on via VPN for this Accelerator to work.

Step 3: Determining the Problem Statement

The aims analysis performed in Step 2 provided your team with a list of evidence needed to explain your aims. This, in turn, offers a perspective on your collected background information. Your aims provide goals, but to effectively drive your project effectively, the goals must be specified in a motivating need or problem.. This problem often lies in the evidence you collected—in the “why” questions that arise when you explain the aim. If your aim is to modify or build on an existing design, the question is, “Why?” What about the existing design needs to be improved? Why not build an entirely new design? Digging into these questions will help you determine your team’s specific problem statement.

Problem statements define a problem and describe general points around which quantifiable design criteria can be established. They usually consist of :

  • A statement of what is desired
  • A statement of the contrary condition or problem with the status quo
  • A statement of characteristics envisioned in potential solutions

The problem statement provides an organizing structure for your design context review. Knowing the problem statement at this stage in your work will enable you to identify appropriate background information to include in the design context review. Note, however, that in the written design context review, you will place the problem statement at the end.  Introductions of research articles and design reports typically move from what is known about the topic to what is not known or in question, and end with the problem statement. While your design context review will cover substantially more information than the typical introduction, following this structure will help you when you ultimately condense your review into the introduction of your final design report in Phase 3.

Find the parts of problem statements by consulting Design Context Review Accelerator #3.

 

Step 4: Developing a Design Context Map

The design context map is based on what psychologists call mind maps or concept maps. Unlike outlines, which impose a linear structure on information, concept maps are loosely constructed. Jot ideas down as they occur to you and then connect and sort the ideas using circles, arrows, crossouts, and other mechanisms. The connections made can help you determine a logical progression for your argument, decide which information to discuss in what order, and cut or condense repetitive or unnecessary information. The connections you discover can even suggest new ideas about your design strategy.

One way to unlock creativity on your team is for each team member to develop his/her own context map from the team’s problem statement and collected research. Then compare the maps. Do all of you consider the same information essential to supporting the problem statement? Do you connect the information in the same way? Differences of opinion may reveal unclear concepts or help you develop better ways of discussing your topic.

Hand in one context map that represents your team’s consensus. It will be evaluated and handed back to you with comments. You may need to change your problem statement or collect additional information before transferring your map to outline form.

Get instructions on creating a design context map by consulting Design Context Review Accelerator #4.

Step 5: Preparing the Design Context Review

The process of researching your problem, determining your aims, developing a problem statement, and mapping your research will leave your team well prepared to develop a problem-focused design context review. You only have a maximum of 3,000 words to make your case, so you will need to choose the information to report carefully. A well written design context review will help your audience understand the motivation for your work. It will also help your team identify design criteria for successful solutions.

You will begin by preparing an outline from your design context review by transferring connections and ordering that you explored in the design context map to a traditional outline format. The process you have followed should result in a problem-focused outline. Design Context Review Accelerator #1 contains more information on recognizing and creating this type of outline.

Once you have settled on your outline, you can begin drafting the design context review. Your team contract should outline a process for collaboratively writing the review. Follow this process in developing your draft. As this is the first major document you will produce in this course, you should evaluate how the process works and make adjustments if you see areas that are inefficient or need improvement. Design Context Review Accelerators #2 and #3 provide specific advice on how to structure scientific writing with assertions and evidence. Consider this advice to streamline your writing.

Learn to recognize a problem-focused outline by consulting Design Context Review Accelerator #5.

See how to lead with assertions by consulting Design Context Review Accelerator #6.

View poor and high quality versions of an argument by consulting Design Context Review Accelerator #7.