Have you ever participated in a Bootcamp and found yourself struggling to schedule a meeting with your team? You are not alone!
With the rise of tech bootcamps and courses designed to have teams of students collaborating to achieve goals within deadlines, the number of meetings that need to be planned has also risen.
Unlike organisations, who typically have calendars already set up, these small teams are unprepared to coordinate between their schedules and time zones. While there are some tools out there, we found them to be tedious, hard to use, or locked behind mandatory account creation.
After interviewing several students, we had a better understanding of why and how these small collaborating groups form and function. Not everyone in the group will have their Google Calendar’s up-to-date or will have wildly changing schedules around work and life.
Team coordinators were frequently left scratching their heads, trying to find times when their whole team was available. Or they would have to painstakingly calculate their teams schedules to the same time zone.
During our user research, we were able to validate that this was a problem space for many people. Including ourselves! Users frequently reported feeling negatively towards the meeting scheduling process. Coordinators will typically take on the burden of juggling the team’s availability or need to engage in several back and forth emails to try to find a time that works.
As we began to deepen our understanding of our users' pain points, we knew our product needed to be easy to use and easy to understand. With the goal to reduce the amount of mental math needed to schedule a meeting, we decided to keep our flow as short as possible. Settling on a visual calendar as a way to display the results of a team’s availability.
Our initial assumption was that users would prefer to visually see their team’s availability in order to find times when their team could meet, However, after user testing, we pivoted to display a much simpler list.
Now coordinators can see exactly when their team is available at a glance
For our product we decided to use a MERN stack which included:
Initially we wanted to have the server and client in 2 different repositories but then have them deployed separately. However, we quickly realised that given the deadlines we had coming, and with all team members being remote, we decided to keep it all in one repository; however that may change in future iterations.
It all paid off in the end because that way we were able to catch bugs before they became a bigger issue.
We chose to use an existing library for the calendar plug-in to try to save some time in the initial implementation. This led to its own challenges as the documentation wasn't well supported for our uses.
There were also certain limitations to how we could style them which led us to having to change our designs to accommodate it. We may in future iterations build one of our own if further user feedback shows the existing ones aren't doing what we need.
Aside from the calendar, there are a lot of moving pieces to some of the routes and functions that were created, but having a certain organised structure from the beginning allowed us to easily keep track of them and even effectively fix bugs because it was easier to find them.
Team Plan-it will be back after a short break to recharge, to save you even more time and brain power. Some of the features that we have planned include Google Calendar integration and a more flexible schedule
Additional Assets can be found here: https://drive.google.com/drive/folders/1i1goxxNH1LotRRjGqb_WwQKMCwGOeD4f?usp=sharing