Telling Your Story

Learn about how to tell your story and improve your project's clarity here!

Introduction

The goal of this information is to help teams understand the importance of scientific communication in terms of explaining their work to a larger audience and documentation as it pertains to the iGEM competition for medals and special prizes for the 2015 season. Telling your story in a clear and concise way is challenging, but well worth the effort in the end.

Remember, your wiki is the public-facing representation of your project! The general public will see it, so your story overview should be clear to non-scientists and you should be able to guide them through the different parts of your project at a high level through your wiki pages.

This is also how the team's judges will first learn about your project, so you should make sure your story, design, and results are clear to someone who has never seen your work before. You might want to ask other Professors and graduate students in your department or college to read the wiki as you build it, to make sure other scientific experts can understand your project from just your wiki alone.

The majority of this advice is centered on the team wiki with a few suggestions for your poster and oral presentations, but these suggestions should also tell you the type of information the team might want to consider including in their presentations.


General Wiki Tips

Everyone involved with your iGEM team should make sure to read through:


Making sure that you follow these requirements should not be the responsibility of only a few team members, but rather a shared responsibility throughout the team, including the advisors and mentors.

Remember, your team wiki is a public page and should show of all of your hard work! Everyone on the team should take pride in the wiki and we recommend that everyone on your team help contribute some material for it.

Avoid using copyrighted material, especially images! Use original content as much as possible to avoid running into copyright problems.

Please take note of the Perspectives from an iGEM veteran that Ana from iGEM HQ wrote as a former team member on an iGEM team. Ana's suggestions are focused on the team members building and maintaining the wiki, and we recommend all teams follow her advice!

Another member of the iGEM HQ team, Traci, had a few suggestions to add. Traci was the team mentor and instructor for the 2011-2014 competitions, so her perspective is from running an iGEM team.

1. Assign weekly tasks for the wiki during lab meetings

As we all know, team mentors and advisors are invested in their team's project. Remember, a large part of an iGEM project is the team wiki! As a team instructor, I helped students decide on weekly tasks and assignments for the content for their wiki during our regular lab meetings. I often told students to work on the content while they waited for reactions to finish or gels to run in the lab, which seemed to work nicely.

2. Instructors and mentors should be proofreaders for the wiki

As your team creates content and posts it on their wikis, you should make sure to take some time each week to read through the wiki and ensure the content has been proofread for typos, clarity, and accuracy.

3. Assign specific pages to specific people

Ideally, each team member will be creating content for the team wiki with a smaller group responsible for editing the wiki and posting the content to the page. To avoid confusion and possible deletion of content, you should make sure the editing of each page is specifically assigned to one person.

4. Updates done on the Wiki Freeze Day should be minor edits

Every team around the world will be editing and updating their wikis on September 18th. I strongly urge you to only make minor edits and update figures on Wiki Freeze Day. I recommend that the vast majority of your content should be on the wiki a full week before the Wiki Freeze so you have plenty of time to read through everything and make sure you haven't missed any critical item. This will greatly reduce the stress on your team members!


Best of luck!
– Traci
If you have any questions or comments, please contact me: traci AT igem DOT org


Project Overview

Having a brief, well-written project overview is a huge help for anyone interested in reading about your project. The overview should only be a few paragraphs in length and often teams will include a cartoon or diagram to accompany their overview. Ideally, the overview should be understood by scientists and non-scientists alike. We also recommend that you have pages with detailed descriptions for each part of your project, complete with references and links to your results.


