Going out with friends is a big priority as we look to stay in touch with one another and maintain our social life. But the planning that is required to successfully bring friends together is the main obstacle for people.

Have you ever made plans with friends and on the day of the plan, your group chat goes silent and the plan falls through? There could be a lot of reasons why this occurs. Friends could be fake committing to plans a week early and will only decide if they actually want to go the day of or they are “home-bodies” and are more inclined to stay at home rather than going out.

That’s where Headsup! comes in, our solution looks to re-confirm commitment to plans amongst group members and force friend groups to differentiate between who’s committing and who's not. We’re looking to break this weird social habit and build an application people can default to, to increase the chance of meet-ups.

‍

Research Insights & User Pain Points

We conducted a survey with a focus group of 66 people and found some really interesting insights.

‍67% said that the difficulty of planning has stopped them from making plans with friends.‍
68% didn’t even follow through with plans that they committed to and the reason they didn’t follow through was either they were too tired from work or they didn’t feel like going.‍
98% usually text their friends to make a plan.‍
53% said that a lack of communication made it difficult to coordinate plans with friends.

The survey gave the context that while they’re multiple layers of difficulty when it comes to planning with your friend group, people’s ability to commit to said plans is also an important variable to take into account when planning.

‍

User Feedback

While conducting user interviews, we were able to further look into this struggle to commit and found that some friend groups have this recurring social quirk. When making a plan with friends, it is required that everyone commits a second time on the day of the plan and if this final confirmation doesn’t occur the plan falls through.

The problem is that this social quirk is the source of why people “flake” on plans and is an unspoken rule of thumb that doesn’t have a solution.

‍

Solution Explanation

HeadsUp is a web application that allows the initiator/planner in friend groups to send automated text messages 24 hours before the event and determine how many friends are actually committing to the planned event. This would be done by inputting the date of the event and the name/phone numbers of the friend group members and creating a “headsup”. The friend group members receive a text before the event where they have to reply with a yes or no.

After each member responds, the planner can view their dashboard to view their friend's responses and initiate a more efficient conversation with their friends about whether the plan is happening or not.

‍

Lofi & Hifi Mockups

Iterative Design Learnings

After we showcased our prototype to the users again, we learned a few things. First, the meeting details page needs to have a better user experience, it’s easy for users to mistake the input field as filled out. Secondly, there needs to be an easier way for users to add in their contact details. Lastly, there needs to be a way for users to view their current events with details. We were able to implement most of these changes in our hi-fi designs.

‍

Implementation Details

Technical implementation

Hosted:

Front-end: Vercel
Back-end: Heroku

Tech-Stack: Vue 3, Vuex, SASS, Python, and Flask

Technical challenges

The most challenging part was the form submissions which come from two different pages and we need to connect them together.

‍

Future Steps

We will not be continuing the project, however a feature we would want to create would be sending a follow-up text that shows the results of the Headsup to showcase how many friends are committing to the plan. This feature was cut from the scope as we prioritized other features, but it’s a feature that would decrease the number of touchpoints for the planner and increase the time to value for users.

‍

Learnings

Product Manager Learnings:

Abeenesh Uthayan

I learned how to work in a collaborative, interdisciplinary team and together create this unique product that I am really proud of. Every member of the team brought something different to the table and it was a lot of fun to work in an agile work environment and tackle priority as a team.

Designer Learnings:

Rianna Alli

I learned the importance of taking the time and effort to uncover the user’s hidden needs. During our user research phase there was a clear solution that we could have moved forward with but after digging a little deeper during user interviews I was able to uncover that a lot of our user’s have a fear of rejection. Being able to uncover this insight allowed us to develop a unique solution to an age-old problem.

I also learned about the nuances of working with developers. Sometimes as a designer you can fall in love with a solution, but after discussions with your team you realise it’s not realistic. I had discussions with our developers to learn their strengths and weaknesses. This way I could build a design that highlighted their strengths and didn’t require any languages that they weren’t familiar with.

The part I enjoyed the most was learning how to build a design system. I knew early on I wanted to build a design system complete with typography, colour and components. This allowed me to work more efficiently during the prototyping phase and allowed for an easier developer hand-off.

Developer Learnings:

Masih Abjadi

I learned how to have empathy in my team and how to help each other grow as a team by assisting those who require assistance and listening to those who have ideas. Share the joy and win as a team!

Developers Learnings:

Ahyeon Jeon

&

I learned how to collaborate within a team in order to build and iterate design solutions in a time-effective manner. I was able to work closely with the front-end developer and communicate with the product designer to develop a realistic solution to our problem.

HeadsUp!

‍Problem Background