A few months ago, I had a chance to run our first-ever remote design workshop here at Tetrate. This idea came when we were trying to think through about how a UI should look like, that caters to an ideated new feature for our product. As a product company, of course, we have to iteratively build the product, based on feedback from users, adding new features from time to time to provide value for them.
Since this new feature also involves new thinking from across different roles, we decided that instead of doing a traditional discussion over a meeting, we'd do a design workshop, remotely, since we're a remote company after all. So, I was tasked to prepare and run the workshop. Even though I've done this kind of workshop numerous times in the past, this was my first time doing it remotely. So I was super excited, but anxious at the same time since I knew, my usual tricks of facilitating might be lost in the process because the participants weren't going to be sitting in the same room.
Fast forward, the workshop went well. It managed to accelerate understanding between us of what this new feature is going to be, how it gives values, and most importantly, as the person who will design the UI and UX of this feature, it gave me a good starting point to do the work. Of course, the workshop itself wasn't exactly 100% as I wanted it to be, but of course, this can be a lesson for future activities. So, here are a few things that I learned after doing our remote design workshop.
This is fundamental, as it'll be derived into a series of tasks that should be happening during the workshop itself. For me personally, the workshop was held so I know what needs to be displayed on each of the UI screens and how is the flow going to be from screen to screen. To reach this goal, I need to know what are the important tasks and information needs to be conveyed by the product.
Normally, I would just define the workshop rundown. But since this is remote, I need the participants to be on the same frame before the workshop itself. So I detailed the workshop plans, explained the goal, the schedule, and what are the step by step tasks that we're going to do. I wrote it down as a document and sent it to the participants, around a week before the workshop. This way. I can ensure that everyone had the same starting point, give or take.
Now, for the workshop itself, time plays a crucial factor. It's hard to sit together for 2 hours, remotely, let alone more than that. I always find myself exhausted after an online meeting that goes close to 2 hours, so I kept that in mind while planning for the workshop. So my goal was to end this workshop in 2 hours, thus each activity had to be planned and timeboxed properly.
In my case, it didn't exactly go as prepared, we ran for 2 hours, but we missed out 1–2 activities, partly due to the fact that this issue that we're tackling is still conceptual, thus any verbal discussions that go overtime were expected. In the end, though, I managed to squeeze in a lot of important details that otherwise might be missed. Some note for the future.
Normally, I'd do everything on the workshop, discussion, solution exploration, and solution building (though in prototype level). But as we're living in such a big timezone difference, this isn't possible. Thus, I broke the workshop down into 2 kinds of activity: problem domain exploration and solution domain exploration. For the problem domain, this was done synchronously on that online workshop with the goal of getting everyone on the same page as fast as possible. Next up, for the solution domain, this was done asynchronously. I mainly tasked myself with building the visual representation of what being discussed, thus, it can be discussed asynchronously, in each person's next available time. If you're working remotely, asynchronous communication is a vital part.
As a means to bring everyone to look and refer to the same object, I use an online whiteboard. Thus, everyone can use this to write on virtual notes, sticks, and cluster them. Later on, we used this cluster as a starting point of discussion. The best part was we could have a living, visual documentation on the meeting itself that could be used for future purposes. This is an extra important part, as normally, a verbal only meeting would be undocumented, without the extra effort of writing a meeting minutes.
During our workshop, we used Miro, but others did well too with Mural. It's not just on the tool, but also how we utilize it. In our workshop, I ended up creating several frames, each for its own activity. Thus, it helped me in directing the participants and they would have an initial idea of what to do.
Though, if I were to do this in the future, I'd definitely do more work on this part and create a canvas style template (such as Lean Canvas) for the participants to play with. Further increasing the clarity on what to do.
So there you are, I hope this article helps you in setting up your remote design workshop. As we're embracing remote work, I'm pretty sure that this kind of activity will become the norm rather than the exception. Feel free to contact me through Twitter at @kotakmakan if you want a deeper conversation about this topic. Happy workshop!