Solution design at very small scale

Having a wee gap between client work, I have spent the last couple of weeks engaging in some of my hobbies.  These include watching epic Chinese martial arts dramas, painting toy soldiers and listening to terrible European power metal songs about tank battles and Vikings.  Actually that’s not true, metal songs about Vikings are awesome.  

So having shattered all street credibility for myself I thought I would try desperately to bring this back to something vaguely work-related.  It happens my good mate Gary and I have over the last few weeks taken to designing and writing an entirely new wargame to use our miniatures with.  For large Napoleonic battles with 6mm figures to be precise. 

I realised early on that I was applying standard solution design techniques to the process.  The way we work is Gary comes round to my place and we start working through what we want the game to be with the little lead chaps on the table.  But, and this is no word of a lie, we also have the Post-it notes out and Sharpie pens.  It’s like a workshop but with added nerdiness. 

One of the keys has been to stay at as high a level as we can for as long as we can.  It was very tempting to go straight to rules, etc, but we stayed disciplined and made sure we really agreed on the high level principles and outcomes we wanted.  We want to be able to play the big battles of the era, we wanted simple rules and not a special rule for each specific nation.  But we wanted the different nations to be different in how they organised themselves.  This was a big thing for Gary, who is a keen student of this sort of thing. 

So in Business Analysis speak we set out our high level objectives and outcomes before we touched on solution. 

Then we made up some simple rules, which we wrote on Post-its and tested between us.  Initially a brigade of French soldiers attacked a brigade of Austrians.  We tried it three times, mainly as Gary is the worst roller of dice in all of the universe.  Even allowing for Gary’s dice rolling it instantly did not feel quite right so we changed the rules and wrote new ones on a new Post-it.  More dice rolling and they felt much better.  Then we added artillery.

This is breaking up requirements and doing testing early. 

Something else that we seem to have got good at early is letting the other chap have an idea and letting them prove it to you even if you don’t think it will work.  And conversely letting go of an idea when a test shows it’s not doing what you wanted.  Again, we based this on testing or referring back to the agreed principles at the start.  This really helped. 

Having an open mind and having some keys to refer back to are vital.

The last observation is that we understand what each of us is good at.  Gary is far more knowledgeable than me about the detail of different nation’s armies of the period.  I have 20+ years of doing this sort of workshop stuff so I lead on facilitation.  Then we collaborate on the key decisions. 

Understanding each other’s roles and respecting expertise is very important in solution design.

At this point we are a week or so away from having our first full playtest against each other.  Then we plan to bring in a couple of other friends for a full blown user test.  I fully expect that the first time that we get other players involved we will realise we still need to make lots more changes. 

But now I am back doing the work that pays for all these little lead men.  Pretty soon it will be workshops and solution design on pensions or data strategy.  But the principles remain the same.  

I’m not sure my next Pensions Dashboard meeting will have The Number of the Beast by Iron Maiden playing though.  Which is a shame. 

Leave a comment