Tuesday, October 04, 2011

How would you process feedback on something you've written?

I'm writing a game called Left Coast, where you play science-fiction authors teetering on the brink of sanity. In July, I pulled together my notes and created a draft that I thought would be fine for others to play. Since then, I've received feedback from:

- Wayne, who's read it
- Simon, who's read it
- various commentators on Story Games
- Mike, who I playtested it with
- various commentators on the Forge
- Malcolm, Gregor and Per, who have playtested it without me

That's a lot of feedback (which has all been stored in my 'Left Coast - Next Draft' folder). Now I have to pull it all together and make some decisions about what it all means.

First, I'm reading through it all and looking for any feedback that almost everyone seems to be giving me. Usually I get overwhelmed by the thought of doing that, so I'm converting the feedback into a mind-map, so I can group similar comments and observations together.

It's already obvious, just from working through feedback from the first five people, that the game is still too complicated: I've layered on so many procedures, and 'mandatory elements' and 'things to keep in mind', that people are having to spend all their time trying to figure out how to make the game work (rather than finding out whether the game actually does work).

So I have two next steps: simplify as much of the procedures as I can, while digging deeper to see if there's anything fundamental that's lying underneath the feedback: stuff that's non-obvious but is actually the 'real' work that needs to be done.

What about you? How do you process all the information when you get lots of feedback about one of your projects?


Debbie Cowens said...

I haven't frequently had feedback from different people all at once, it tends to trickle in from different sources so I get to process it one person at a time.

Actually thinking about my writing course crit group I have had a few occassions of processing about 12 people's feedback at once and it was exhausting!

I tend to approach processing one person's feedback at time. I jotted it down in my notebook under the headings of the +ve (what people liked and why), -ve (things that caused problems or people didn't respond well to and why) and the 'interesting' (questions, suggestions, things that could be added, developed or twisted in some way)

I also then had a space for 'general' ideas underneath that came out of that feedback when other people would bounce off something that was mentioned in feedback or any ideas I had that were something triggered by something in feedback.

I also tended to underline bits of feedback that immediately struck a chord of truth with me so they would jump out when I went back later to look at my notes and actually start using the feedback in the rewrite.

Following the De Goldi maxim of not replying to feedback or 'defending' the work really got me to focus on taking all feedback in to process. I found I had developed a habit over the years of filtering out feedback I didn't like. Working out how to truly ultilise feedback is still a very steep learning curve for me :-)

Steve Hickey said...

I like that process, Debbie. When it's time to start thinking about the rewrite, how do you assess your lists and figure out what points to take on board (or not)? Do you make a plan of what you're going to do next?

The De Goldi maxim is really useful!

Debbie Cowens said...

I guess tend to arrange the feedback into the various bits for the rewrite - group all the feedback related to beginning or a particular scene or chapter etc. I also have a 'wishlist' on a post-it or piece of paper by the laptop of the general stuff I work to improve throughout (more dialogue/description, amp up tension/relationship, etc) to remind myself to what to tighten/strengthen/reduce while I'm going. Sometimes ways to fit in wishlist stuff appear suddenly when you're restructuring or reworking for anpother purpose other times they become a focus for another edit.

I don't doubt my way is a very efficient method but I tend to always work beginning right through to the end in order for rewrites and edits so I don't need to be particularly methodical. :-)