Well, I had planned on releasing the full version, complete with LRS Worlds analysis, the beginning of next week, but I’ll go ahead and post this version (@9935E ).
I will mention that while my EDN is by no means a perfect or the best method of documentation, the judges at the tournaments where I’ve competed have seemed impressed by it, so I hope it will help to provide an example of how you could choose to record your design process.
Without further ado, here’s my EDN through 4/19/21, the version I submitted for judging at Worlds:
For anyone who doesn’t feel like scrolling through 230+ pages of notebook, here’s a few tips I would suggest:
- Follow the rubric. I would recommend using the exact wording from the rubric (such as design/game/robot challenge, decision matrix, solutions, etc.) where possible to make sure that a judge with any level of experience can easily find what he or she is looking for. Include all steps in the design process. Make sure to specify which teammates do what tasks and have everyone present sign and date each page. Remember to date any code, photos, CAD, etc. that you add in as well.
- Use lots of labeled photos, sketches, etc. Judges don’t have long to look at your EDN. They won’t have time to read every word, and some sort of visual aid is almost always easier to understand anyway.
- Include goals. It’s best to have specific goals so you can objectively determine if that goal has been achieved. “Score at least 120 points in driver skills” is much better than “Get a good score”.
- Getting awards is not the only reason to keep a detailed EDN! It’s very useful to be able to look back at previous designs and recall what worked and what didn’t, and what the problems were. Also, I’ve found that in explaining what I’m trying and why, it actually helps me understand what I’m doing more fully.
I hope this will be a beneficial resource for any teams out there looking to improve, and I’d be happy to answer any questions you might have!