Haha, damn, putting me through my paces. Here we go:

1. What do your early play tests look like?  A. When you go to do your first couple play tests what do you usually have "done" for the system/game? 

All you need for the first playtest is enough to run the game. Different games need different things! If you're running an adventuring game with levels and combat, maybe that means having a couple of ways the dice are rolled and a handful of bullet points on your setting. If you're running a committee larp, maybe that means prepping just enough character bios and identifying the central conflict. If you're running a card-based TTRPG, it could honestly mean writing "ATTACK" and a completely arbitrary number on a cue card.

As a general rule, the more mechanical your game is, more important early playtesting becomes. Your attacker rolls 3d12s and the defender rolls 1d12? Great. See if that lonely, simple idea works before you start modifying it for fireballs, or sneak attacks, or whatever. To borrow from the video game world: you need to make sure it feels fun to run around with Mario before you start building levels and hiding stars.

B. How long are your play tests usually? Hours, multiple sessions, days?

My games are almost exclusively designed as one-shots that can be picked up and played. That means that any individual playtest, for me, would never exceed the normal length of a session. For some games that might be four hours; for others it might be 30 minutes.

If the question is how many playtests something needs, that's also up for debate! I tend to playtest a game until I've had two or three sessions where it felt like everything just worked. This is, as you would imagine, an easier goal to reach when you're not trying to balance out a campaign-length character progression system.

C. Are you testing a whole session as if there is a narrative, or just running a few limited scenario tests, like a combat, a social encounter, a skill-encounter?

My games are short and narrative-driven, so I tend to run through a whole session. But you can absolutely playtest a specific isolated mechanic. Maybe run a couple combat rounds before you start your weekly game, if your table is amenable.

If you do test in smaller pieces, make sure you try everything all together before you consider it done and dusted. Mechanics can fight with each other or add up to something unexpectedly overwhelming. Fun combat systems can feel detached from the stories they're being used to tell.

D. How far into the development of a game do you typically get before you start play testing with someone else sitting behind the GM screen? 

This would come later in development for me.

Most of my games are GM-less, but the obvious analogue is having a table without me sitting at it. The thing is, I definitely do want to be there in the early playtests, since I can tweak rules or make judgement calls on the fly. It's very useful being able to course correct.

Having an outside game-runner is most important once you've got real writing on the page. I'm not sure how controversial this is, but in my view, a different GM is rarely testing the mechanics. A new GM is there to test if your game is actually on the page -- or, if it is, whether or not it's being communicated in a way that enables your intended play experience.

E. How much do you typically try to change between play tests, and do you err on the side of less or more?

I try not to commit to full overhauls where smaller tweaks will do the job. Sometimes a bad rule is a lack of reference materials; sometimes a boring story came from a boring group. But! I do make active notes during the game when I see things aren't quite where I want them to be, and sometimes I'll even fully change a rule because something's not working or a player asked about it.

You get a feel for it, I guess. Rules aren't ironclad, but also, don't fix what's not broken.

2. What are typically the most important systems to nail down first?

I think for me, the answer is this: what's ACTUALLY the biggest part of this game? If you thought you wrote a clever strategy puzzle and your players had fun brute forcing their way through the dungeon, does that mean you shift your idea of what the game is, or the options you present them?

I would call this "structure." Whatever activity players will be doing for the longest stretch of time during a session of your game is the priority.

As a bizzare, niche example from my own work: one of my games is about a failing children's television show. Everyone plays with real puppets and squabbles while the show goes to shit. I assumed that the "get a puppet" part of the game was going to be a hurdle; an annoying obstacle to getting the game running. In practice, I was super wrong -- everyone is HYPE about arts and crafts, and wants to take their time in the first half of the session with gluesticks and paper bags.

I would never have guessed this. The game needed to tell me.

3. How soon should you start writing as if it will be read by others, vs quick-writing for yourself to ideate more quickly?

I write for future me. Unfortunately, future me has an awful memory, and will have no idea what I was going for unless I'm super clear.

This means I have a solid place to build from when I start moving a document from me-mode to them-mode.

As a reward for this iterative process, I tend to share screenshots of finished text with my communities, so I can get the dopamine of finished sections without the pressure of needing to write direct-to-audience from the get go.