1 Hi. Dave Custer here again, lecturer in MIT’s Experimental Study Group and the Comparative Media Studies & Writing program. In this second 6.101 communication video, I’ll continue to share some thoughts on meeting the communication challenges that arise during the course of analog design projects. Once again, these thoughts are targeted to specific 6.101 deliverables, to design projects in general, and more broadly to the interrelationship between design and communication. I will have succeeded if you come away from this video with a sense of how the processes of analog design and its communication are intertwined and how common challenges in the design process are met by different communication genres.

2 In the last video, I suggested that authors with an exigency craft text for an intended audience to effect change or bring about a desired action. In this video, I’ll address the process and genre knowledge domains and show how the activities of analog designers guide the production of text. 3 To do this, I’ll start with an overview of the engineering design process. In a general sense, it proceeds in stages from conception, t o design, to build, to operate and test. In general, it moves from broad detail to specific detail—in 6.101 terms, from block diagrams to circuit topologies to component specs. Because if you start your design process by biasing a transistor, either you’re either wasting your time or you’ve actually already done the system level thinking in your head. The list elements at the top of the image make it look like the process is linear: first you conceive, then you design, then you build. And at the end, you’ll write the report, like sprinkling on a little salad dressing at the end—but this line is deceptive. If your process looks linear, either the project is too easy, you’re not doing a very good job, or you are under tremendous time pressure. As Gim noted in lecture last Thursday, the 6.101 deliverables are necessary but not

sufficient. You need to pick a problem that is—shall I say um “interesting”—it has to be more challenging than modeling a resistive voltage divider, which you can implement without much attention to the conception & design stages. Rather than linear, the design process shape is fractal, which has implications for intra-team communication. Beyond a colorful, curly icon for fractalness, what do I mean by fractal? 4 Here’s one way of looking at the fractal nature of design. On the right is the linear-looking process. (Sadly, the communication sprinkled in at the end here.) On the left is data from a study of student design process and outcome. In some probabilistic sense, the linear-looking process pieces do occur in order, but they occur repeatedly—presumably as finer levels of detail are addressed. Without proof, I’ll state that quality is attention to detail. And that when you design you climb Peko’s complexity mountain until you’re high enough to understand the landscape; then you come down to level at which your solution is as simple as possible but complex enough to be sure to work.

5 The implication of the fractal nature of design is that the designer or designers must alternate between opening up possible solution spaces, exploring the ramifications of the space, and closing the spaces that are not productive. I can represent this opening and closing as chain of less-than, equals, and greater-than signs. In one sense, engineering discussions often look like a linear chain of these elements. Sometimes it’s useful as discussion participant to recognize this opening and closing of possibilities. If you have high expectations of quality, you are motivated to linger in the ramification exploration; if you are motivated to keep your team on track, you may prefer to close explorations quickly and reduce the number of explorations. Your team needs both the high-quality expectation and to be kept on schedule; recognize this interaction as a potential source of heartburn. And don’t forget to respect the complexity mountain. Some thoughts about this fractal image. One of the hallmarks of a quality design is that every component and interconnection has been chosen for a reason. In some sense, this image of a design tree represents this reasoning,

demarcating the pedigree of every final node on the right. Recognizing and documenting choices as they are made can go a long way toward producing the content for proposal and report drafts. Did I suggest that quality is attention to detail? As a designer and team member, what needs to be in place to create the intricacy requisite to your quality demands? I encourage you to have this discussion with your teammates. 6 Here, I transition from intra-team to extra-team communication. A characteristic of the design process is a constellation of genres associated with the process. These genres are codified responses to typical situations that arise during the design. As shown in this figure, it looks like the engineering is above the dashed line and the communication is below; a neat dichotomy, but perhaps deceptive.

7 My metaphor for a more accurate and useful relationship between the design in its genre constellation is that of an emulsion. In the same way that cream and butter are the made of the same components—cream is an oil in water emulsion and butter is a water in oil. I claim that neither the communication nor the design exists independently. It’s true; there is a mathematically pathological case in which an individual can design a circuit without ever communicating to any audience; but this situation has never been observed...

