find references and share with the team/client, also ask the designers/directors and client (if possible) to throw me some good refs.
conversations with tech folks
research middleware or existing frameworks made for projects with similar audio needs to save programmers some time.
I love spreadsheets! Making a SFX list or music list is very helpful when we reach the final stage of the pre-production. As we get maybe the first draft of design docs, I always start with making list of sounds needed and trying to have the designer review the list and leave notes.
scratch VO lines
scratch VO lines can be done in a very short time and sometimes it helps the client understand the script when we don't have a lot art assets in game and the client doesn't have time to review the long long script.
scratch SFX /
conversations with artists
scratch SFX, especially scratch SFX for animations, can help communicate with the artists/animators what sounds you're making for the arts they made, and with iterations for both art and sound we'll finally get highly matched.
music or background music is always tricky, there's a lot to talk about but, here I just want to say that the first few drafts of music are super important because with iterations on these drafts we'll finally get a right direction that the client/designer want the music to go with.
I used to be a programmer and I love version control a lot. It's always safe to version control my stuff especially during the iterations, cuz we never know if the client/team would suddenly decide to roll back to an earlier version.
I'm a huge fan of assets tracker, cuz it really really makes life easer. The tracker helps track my work and I'm also able to see others' progress like the implementation status or animation status so that I could have an idea what I will probably work on next.
I love spreadsheet and I'll create my own audio feedback sheet for each round if there's no higher level feedback list. Even there is one, I'll make another one for audio with status and notes column to help myself organize the feedback.
Making audio QA guides/documents for the QA team is like making a documentation of how the audio was designed how they're supposed to sound like. It saves QA time and helps avoid misunderstandings like they reported an audio bug saying this was weird but it was actually by design and wasn't even a bug.
QA it myself
Most times I was the only sound designer in the team and the QA people are usually not audio people. So for some very specific audio quality testing, I usually do it myself in addition to the QA process, cuz there're issues that can only be found by myself.
Basic info about this project (audio part), also tips and something that the future designer should know. The intention of the write-ups is to help the future audio person get to know this project sooner.
Clear and structural docs for future designer to look up. Should include all the info about the audio system, as well as where the project archives are located. But the future designer can choose to ignore it.