I'm giving a short talk to the University of Washington iGEM interest group tonight based on my experience watching the competition from the beginning and as a judge for the last couple of years.

The judges are given a long list of criteria for the various medals and awards.  The list has grown longer and more involved -- if the trend holds next year I expect it to be even more complicated.  There are many more teams than judges, so each of us sees only a small fraction of the teams in person on the first day of the Jamboree.  The only way we can keep things fair (and keep the teams straight in our heads) is to follow the judging criteria very closely.  We have a checklist.

It is important to remember in what follows that my academic training is in experimental physics, and I spend most of my time today trying to build stuff out of DNA.  I don't have anything against elegant and cool models; I simply groove more on elegant and cool atoms.  I speak only for myself and not for any other of the judges or organizers.

Here is what I plan to say this evening:

1. You need to make easy for the judges to understand your objective and your design.
2. Web pages can be too cool.  A rough rule of thumb: the cooler the web page is, the harder it is to understand.  A cool web page may be full of information, but as a judge it is the baud rate I care about.
3. Fun is good.  Demonstrating actual learning is better.  Data trumps everything.
4. In my experience, the more equations in your model, the less likely you will produce experimental data.  I find complexity as distracting in my own work as I do when I have something like 15 minutes to figure out the theoretical details of an iGEM project.  Keep it simple!
5. Find a mentor to help tailor your story to your customers, namely the judges.  This past year the judges were a mixture of academics and industry types -- biologists, engineers, computer scientists, physicists; theorists, experimentalists, hackers.  All probably have PhDs in something or other, which means we are used to rapidly parsing stories that are packaged more like papers in Science and Nature than like facespace/mybook/twitterwikirama/whatever.  Those things may be the future of science for all I know, but your customers (the judges) don't play that game -- we are fogeys as far as you are concerned.  You have to market to us.
6. Follow the directions!  Follow the checklist.  Make sure your DNA is to spec (e.g. meets the Biobrick(TM) standards).  Make sure it is in the Registry.  Get everything in on time.  Sometimes the organizers and judges screw up this part -- the way to resolve complaints is with reason and your own checklist.  No whinging.
7. Here is a suggestion I made to the organizers after the last competition.  Even if they don't implement it, you should.  Everyone in the competition has completed some sort of laboratory course requiring basic experimental write-ups.  Make sure your web page has a basic lab write-up, no clicking or hunting required. You will do better if the judges don't have to spend even thirty seconds trying to figure out if you have actual data and where it might be hiding on your wiki, especially if other pages are better designed and easier to read.  If I recall from my student days, those write-ups go something like this, mostly in this order: "1. Here is what we wanted to do and why.  2. Here is what we did.  3. Model.  4. Data.  5. Conclusion."  Bonus: if it didn't work, why not?  iGEM and the Biobricks Foudation both need a failure archive.

Good luck next year!