At Bocoup we believe that focusing on crafting resilient and accessible experiences is the most effective way to build digital services. This philosophy and practice extends to our learning design. In an earlier post, I talked about building a curriculum framework with a design driven approach—this involved user research, persona and journey map development, and some testing. Let’s dive a bit deeper into the next phase for the workshop offering: lesson plan development.
As the title of my post suggests, eventually the process for learning module development became remote first. I’ll explain how we got to this approach, but it’s worth noting that whether you are in an office or working offsite, you are a remote employee. This is because our clients are virtually everywhere and teammates are a hodge podge of in-person and remote colleagues.
Goal oriented learning
A workshop participant is probably bringing a handful of goals and expectations with them to the activity. We start by leveraging this data point. As with any design, for workshops, we identify user goals and build the experience to meet those goals. From doing some simple research exercises, we came into lesson plan development knowing that there was a strong desire for users to walk away from the workshop having a general understanding of the Bocoup approach to user experience design. After a bit of brainstorming, it became obvious the best way to tackle this learning objective was to treat the workshop as an opportunity to collaborate on a design project.
Determine what project to work on
I’ve been a long-time proponent of project-based learning. In design, it seems like a no-brainer, but you’d be surprised by how many lectures, workshops, talks, and conferences I’ve attended that are all talk and no action. Project-based learning can simply mean working on a specific activity that simulates a real world situation, but working in open source means we have the unique opportunity to actually work on practical design problems that will have a real world impact.
Designing what to work on took tactical planning. For testing purposes, I knew that my first group of workshop participants would be Bocoup staff. What would be an activity to have all of the staff work on? It couldn’t just be a normal project such as, “fix our website”—it had to solve a problem we all felt empathy toward so we felt motivated to work on it in the workshop and (in a fantasy world) beyond. After some brainstorming, we decided to work on an internal skill-sharing problem we have been trying to wrap our heads around at Bocoup.
To clarify the opportunity space, we crafted a design brief and scope of work (SOW). What’s involved in the project? What are we not going to tackle? What are the challenges? I drafted this as a simple markdown file in GitHub. Writing the file in GitHub allowed others to collaborate on the document easily and gave us a chance to get comfortable working in a dedicated repository.
Build the project team
Bocoup is by nature a distributed organization. We have offices in New York and Boston, and remote colleagues all over the world. When we scheduled a “workshop” day for the entire team, the fact that we had three location categories (NY, BOS and “remote”) quickly became a challenge. In order to be successful in synchronizing this kind of dance sequence, I knew I would need some help. I was able to pull in two colleagues, Mat Marquis and Sue Lockwood. Mat is based in Boston, Sue in Seattle, and I’m in New York, so they collaborated on the project with me and acted as location leads on the day of the workshop. We set up a dedicated Slack channel and swiftly found ourselves passing files back and forth.
The way we worked together was similar to product development—we had daily stands or check-in meetings, and then worked mostly asynchronously using Slack and GitHub.
What is remote first lesson plan development?
As I started to write the different learning modules for the first activity, the “design-o-meter” (an activity designed as an icebreaker to get participants to have a conversation about the word design, and if they in fact identify as a designer), Sue and I had a very interesting (now obvious) realization: the hyper interactive and physical design workshops I have been used to running would need to be reconsidered with a distributed team in mind. I had an activity in mind that is actually a remix of an icebreaker I learned from Allen Gunn (Gunner) at Aspiration Tech called the Human Spectrogram. Here’s a description of this activity:
In a spectrogram, colored tape is laid out across an open floor. Ideally the tape stretches 15-20 yards/meters. One end of the tape is marked as “Strongly Agree”, and the opposite end is labeled as “Strongly Disagree”. Cross-marks are made at the 25%, 50%, and 75% points along the line.
Participants are then read a short, controversial or extreme statement. Those who agree with the statement are invited to move toward the “Strongly Agree” end of the line, positioning themselves closer to the end if their agreement is complete and towards the center if their agreement is mixed. Those who disagree with the statement are invited to do the same in the opposite direction.
The facilitator then interviews people along the line, asking them why they are standing where they are. Passion is encouraged in describing positioning, and listeners are encouraged to shift their position on the spectrogram as points are made which alter their thinking and perspective on the question.
I worked with Sue (who is a wonderful illustrator: check out her twitter feed!) to draw out this diagram to explain how it would work:
As you can probably guess, the core interaction here—moving around the room—wasn’t going to be possible for remote participants. We solved this with a few tactical decisions:
- Create a remote “team” that has a dedicated Slack channel
- Have all teams connect to a video call for major presentation chunks and have the remote team join together in a dedicated appear.in channel when teams break out for physical activities
- For this exercise, leverage Trello—each participant, instead of moving their physical location, had a dedicated Trello card to move around to different columns.
After we figured out this exercise, we decided to design the remainder of the activities as remote first (ugh, I know, yet ANOTHER x first approach, but …. but hear me out!). This just means that from here on out, we asked ourselves the question, how might we make this the best possible experience for remote participants?
Things we learned from remote first design
After designing a few remote first modules, we learned a few things:
- Working remotely should be celebrated: We are a distributed community, and there’s a good reason for that. It allows us to have a diverse workforce with many different kinds of viewpoints. So, instead of looking as remote employees as an obstacle, let’s see remote as the norm.
- We produced great documentation: The secret to working remotely is over-communicating. As such, we were able to produce a plethora of documentation so that now anyone at Bocoup can remix the learning content into different configurations for future workshops. Now, documentation is a living activity instead of something static that is created at the conclusion of a project. Plus, workshop participants are essentially documenting all of their work, so there are no reminders to take photos of that, save this, or remember to drop it into a shared file because it’s happening all of the time.
- Remote first = open source: This one is subtle, but thinking about remote work is truly the only way a project can be open source. You are eliminating any barrier to participation.
As Sue pointed out, “Since we were a remote team working together (none of us were in the same office) in order to test out any of the exercises we had to make them remote, so it was natural that we approached it this way in order to collaborate on the workshop.”
Writing modules
So the last thing I’m going to mention here is that after understanding a) who we were designing for (via personas), b) how we were approaching our activity creation, and c) what project we were developing (skillshare), we broke down the activities into small remixable modules. This way, we weren’t planning the entire 3-hour session, but were instead focusing on concrete digestible chunks of user goals.
Finally, when it was time to structure the flow of the workshop, we stacked together modules that complemented one another. I feel anxious when I’m in a workshop and don’t know what’s coming up next, so I like to post the agenda prominently. We demonstrated this in Slack by “pinning” the agenda, and by posting a handwritten agenda in the New York and Boston offices, like so:
In future posts, I’ll talk more about how we do our user testing and take feedback into account. In the meantime, we’d love to hear if you have considered distributed team workshops. Do you have any best practices you might be able to share?
Be sure to check out the Learn Open Design Skills workshops in New York this winter. The last day to register for all three workshops in the series is February 18th.
