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.

‍

Research Insights & Pain Points

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.

Feedback

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.

Solution Explanation

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.

Iterative Design Learnings

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

‍

Implementation Details

For our product we decided to use a MERN stack which included:

React for the frontend,
MongoDB for the database
Node and Express for the backend

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.

We are using typescript and javascript which gave us a battle at first because of how strict typescript is.

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.

‍

Future Steps

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

Learnings

Product Manager Learnings:

Dana Mitchell

Product discovery is equal parts vexing and wonderful.
Positively a plethora of new experiences; from creating and presenting demos to creating and maintaining a product sprint board, with user feedback interviews being my favourite.
How important it is to take the time to understand the problem space and the user, and how easy it is for assumptions to slip in.

Designer Learnings:

Jacqueline Holtsnider

Working closely with the Developers and Product Managers has shown me the true value of teamwork in building a product. Each person was able to bring in their own unique ideas and working closely with them is imperative for success.
I learned how working closely with my team allowed us to produce better and more well-rounded solutions that were realistic for our MVP and we were able to quickly put out small fires before they became bigger problems.
I also learned the importance of compromise and being able to adapt my designs to fit not only within our users needs and feedback, but also within technical and time constraints as well as keeping in mind our business goals.

Developer Learnings:

Kristin McCollum

Learning what the different roles in a cross functional team are and how they work together.
Having an understanding of the problem space and user helps me come up with better solutions as a developer.
Learning how to refocus and work with the rest of the team to come up with alternate solutions when faced with a roadblock.

Developers Learnings:

John Saguay

&

Learned to work effectively with a team that included a product manager, a product designer, and a software developer. Where I learned proper work flow and how essential each persons job to build a product.
Learned to take in user testing feedback to make changes that would benefit a users experience based on their needs.
Communication & patience because it was essential to make the best out of the time we were able to work through calls since we all worked from different timezones and couldn’t always meet.
The importance of structure and being consistent with coding practices to make a solid base to be able to continue to build on top of as well as make the code readable for other team members.

Full Team Learning

Constraints and compromising on plans can lead to unexpectedly creative solutions..
Keeping on top of your assumptions can be tricky, but staying flexible by treating the product as an experiment makes pivoting easier
Strong communication and trust are essential to a great team, being able to hop into a call to hash-out details preserves momentum
That 4 strangers can be thrown together to create something that they are all proud of :’)