Fieldnotes: Reflections On Social Labs Information Stacks
Designing how information flows in a next-gen social lab
When you’re addressing complex challenges, such as unemployment or climate change, writing a 5 year plan doesn’t really help. Situations change faster than a plan.
Yet that’s our dominant response — strategic planning.
Even the likes of Forbes magazine highlights that leading research shows 70% of strategic plans fail (article).
Thankfully there’s another practice in the field of complex problems, known as Social Labs.
Social labs are a strategy for increasing the likelihood of success when tackling complex problems.
Social labs are a strategic response, a space, and a practice (much like a scientific lab) all at once. For this article’s purpose, I’ll refer to all of those simply as ‘a Lab’.
For more information, check out social-labs.com and the Fieldbook for a quick grounding in what characterises social labs.
What is a ‘stack’?
To help pay attention to all the ‘moving parts’ of a social lab, we talk about a number of ‘stacks’ which characterise different aspects of a lab’s functions.
The Information Stack
For the purpose of this article I want to focus on the Information Stack. Recently I spent a month focused on designing, integrating and reviewing this stack for the launch of Grove 3547. The Grove is a social lab in Chicago which supports young people to develop resilient livelihoods.
Simply put, an information stack is concerned with the documentation, storage, activation and sharing of information within a social lab.
I often liken an Information Stack to floor of journalists in the New York Times. Within that floor, you’ll likely have people creating and publishing stories, storing a variety of data, and people working to push those stories out into the world. The floor will also have people who are out looking for new stories, as well as sharing information that has come to light recently with the managerial team, so that good decisions can be made. This thin slice of the newspaper operations has links with all the other operations of the paper, to help it continue to move smoothly.
This stack needs to take into account how information will be captured, stored and moved through the other stacks, such as evaluation data getting to the facilitation team (Innovation Stack), lab stories moved out into the stakeholder community (outside the Lab), or financial reports moved down to the Secretariat to aid decision making (Governance Stack).
Reflections on designing an Information Stack
Working on Grove 3547 was the first time I’d explicitly designed a stack, so all of these reflections are raw and through a beginners lens. That said, I’ve worked in communications, digital organising and social labs for a few years now, so I’m comfortable with the domain.
1) Context is vital for design.
As I set out to design this stack, I found I had to write myself a brief. My brief had to take into account a wide variety of contexts, including the ubiquitous Who / Why / How / When / What / Where?
What I rapidly found, was that building personas, scenarios and ‘Jobs To Be Done’ for a wide range of these scenarios was the best way to proceed, as there’s too much fuzziness in what will happen in the lab to engineer a suitable solution from a standard brief.
We need to embrace the complexity of a social lab, and design a core infrastructure which people can live into.
2) Focus on behaviour not tools.
Whilst information stacks are inherently going to lean towards the digital, I suggest a focus on the user’s experience rather than the next exciting tool on Product Hunt.
That said, I believe in having an in depth knowledge of a bag of tools, ready for when the need arises, as it really helps to know what’s possible.
For example:
Have a prototyping team which wants an easy way to record videos of their screen with their voice over the top?
There’s an app for that. It’s called Loom, by the way.
Our role as designers is not to force people into behaviours which fit our whims, it’s to make their lives easier.
3) Design the whole, but show the parts.
Very few people need to see the entirety of an information stack. In fact, it will likely confuse them if you do show it to them.
When you want to show people around an office space, you give them a walk through tour, not the blueprints.
The same is true of an info stack. For example, does this make sense to you?
Probably not.
But if I told you: “if you’ve taken a photo of a flip chart you were working on at the second Studio, you would drop it into your team’s Google Drive folder marked ‘Studio 2 & Sprint 3’”, you might have more success.
That’s because most people navigate the world through the lens of their own behavioural triggers and mental models, not an abstract blueprint of a whole system.
After taking all the scenarios and users into account for Grove 3547, this was the model I came up with, but no one in our team needed it, once I’d set up the digital structure.
Instead I created a series of cheat sheets for each of the roles I foresaw, with how they could navigate the digital structure and some examples from scenarios which might emerge in the lab. In addition, if they needed help I ran briefings for each person, to increase uptake amongst the lab community.
Social Labs are already challenging environments where people are asked to learn a lot, fast…
If you want people to enjoy the play, don’t show them everything that happens backstage.
4. Prepare to be wrong.
Most likely you will be wrong with something in the stack. People have a habit of using things in ways which the designer did not foresee.
Designing an information stack to be in place before the lab starts, means that you will have to make some assumptions and leaps of faith before you will even meet most of the participants. Co-design (an approach to design attempting to actively involve all stakeholders in the design) may well not be an option.
So, when people do start using what you’ve created, they’ll find a different way of doing things, which may suit them better. That’s fine, don’t take it personally. Note it, and integrate it into future iterations of the stack (here’s an article I wrote about looking out for those gems).
So don’t over engineer this. Just design a minimum viable solution. You can go a long way with Google Suite (document creation and storage) and Mobilize (communication for groups).
Review how the stack performed midway through and at the end of the first cycle, then iterate to improve it, based on the main pain points.
Summary
The social labs space is still in its relatively early days (15 years or so), so we’re breaking new ground with this work, even for next-gen labs.
I’m keen to share my thinking and reflections with the social labs community as I know I struggled with how to manage Information Stacks whilst working at Lifehack in Aotearoa New Zealand. It was definitely a level up for me to sit down and consciously think it through at Grove 3547, rather than just evolve something on the fly. These are just my musings and I’d love to get a good debate going about what ‘good practice’ looks like for this work.
I’m glad we’ve got a 1.0 design for information stacks for Roller now, a place to iterate and improve from. We’d love to open source more of this work beyond the blueprint I shared above. Keep your eyes peeled on http://social-labs.com for more news on that front!
To find out more about social labs, head to http://social-labs.com
Please do feel free to respond on Medium with your own thoughts, or hit me up on Twitter if you have questions! Finally, please do hit the little heart button if you’d like to help other practitioners find this article! Thanks!
‘Reflections on Social Labs Information Stacks’ by Sam Rye is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
