How We Build the Guides and Workshops That Crews Actually Use
A look at the written formats, working methods and rehearsal habits behind our technical guides and training sessions, and why each one is tested on a real crew before it goes out.
6 minutes to read
Start from the crew's real day
Every guide we write begins with a plain question: what does the person holding this document need to do in the next ten minutes? A camera operator rigging at six in the morning does not want a history of signal standards. They want to know which cable goes where, what the monitor should show when things are right, and what to try first when it does not. So before a word is drafted, I sit in on a load-in or a rehearsal and write down the actual questions people ask each other across the room.
Those questions become the skeleton of the guide. If three different people ask why a return feed is silent, that problem earns its own page, written in the order a tired person would check things. Background theory still has a place, but it sits at the back, clearly separated, so nobody has to wade through it mid-task. This habit of listening first has saved us from writing a good many handsome documents that no crew would ever open.
- Shadow a real load-in before drafting
- Collect the questions crews ask each other
- Order content by what is checked first
Short formats that survive a cold stage
Our written guides come in three working shapes. The first is a one-page quick card, laminated or printed on stiff paper, that lives in a flight case or taped beside a desk. The second is a step-by-step procedure of a few pages, used for setup and shutdown routines. The third is a longer reference note, read away from the venue, which explains the reasoning behind the settings.
We keep sentences short and put one action in each step. Numbers such as gain positions, cable lengths or channel assignments are written exactly as the crew will see them on the equipment, using the same labels printed on the panels. Where a venue's layout varies, we leave clearly marked blanks for the crew to fill in on the day rather than guessing, because a confident wrong value does more harm than an honest gap.
- Quick cards for the flight case
- Procedures for setup and shutdown
- Reference notes for reading at leisure
Diagrams drawn by hand first
Almost every signal flow diagram we publish started as a pencil sketch on a pad. Drawing by hand forces a slower pace, and you notice quickly when a path does not make sense, when a split has no destination, or when the monitoring chain quietly depends on a device nobody listed. Only once the sketch holds together do we redraw it cleanly.
We use a small, fixed set of symbols and keep it identical across every guide, so a crew member who has read one can read the next. Colour is used sparingly and always paired with a label, since printouts get photocopied in black and white and a venue's lighting can wash out a tint. A diagram should still be readable under a head torch, held at arm's length, with one hand free. That is the test we apply before anything leaves the office.
- Sketch on paper before any software
- One fixed symbol set across all guides
- Colour never carries meaning on its own
Workshops built around the equipment itself
Our workshops are short and hands-on. We would rather spend an hour with people patching a desk and finding their own mistakes than two hours talking through slides. Each session is organised around a specific job, such as setting up monitor mixes for a small stage or lining up a multi-camera shoot, and the equipment used is as close as possible to what the crew will meet on site.
We deliberately introduce small, realistic faults: a muted channel, a swapped pair, a feed that drops. Finding and fixing these in a calm room means the first time a crew meets the problem is not in front of an audience. Groups stay small enough that everyone gets a turn on the gear, and we finish each session by having participants explain the chain back to us in their own words.
- Sessions built around one specific job
- Realistic faults planted for practice
- Small groups so everyone handles the kit
Testing every draft on someone who was not there
The most valuable tool in our process is a person who has never seen the document. Before a guide is released, we hand it to a crew member who was not involved in writing it and ask them to follow it with the real equipment while we stay quiet. Where they hesitate, reread a line or reach for the wrong connector, the text is at fault, not the reader.
These trial runs are humbling. A sentence I thought was perfectly clear has sent testers hunting for a button that has a different name on their model of desk. We note each stumble, revise, and repeat with a second tester if the changes were large. It adds days to the schedule, but a guide that has survived a stranger is far more likely to survive a busy venue.
- Hand the draft to someone who was absent
- Stay silent and watch where they hesitate
- Repeat with a second tester after big changes
Keeping guides honest as kit changes
Equipment is updated, venues are refitted and habits drift, so a guide that was accurate last year can quietly become misleading. We date each document internally, note the equipment and software versions it was written against, and review it whenever a crew reports a mismatch between the page and the panel.
When something is retired, we remove it rather than leaving a stale page in circulation, since an outdated instruction that looks authoritative is worse than none. Crews are encouraged to mark up their printed copies, and those scribbled corrections are often the best source for the next revision. A guide is never really finished; it is simply the best version we have tested so far.
None of this is complicated, which is rather the point. Listen to the crew, write short, draw by hand, practise on the real equipment and test on a stranger. Each habit costs a little time and removes a lot of confusion on the day. If your team would find a guide or a workshop built this way useful, get in touch through the contact page and tell us what you are working with.
Ask for a quote
Write to us: hello@newsymph.net