8 A more useful pathological case occurs when an author creates text for their self. It’s a thing. If you as an individual are going to engage in the design process for over 5 hours, I recommend spending 5 to 20 minutes doodling up a proposal for the work—a document that will help make sense of your design at 3AM.

9 Yet another useful pathological case is to use the communication component of the design process to design text. If you want a publisher to publish your upcoming book, you’ll need to write up an abstract and a book proposal. At the start of the process of producing this video, I listed the rhetorical elements I consider when designing text. (More perhaps on this in a later video on this list and the rhetoric knowledge domain.)

10 Pathological cases aside, my take-away regarding process: go with the flow; base your communication work on the engineering process. Adhere to the design process that is codified in your community of practice. If you do, it will be hard to go wrong. Because your community of practice is structured for success. Conversely, if you find yourself outside of your customary communities of practice, tread cautiously and don’t ask for a flame thrower.

11 What does the going flow look like? My visual metaphor here is a series of historical maps of the planet mars that progress in detail. In some sense, the communication deliverables are maps of where you want to go and—as you progress—where you’ve been. As the design progresses and the detail increases, so too does the detail on the “maps.” I’ve already said a few words about the abstract in the previous video, so next in line in the design trajectory is the project proposal.

12 In general, proposals are formal requests for permission and/or resources to accomplish something interesting. They articulate what is to be accomplished, how it will be accomplished, and what is needed to do so. In order of appearance in the proposal text, some common structure elements found in proposals, but perhaps not in your 6.101 proposal are: The summary: The reader’s digest version of the information in the proposal proper. It exists because the vice-president of engineering doesn’t have time to read your proposal. Because the funding agency simplifies things by using the summaries to divide the proposals into good, bad, & ugly categories; the latter category may never see a human eye again… Use your understanding of your community of practice to make sure that the summary includes key pieces of information for the various sectors involved. For instance, if your design proposal is targeted at folks in your company, make sure that the vice-president of engineering, marketing,

and manufacturing can all find the elements they think are important in your summary. The introduction defines a problem. “Problem” is open to a range of interpretation; perhaps something that needs to be designed (common in engineering), perhaps something that needs to be discovered (common in the sciences). In general, there are many plausible structures for a proposal introduction. If you are looking for a common one, consider a movement from general context, to specific context, to general problem, to specific problem (include functional requirements here), to the challenges of the specific problem, to an overview of the solution space. Your 6.101 proposal introduction need not be this intricate. Perhaps it sounds like “This document proposes a technique based on the use of an analog phase-locked loop and an analog integrator system for processing laser Doppler velocimeter data to infer particle velocity. This method appears to be suitable for designing low-cost integrated LDV sensors.” Background sections of proposals explain what it is the reader needs to know to understand the proposal. In many engineering circumstances, the author can safety presume that the audience understands the engineering sufficiently to evaluate the efficacy of the proposed plan of action. In interdisciplinary engineering work, backgrounds can be more important because folks from different backgrounds may need to understand segments of other disciplines. A second common element to find in a background section is prior art. I find that prior art is usually part of two types of arguments. One is the hole-in-the-donut argument, which shows the range of existing products on the market and the hole in some price or performance space, a void that the proposed design will fill. Closely related is the 2nd, best of all worlds, argument: for example, where the proposed design costs as much as a used Ford Taurus, accelerates as fast as a Ferrari, seats as many little league players as a Dodge Pro-master passenger van, and hauls 50 hay bales… Both these types of arguments might well appear in the introduction too.

