Remote Design Sprint for capstone project: a review
For our capstone project, we were posed with the challenge of solving an interdisciplinary problem in a team. As we are heading towards the end of our program, we were aiming to implement our previously achieved skills in a practical setting. There were five of us in our team — all of us but two members came from different countries and we all represented quite different academic and professional backgrounds. The Interaction Design scenario which we chose to solve was inspired by a real situation resulting from the COVID pandemic and concerned helping a hospital to efficiently manage the workload of the nursing staff keeping both personnel and patient needs satisfied.
During our project, we got our scenario and through investigation, reflection, and design activities, constructed and proposed a commercially valuable solution all by through working in an online collaborative environment. We followed design thinking activities, an adaptation of remotely-run Google Ventures Design Spring. The Design Sprint is a week-long process of design, prototyping, and testing ideas with customers that helps to answer critical product and business questions.
We started by planning our Sprint using a Gantt chart. Later on, it turned out to be very hard to strictly follow our schedule; our Design Sprint was extended into many weeks of the semester, instead of taking 5 days, therefore it was very challenging to predict our availability. However, early planning was definitely useful as it allowed us to see the bigger picture of what needed to be done. During the planning phase, we already realized the limitations but also the perks of running a remote Sprint. For us, the experience included:
- Challenges of effective communication — asynchronous communication would, at times, be spread out in time resulting in a lower effectiveness of activities. Working over the video was also less effective compared to being in the same room.
- Scheduling and coordinating each team member’s availability, working in different timezones — in the middle of the semester, one team member moved to a timezone much different from the rest of us and having full schedules of both work and private lives, we definitely struggled with getting to all work at the same times.
- Some technology limitations.
- The convenience of being able to work from our own home settings, saving time we would need to dedicate to get to the same place to work together, even if we all lived in the same city.
The technology that we used was all very helpful, despite some minor limitations (e.g. Google Meet would only allow a meeting creator to record the session, Miro didn’t allow us to actually draw on the storyboard, etc.). We used:
- Slack for all asynchronous communication, chatting, and sharing files
- Google Meet for synchronous sessions, meetings with experts and customers
- Click Up for the Gantt chart
- Miro for the Design Sprint
- Pen and paper for sketches and storyboard drawings
- Figma for creating the prototype
- Google Docs and Slides for our session reports
I would say that Miro online collaboration/whiteboard tool is extremely useful for Design Spring purposes and without it, our work would be much less effective and more chaotic. It helped to run the remote Sprint in a way similar to the real-life setting.
Our Monday and “understand” phase were vital for setting our product’s direction. Two activities strike me as the most valuable: Ask the Experts and How Might We. Our Experts included two doctors with prior experience as nurses, familiar with COVID hospital ward reality. Thanks to listening to their first-hand experiences, we were able to adjust our long-term goal and fully understand how does our solution fit in the environment we were designing it for. Therefore, we were able to form How Might We questions that set the ground for our sprint target.
I thoroughly enjoyed our Tuesday session with the Lightning Demos and the Four-Step Sketch activities. It was very helpful to research solutions similar to ours and sketching let us unleash creativity. It was also all done asynchronously so we were able to work at our own pace. During the Wednesday session, our idea really got into shape as we chose the features of our solution. This was the week when I got to be the Facilitator, and I found this role quite challenging as it required me to take on leadership skills. In our group, the team balance was mostly just right as one member positioned themselves in a more of a leadership position, however, we decided to pick out new facilitators for each session and that allowed all of us to try it out.
For our Thursday and Friday sessions, we divided the new roles and I got to be the Interviewer, so I haven’t worked on the actual prototype. I realized that this might have been a missed opportunity because I want to improve my Figma skills and I could have learned a bit from the more experienced team members. Conducting interviews, however, was a really pleasant activity, as our customers had very insightful feedback and they seemed to like our solution a lot. I would say that the most surprising thing that I learned throughout the whole process was how our interviewees working at hospitals were very impressed with the idea and although they have seen somewhat similar solutions for managing staff, they never stumbled across something exactly like that even though they express a need for it.
Finally, the most difficult part of the process for me was the communication and coordination issues mentioned before. It wasn’t easy to always get all of us to collaborate efficiently due to hectic, quite different schedules. In the end, though, I’m satisfied with all of our work. As for the most rewarding moment of the experience, it was definitely the customer interviews during which I was under impression that our interviewees genuinely liked our product a lot.
Running a remote Design Spring is hard but it can have its perks and after this semester I’m entirely sure it can be just as effective as an in-person Sprint.