Observation allows one to be objective and offer a fresh and if need be, positive disruption.
We have our own unique ways of running workshops and facilitating ideas as an inception team and I as an inception (early business envisioning and feasibility) lead. BUT we must humble ourselves it we are to remain open and suggestive to ideas. A leader and a strong team need to also listen. We should not be afraid to embrace a challenge, listen to ‘outsider’ feedback and incorporate it as part of how we create.
Yesterday, I had the opportunity to go in and ‘observe’ an XD workshop as part of an inception. If anything I wanted to see how another team collaborates creatively with a client to get that good stuff we need to create stories to estimate that allow us to create the holy grail of a release plan.
What I learnt:
- Ignorance is bliss – I came in NOT knowing anything about the project (it is not a programme!). The team brought me up to speed on the essentials and I looked at the personas for starters. I had to learn fast BUT that element of ‘not knowing’, if used ‘right’ allows you to rely on assumptions based on past experiences, different to what the team has already experienced in the inception - a fresh view
- 2.5 weeks is a ‘long’ time if most of it is spent exploring and not nailing the essentials fast
- Visibility is key – We need to make sure the Parking lot, Out-of-scope, In-scope, RAIDs are ALL VISIBLE and referred to all the time – these need to be up on the wall so the client can see it and so no wires are crossed. Use these spaces to move features in and out but aim to slow movement down before estimating asap
- What a difference a day makes – from little to no new stories to a huge bunch by the end of the day – fantastic BUT existing stories need to mapped to these quickly, Gaps highlighted and ‘filled’ and estimated asap. The client writing stories was great but they need to be read out and clarified asap.
- Help where you can be most useful – sketching, user flows, writing stories, questioning technical feasibility, generally offering a holistic view as an agile coach
- I could be the bad guy – I could bring stuff up and challenge the status quo and stir things up a little. This is interesting as it allowed me to re-energise and bring back items that may have been thrown out earlier into a new light for re-consideration
- Break up – Based on prior experience, working to a tight schedule, separate in-depth, focussed technical break out sessions went well. At some point techinical folk need to separate and nail the technical RAIDs in order to write new stories etc.
- One design is good enough. Remember it is an ‘experiment’: a minimum delightful product. There are enough user flows mapped and enough sketches to start consolidating them into one now. Splitting the groups into 4 instead of 2 meant more exploration but there are many commonalities. Unique ideas can be prioritised and represented all into one layout now. Don’t be afraid to narrow it down and propose one idea quickly. You need this to write and map stories.
- Show progress from one day to the next. Don’t just walk away after a hard days work and pick up from where you left it with the client when they left. User journeys made up of related stories was brilliant they will love that. It shows how we have consolidated a days learnings into a considered and useful new arefact. The same needs to happen quickly with all other aspects of XD and technical e.g. re-sketch screens and interactions to map to user flows leading quickly to an exercise to create one design and eventually wire frames and hopefully a rapid prototype to demonstrate a key our journey with many if not all main touch points
A few last words…
Some clients, some are are still quite set in their ways. Often when a rigid brief is handed to you, personas, prior research, wire frames, ideas are brought in almost as ‘non-negotiables’. Some ideas have even been ruled out before they have even been usability tested or realised. Not easy to take, break and remould…
Perhaps bringing in a casual observer (who never really just observes), who can disrupt is something we should be doing at strategic parts of envisioning and delivery all the time?
ok it is 4am and have have ranted enough (back to bed). Thoughts?