Another 12 months, another post. This time around it is the third year I’ve created the Melbourne to Warrnambool Cycling Classic Technical Guide. This year the time required was a little less which given some formatting changes and a deign change to look a little like the Herald Sun Tour guide (another NRS race so important from a branding stand point), so not bad. Having designed or redesigned most of the artwork last year also cut down on the time needed this year.
Improvements on last years guide include:
- more table consistency (the sprint and KOMs were left as is but could be improved upon)
- text size consistency – previous years had small text for tables. This time the only small text present is in the mocka.
- standard notation used – better than the provided KM, KMS, 09:00am, 6.04.56 for times etc.
As for last year, Kanboard was used to allocate and track tasks.
Throughout this project, I stayed in touch with the client via email and phone.
Again, the most time-consuming part was formatting the race mocka. I’ve improved on the process so it is far quicker which is a nice gain.
Below you can see the non fancy table formatting that was seen in some locations in 2019. This time around, all table look like those in the second image.
This year a spreadsheet mocka was provided for the marshals along with a pdf of the guide for posting online and printing out.
What to improve
Various iterations of the guide resulted in incorrectly linked documents. An Illustrator file was sourcing unrelated images rather that the ones it should have been and the mocka seemed to lose changes now and then (this was curious as I inserted the spreadsheet and linked to it so changes should have been automatic). I think what happened here was a result of using the 2019 and 2020 brief directories and a few different InDesign files. This meant I spent unbilled time fixing things.
So, next time, follow my own procedures and work out of the one directory using the files there. This is a nice example of why not following procedures and winging it is not the best idea. I should also introduce a procedure for proof reading using a comparison between previous and current documents before releasing them. That will cut down on such errors.