Communicating a Technical Topic

Last week I learned a very crucial lesson: know your audience. While I have given several neuroscience presentations during my college career, until last week I had never given one to an audience of students and faculty without background in the field. Speaking to a group of historians, statisticians, political scientists and writers, I learned firsthand the challenges involved in communicating highly technical neuroscience concepts to non-neuroscientists.

Going into this presentation, I was conscious of the complexity of my project. Most of the words I had to say were at least four syllables long. I had several slides with diagrams of overlapping neural pathways – some represented with blue lines, others with red, some with solid lines, others with dashed ones. It was a lot for me to explain, so I figured that it would be hard for someone unfamiliar with the concepts to follow. However, I underestimated just how challenging it would be for them to understand, and although I worked with my advisors to make the presentation more clear, it was still far too technical.

Looking back at this presentation and the feedback I received afterward, I have come to the conclusion that there were three main mistakes I made in communicating my thesis to this particular audience. My first mistake was failing to do a quick review of basic neuroscience principles at the beginning of the talk. Such a review would have contextualized my project and helped to catch my audience up to a level at which they could better understand my work. My rationale for not including this introduction was time; I wanted to maximize the time I spent talking about topics directly pertaining to my project. Therefore, I was hesitant to waste precious time on more foundational ideas. In reality, however, the time I saved by excluding this introduction was then wasted anyway by adding in other superfluous information elsewhere – my second mistake. I went on tangents thinking that extra information would help complete the picture of the issue I was addressing with my project. Because these tangents were also highly technical, however, all they did was confuse my audience further by distracting them from the more pertinent information. The final mistake I made was in the language I used. While I would argue that there were times when I could not get around using technical language to describe my project (e.g. the first time I introduced a key concept), I certainly did not need to rely on this technical language to the extent that I did. For example, rather than saying “temporal hemifield advantage” ten different times, I could have just said it once to define it and then subsequently referred to it as “a faster response to temporal stimuli.” Another, more simple alternative could have also been “the effect we are looking for.” In hindsight, using less technical language would have kept my audience more engaged with the result that they would have gotten more out of the talk overall.

If I had not made these three mistakes, my audience may have been able to follow my talk more easily. However, I do not regret making these mistakes. Although my audience may not have learned as much from this talk as I initially hoped, it was certainly a learning experience for me. Going forward, I know now that I will be more conscientious of the expertise of the people I am speaking to; I will choose to include specific information and language that will meet my audience’s need, with the hope of keeping them engaged throughout the whole lecture regardless of how technical the subject matter actually is.

Learn more about my project here.