top of page


Yes, there is audio work that could be done at the pre-production phase which saves you weeks of actual production time!

scratch audio

Scratch audio gives people the idea of how this whole list of sounds will actually sound like. It's where we first bring concept to reality and get early stage feedback.


Feedback-based iteration is an essential phase of my workflow. It brings together the team, client and myself to work on getting as close to the ideal as possible.

Audio qa

It's all about making audio QA guides/

documentations for the QA team or audio QA plans for myself if there's no QA folks around.


It's always possible that a project would have another new phase happen in the future. So write-ups and docs for the future designer is essential.



find references and share with the team/client, also ask the designers/directors and client (if possible) to throw me some good refs.

tech research/

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 audio

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 drafts

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.

scratch audio


version control

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.

assets tracker

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.

feedback spreadsheet

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.



QA guides/docs

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. 

bottom of page