Free Space

It’s hard to plan a meeting with more than two people. Schedules don’t line up, and it can take forever to find common availability. This is the problem my partner and I were trying to solve.
User Research
UI Design
Project Type
Personal Project
2 Months (1-2 Days/Week)


Affinity Mapping
Empathy Mapping
Competitive Analysis
Low-fidelity Prototypes
User Feedback
High-fidelity Prototypes
Usability Testing


I spoke with 10 people, to get a sense of how they currently plan meetings, be it a casual meeting, or for school/work.

Through the interviews, I identified 2 roles that represented the users:
Personas of leader and supporter roles which lead to optimizing an app for speed and ease of use

Using roles instead of personas was best since we were a team of two and didn’t need to communicate much about the user beyond this information. It also saved time.

Next, I identified how users plan meetings:

Flow chart of two methods of meeting planning and their issues. Using doodle the organizer causes conflicts. Using email or messaging is disorganized.

With Doodle, the meeting planner must pick blocks of time for participants to vote for. This causes issues as people might not be available for those entire blocks of time, but could be available spanning two blocks. This issue compounds the more users you have.

Design & Testing

Through several rounds of low-fidelity prototypes and user testing we validated our feature set and created sensible defaults to make the user experience fast and effortless.

Phone displaying scheduling web-app mockupPhone displaying scheduling web-app mockupPhone displaying scheduling web-app mockup
Low Fidelity Prototype

The next problem was the availability entry screen. As a mobile-first product, we had to find a way to display 24 hours' worth of availability on a small screen.

I created two input methods and tested to see which was preferred. I referenced Google’s Material Design spec to determine the minimum space a user needs to drag the boxes around.

Preferred Method

Finally, I built a high-fidelity prototype and went through testing. Users liked the interactions and knew exactly how to use the product with no instructions.

The final piece was how to determine the rules for how Free Space picks the best time to meet. My partner and I came up with these rules to rank the available times:

  1. No conflicts or 'not ideal' sections
  2. Everyone can attend with some 'not ideal'
  3. Majority of participants can attend
  4. Only some participants can attend

If multiple meeting times have no conflicts users can vote on their preferred time.

User Interface showing how users can select a preferred time for a meeting app

What I learned

Create a Timeline - Even with personal projects it’s important to have a schedule so that you and other contributors can stay on track and keep the project moving.

Set User Expectations - I explained some of what the users should expect during testing, but I had to re-explain some things which told me I didn’t explain thoroughly enough at the start. Moving forward I will test my explanation before meeting with users.

Choose the right tools - I used Figma for both design and prototyping which hurt the feedback on some parts of user testing. I believe with a better prototype there would have been room for a different time entry flow that would be faster. Since I wasn’t able to show the interaction to users properly, they didn’t choose that option.


Users loved the product and were able to get through the prototypes quickly and with no questions. It's hard to measure success without launch, but the first round of product design went well.

(I’ll update this if we get Free Space built at some point)