How design studios can accelerate group learning through self-initiated projects
Striving towards a multi-faceted approach to learning as a team
Previously, I wrote about the Slack bot that Marion and I built in moments carved out between hectic stretches of client work at AQ.
In addition to producing a tool that greases our daily communication wheel as a distributed team, this small project also served as a self-initiated exploration in designing tools without screens.
In their work on organizational learning, Crossan, Lane and White point out that there’s “a tension between assimilating new learning (exploration) and using what has been learned (exploitation)”.
In order to be effective as an external design team for our clients, we need to investigate new ideas (exploration) in faster, deeper cycles than the work itself (exploitation) allows. Internal projects are one way to do this. In an agency context, they are ridiculously easy to start but often agonizing to finish. “It’ll be cool!” is quick to grow stale in the endless winds of competing interests — namely, deadlines and the next billable project.
Though Meekee’s path to release was neither short nor straightforward, there was something different about how we approached the project that made it always feel fresh.
Looking back now, I can trace a multi-faceted and collective approach to sense-making and learning that can be carried on in other initiatives and developed further.
- Identify individual interests and share it with the team
- Assign a specific space about the broader exploration
- Invite teammates to add to the narrative
- Externalize ideas by presenting to peers
1. Identify individual interests and share it with the team
Marion and I were united in our interest to launch a tool that we’d both get good use out of. Within that shared objective though, we were curious about different things.
As a software engineer who’d studied system programming before web, Marion was keen on creating an Open Source tool that would support remote teams and have an opportunity to implement authentication with different services. I was curious about the emergence of bot technology and the interaction design challenges that come with it.
We were explicit in these interests from the beginning, and because we pursued them with equal enthusiasm, the project sustained a natural diversity of perspectives and information sources.
It’s a good sign for the project if teammates can articulate a POV on their personal interests. It’s not like a brief — this must come from within.
2. Assign a specific space for the broader exploration
Like all other projects, this one had its own channel on Slack, hooked up to Github and the usual suspects. It was called #build-bots (instead of #meekee) and became a space to exchange broadly about bots — not just to share status updates and fix bugs.
The channel also included lurker teammates, who were happy to tag along for the ride. We played with apps, prototyping tools, and machine learning libraries, and shared those discoveries.
In hindsight, our activities in this “space” kept oxygen pumping through a project that inevitably had long stretches of time when no one was available to work on it.
3. Invite teammates to add to the narrative
Our project teams are encouraged to present learnings in the weekly all-hands meeting, but frequency is spottier than I’d like. It’s perceived as yet another thing that to do on top of delivering the project itself, and tends to get pushed back until forgotten. 💀
With Meekee, we experimented with an Ask Me Anything session. Removing the burden of formulating content (no prep required!) turned out to be the key to making it happen.
More importantly, it encourages non-project members to actively connect to what was going on, which leads to broader ownership and narrative.
4. Externalize ideas by presenting to peers
AQ organizes a designer/developer meetup called Ride the Lightning in our Tokyo office, and it was an obvious choice to do an event about bots.
Many of our peers had a keen interest in the topic but hadn’t really found the time to do their own investigations. We invited a bot startup as a second speaker, and spent a fun afternoon exchanging with our local designer/developer community.
Marion has also written a technical write-up of her experience building a Slack bot with a Google Apps integration — her first time publishing an article for the company.
Looking forward
Inevitably, a re-design project for a chatbot framework came our way. And whenever I facilitate workshops, someone’s always proposing a bot.💥 So, there were plenty of opportunities to apply what we learned, yet I feel there were meta-lessons that were really valuable, too.
In our field of UX design, we preach the value of a shared understanding of the problem space as key to cohesive, collective action towards a common goal.
What I learned through building Meekee is that a shared ownership of learning can be equally powerful, and also deserves to be fostered.
Organizational learning is a multi-level activity, with a sequence and progression to processes between three levels — individual, group and organizational.
I see this project as a successful case of Individual-Group learning, in which we stumbled upon soft and hard systems to support these dynamic processes.
The next challenge — and more difficult, perhaps — is how to make the leap to institutionalize the learning in the Group-Organizational dynamics.