Perhaps authors put prior art in the background because nothing else seems to go there. Don’t follow a recipe unless it makes sense. The methods section of an engineering proposal can often be renamed the “design section.” Here, you lay out the map & and your plan to get somewhere interesting. Proposals don’t end. Sometimes there is a “conclusion” section, which sound suspiciously like a long version of the summary at the start. Many proposals end in pages of supplementary information: time lines, budgets, the CVs of PRs. 13 But your 6.101 proposal might well not conform to the generic proposal structure. It will suffice to state your project goal, outline the structure of the envisioned circuit, and the process that you plan to follow. What’s it got to do? How will it do it? How will you make it happen? Additionally, your 6.101 proposal might include a paragraph or two about the how the project benefits you, a value-added element that is rarely explicit in formal proposals. For 6.101, in the proposal and the design review/progress report presentation, hand-drawn circuit diagrams are acceptable and appropriate. Because in the early stages of design, the handwritten diagram signals the audience that the idea is not set in stone & thus promotes feedback. And further, if CADing up the circuit is tedious and time consuming, doing so for a circuit that will later be discarded is potentially a poor use of time. Balance hubris and humility; make challenges clear and the reasons you think these challenges are surmountable. Underpromise; overdeliver.

14 The objective of the 6.101 oral design review/progress report is to reassure “management” (course staff) that progress is being made and provide the presenters with feedback to move the project forward. The “map” of your design should be more detailed for this event—proportional to the time

and effort you’ve put in since the proposal. And you’ll want to focus the resulting discussion on what will best help you move forward. Once again, hand-drawn circuit diagrams are acceptable. 15 About the report: A report is the story of your design, told from the point of view of the design and contrivedly absent of the “you” part of your design. The shape of the story is similar to that of a murder mystery. It starts with a dead body—the problem, the puzzle, the paradox, the cool, interesting, valuable thing that might be. It moves on to the background—the usual suspects, how they connect to the corpse, what their motives are, how good their alibis are. Then comes the methods section, the details of how the crime is solved. Results, analysis, & conclusion is the big reveal meeting in which Sherlock Holmes identifies all the important pieces of evidence, fits them together coherently, and identifies the culprit beyond a shadow of a doubt. An important difference between the report and murder mystery genres is that the report reader MUST know from the very start who done it. The title and abstract should make the identity of murder clear; and this identity can be reinforced in the introduction. Another crazy difference is that in the report the detective (AKA author) rarely appears in the subject of sentences—because the report is about the circuit, not about the author. Which leads to an abundant use of the passive voice, as in “Q1’s emitter voltage must be carefully controlled to get low drift. ” (Bonus challenge: how could that sentence be cast in the active voice with saying “I carefully controlled Q1’s emitter voltage to get low drift.”) Omit hand-drawn circuit diagrams in your final 6.101 report. Why? Jim William’s The Zoo Circuit has only hand drawn schematics. Why? If things go well, your proposal becomes the draft text of your report. To which, add the results, analysis, and conclusion. Incorporating text and images from the proposal & design review, word for word, pixel for pixel without editing—is

appropriate. It is possible to plagiarize yourself, but including text and images from the proposal in the reports is perfectly acceptable and appropriate. Doing so is a sign that you’ve been going with the flow ever since you started the project. We’ll say more about the report in person when we meet later in the semester to work on drafts. And perhaps more in another video about the rhetorical knowledge domain. For the time being, I’ll conclude the report genre section with the observation that many of this year’s 6.101 reports will be centered on modeling. Some large number of examples you may try to use as model documents will be design centered, to which building, modeling, testing are subordinated. So be alert to subtle adjustments to your 6.101 report due to the primacy of the model in your work and the absence of build/test and the—perhaps—reduced element of design. 16 Don’t lose any sleep over this one. But it is an opportunity to widen the audience who might have interest in your work—or hiring you… Model based projects are potentially more difficult to show in the video medium because there is no “thing” to point the camera at.

17 Well, that’s it for this video. Operationally, now you understand the principles that connect the design process to communication of design, a framework that implies success at both the 6.101 communication tasks and those you’ll encounter beyond 6.101. As a final note, when you read The Zoo Circuit and Picowatt, 0.45-0.6 V Self-Biased Subthreshold CMOS Voltage Reference check out how the reports’ genre and structure plays out.

18