Recommended Components for a Clear Overview Page

  • State the Problem: Very briefly, state the problem you are attempting to solve in non-technical terms.
  • State the Solution: Describe how you plan to approach and solve this problem at a high level.
  • List the Goals: If appropriate, briefly give your project goals that will help you achieve your solution. Try to avoid getting into a lot of details.
  • Link to Details: Add links that will take people to the more detailed description of your project, the problem, and your solution. These are sometimes included in the text, shown as drop down menu options, or are links within images.

    • Examples of Well-Written Overview Pages


    Overview illustration from the 2013 SYSU China team

    Below are a handful of well done project overviews. These examples show different ways that the project overview can be done on the team wikis. These are all concise, well-written project overviews with links to more detail.

  • 2014 Valencia Biocampus
  • 2014 MIT
  • 2013 SYSU China
  • 2013 Paris Bettencourt
  • 2012 Purdue
  • 2012 Westminster

    • Project Design

    Project design pages should be where you delve into more details about the genetic devices, software, hardware, and anything else you intend to work on and build over the course of your project. You should highlight design elements that are inspired by previous work (and cite the work!) and discuss if you are creating a new part or using a part in a new way. Often, teams will include a diagram of their genetic circuit layout, the GUI design for their software interface, or a schematic of the hardware they're creating, among any other design elements that went into the project. The list of components below focuses more on wet lab teams.


    Recommended Components for a Clear Design Page

  • Show Your Part Design: You should use graphics and text to clearly describe your Part design and where the inspiration for that part and/or design came from, if it's from any sort of previous work (iGEM project, research article, etc.).
  • Cite Previous Work: If you are inspired by previous work of any kind, make sure you cite the work properly. Likewise, if you show images from research articles, make sure they are attributed properly.
  • Graphics Should be Clear: When using any graphics to show your design, make sure the colors and font can be easily seen by everyone. Avoid excessive use of reds and greens in your graphics. Loopy or overly creative fonts can also make it difficult to understand an informational graphic.
  • Sections for Different Elements: If your project has multiple design elements (such as an input biosensor, an output device, etc.), you should keep the design for each of those elements clearly separated, either by having multiple design pages or having clearly defined sections within one page.

    • Examples of Well Done Design Pages


    Software design example from the 2012 Wellesley HCI team

    Below are a handful of well done project design pages. These range from wet lab teams to hardware projects to software designs. These highlight the vast range of ideas and projects undertaken by iGEM teams and should highlight different ways that designs can be conveyed to the general public and to the iGEM judges.

  • 2014 Aachen
  • 2014 UC Davis
  • 2013 SYSU China
  • 2013 Tokyo Tech
  • 2013 Berkeley
  • 2012 Wellesley HCI

    • Project Results


    Make sure you post your results on you wiki!     It may sound like an obvious statement, but sometimes teams can forget to clearly state how their experiments ended and discuss what they concluded from that work. It's not enough to post your experimental details in your online wiki notebook - you need to have a section devoted to the results of your work on your wiki.

    We strongly recommend that the results of your work should be posted on your wiki using your assigned standard Results page (https://2015.igem.org/Team:Example/Results). You will want to include a link to this page in your wiki navigation so it's easy to find for someone who will be seeing your wiki for the first time. Finding the team's results can sometimes be challenging when there isn't an obvious button or dropdown menu item on your wiki that is labeled "Results". You want your judges to find the results of your hard work, so make sure it's easy to find the page!


    Recommended Components for a Clear Results Page

  • Restate the Goal: Remind the reader what the particular goal is that you're working towards in a brief phrase or sentence.
  • Summarize the Results: Quickly list or summarize your results for that goal.
  • Show Experimental Data: You will need to display the data that gave you this result. This should include some information about the experiment run or provide a link for full details about the experiment.
  • Show Your Controls: Your experiments should ideally have both positive and negative controls. You need to explain the design and purpose of your controls, and you need to show the data from them. It's not enough to say you used them - if there isn't any data, then your audience doesn't know what you included in your experiments!
  • Links to More Detail: Provide links that can take your reader to a page with more detail on those results, which would most likely include information on how the data was obtained and how you interpreted the results.


    • Examples of Well-Written Results Pages


    Results example from the 2013 Paris Bettencourt team

    Take a look at the example Results pages below. These examples represent just a handful of teams who implemented a clear, concise Results page. It can be a difficult task and will take careful planning and hard work to execute it well. These teams all have some variation of the components given above in their pages.

  • 2014 Imperial
  • 2014 LMU Munich
  • 2014 SDU Denmark
  • 2013 TU Munich
  • 2013 Paris Bettencourt
  • 2012 Cornell

    • Medal Criteria Checklist

    Another page teams may consider having on their wikis is a Medal Criteria Checklist page. This is not one of the new standard pages, but we recommend teams create one and have it easily visible for the judges to find.


    Recommended Components for a Checklist

  • List the Requirements: For each medal that you are trying to achieve, re-list the requirements for that medal. It will help you remember the checklist as well as help people read through the list.
  • Add Checkmarks to Completed Tasks: For each item you believe you have completed, mark it in some way. Many teams include a check mark or something similar a they go down the list of requirements.
  • Link to the Relevant Pages: Within the text of each list item, if you have a page you can link out to, then include it. Some of them will not have links (ex: Register a team for iGEM in the Bronze medal requirements). For your Bronze, Silver, and/or Gold medal part requirements, you should include a link to the direct Registry page for your part.
  • Document Your Registry Pages: One of the major criteria for convincing the judges that you tested your part and showed that it is functional is the data that should be posted on the part's Registry page. It is not enough to just post it on your wiki - this data must be included on your Registry pages! Remember: the purpose of the Registry is to provide as much documentation as possible so that other researchers may use your Parts.

    • Examples of Medal Criteria Pages


    Gold medal checklist from the 2014 BostonU team

    Below are a handful of ways that teams have highlighted their work towards the medal requirements. The chosen teams were all awarded gold medals during the competition and were chosen because they showed a completed checklist of items for their year.

  • 2014 BostonU
  • 2014 Aachen
  • 2013 ETH Zurich
  • 2013 Manchester
  • 2012 UNITN Trento
  • 2012 UC Chile

    • Presentation

    Below is some general advice for teams to consider as they start preparing their oral presentations. These are just some ideas that we hope you think about, particularly if you've never presented a talk at a conference before.

    Make sure to check out the Giant Jamboree Presentation Guidelines for information about timing and judging!


  • Practice, Practice, Practice: You should practice your presentation multiple times before you arrive at the Giant Jamboree. Ideally, you should practice in front of people who are not involved with the iGEM team or project. You'll get the most honest feedback about clarity and a chance to answer real questions if you can give a departmental seminar or similar before arriving in Boston. Avoid editing your slides at the last minute / at the Jamboree, as that will only cause more stress!

  • Come Prepared for Questions: Make sure to go through the presentation with your instructors and advisors (and others, if possible) with the goal of coming up with "predictable" questions. Prepare a few back-up slides that can address those questions easily. Only the team can answer questions, so make sure everyone is well versed with the methods and results. If possible, elect 1-2 team members to handle questions about specific areas of the project. For example, if one team member focused a lot on the cloning a nitrogen sensor while another worked on running characterization experiments, you should make sure those people answer those types of questions.

  • Remain Calm During Questions: When the judges ask you questions, try to stay calm. Many students will become defensive and sometimes aggressive in their answers since they may interpret the question as an attack on their project. Remember, it's the judges' job to ask you detailed questions about your work - they've been reading your wiki for a week, are well versed in your project already, and are excited to talk to you. If you don't understand the question they asked, don't be afraid to ask them to repeat it or ask it in another way. It's also perfectly fine to admit you don't know the answer!

    • Poster

    Below is some general advice for teams to consider as they start preparing their poster presentations. This does not mean other methods of discussing your poster are discouraged; but rather, these are just some ideas that we hope you think about, particularly if you've never presented a poster at a conference before.

    Make sure to check out the Giant Jamboree Poster Guidelines as well for more information!


  • Prepare Short, Medium, and Long Poster Presentations: Since judges and other attendees are often trying to chat with many teams during the poster sessions, you should practice three different length talks: 1 min, 3 min, and 5 min. It's very easy to get lost in the details of your project and talk with a judge or other attendee for 10 minutes (or longer!), but oftentimes for judges they don't have a lot of time to spare. Try to keep this in mind when they come to your poster.

  • Let People Read Your Poster: When someone new comes up to the poster, ask them if they would like a minute or two to read the poster before you start presenting. Sometimes people are stepping closer to read the poster and other times they have already looked at it during one of the breaks and have come back to talk to you. It's polite to ask if they need some time to look things over before you being discussing your work.

  • Use Large Font Sizes: You should be able to read the poster easily from a few feet away. If you need to be right in front of it to clearly read the text, the font is probably too small. A good way to check font size is this: print a copy of your poster and have it "fit to page" on a standard A4 or 8.5"x11" page, and if you can read the font clearly when you hold it out with your elbows locked, then it will probably be large enough on the poster.