I spent plenty of time this week trying to work through what we have learned so far on a piece of work and how that informs the next steps of defining a strategy.
The short story is we’re looking to set a customer experience vision for shopping in a food store, with a strategy that helps us move towards that vision.
I won’t bore with the details but as a team we’ve been gathering existing research, doing new research, spending a lot of time with subject matter experts and running iterative trials in stores to discover:
- The high level needs customer have when shopping in a store
- The needs of colleagues to be able to meet those customer needs
- What prevents us as a business meeting either those customer or colleague needs
For me this is a solid basis from which to define a (user-centred) strategy, but I personally and as a team we were still grappling with what the relationship was betwen these three and a coherent strategy for action.
So obviously, I tweeted 🙄
The particular thing I was working through, which I’m not sure I communicated that well was whether it was helpful to bake specific user needs into the strategy, or should the strategy be ‘to meet user needs’ in a user need agnostic way?
Tero Väänänen, Head of Design at NHS Digital has written a great summary of why user centred design can be strategic (not just tactical I guess) but what I took from his article was that the strategy is meeting user needs in the general sense, rather than meeting specifc user needs that then get referenced in the strategy.
But as Co-op colleagues helpfully pointed me in useful directions, Sophie Dennis made an excellent point:
Probably what I was lacking was clarity around which layer the strategy work we were doing sat, and that was driving the uncertainty around how to include user needs. Tero’s approach was targeted at those setting org level strategy (who probably needed to hear the value of user centred design most) whereas by the time you get to product teams you can be a lot more explicit about which user needs you will be meeting.
This is in part because of the speed at which those different layers of strategy change. An idea helpfully visualised by Stewart Brand’s pace layering concept:
Would it really be a design strategy post without pace layering?
If I riff on this diagram specifcally for this conversation it might look more like this :
Its radically simplified to make a point. But essentially communicates that the org strategy is realtively static – as Tero (and others in that thread) have said better than I, it should be to meet user needs. At that level it should accomodate the natural changes that happen to user needs over time by not being specific about what those needs are.
But as Sophie pointed out, at the product team level the implementation of ‘meet user needs’ as a strategy looks different. Because as a team they should have clarity of what those needs are through regular exposure to users/customers etc then they can work to continually evolve their strategy, metrics and measures of success to reflect changes in those needs. The pace of change at each level is different.
I think the reason I’m struggling is because we’re trying to work at business unit level, and so I’m less certain about the ‘middle ground’ of baking user needs into a strategy at this level. The pace of change is slower than a product team but faster than the org as a whole.
alistairuff 
Leave a comment