Streamlining rental space management for recovery-oriented meetings.
Building a centralized platform for administrators to better manage and provide meeting spaces.
MY ROLE
Product Designer
TIMELINE
Jan 2024 - May 2024
TEAM
1 Product Manager
1 Technical Lead
2 Designers
5 Developers
SKILLS/TOOLS
Figma, FigJam, Product Design, Visual Design, Interaction Design
OVERVIEW
Ithaca Community Recovery (ICR) is a non-profit organization providing safe and affordable meeting spaces for Ithaca’s recovering community.
Our client, Ithaca Community Recovery, is a volunteer-run community resource for 12 Step and other recovery-oriented groups and individuals, serving around 30,000 members annually.
I worked closely with a co-designer, developers, and our clients at ICR to design and deploy a system that streamlines the processes involved in offering and facilitating rental spaces: scheduling meetings, booking rooms for in-person and hybrid sessions, and tracking group lease agreements.
Over the course of 10 weeks, we designed a scheduling platform that transformed administrators’ workflow, building a design system and prototype to hand off to developers for deployment.
PROBLEM
Scheduling and updating meeting details is extremely tedious and manual (everything’s all over the place)
Currently, only two volunteer administrators manage ICR’s online schedules and maintain the public-facing website. The process of creating and updating meetings involves 4 different platforms: email, Google Calendar, Zoom, and the ICR website.
Why is this important?
Simplicity
The current system works, but is highly time-consuming and can be confusing.
Scalability
Other and future volunteers should be able to easily understand and navigate the scheduling system.
GUIDING QUESTION
How might we make the process of managing group meetings more seamless and intuitive for volunteer admins?
SOLUTION
A “single source of truth” – a centralized platform for admins to manage and keep track of all meetings.
Creating a meeting
Viewing and editing meeting details
OUTCOME
After designing this in Spring of 2024, we handed off the designs to developers and I remained on board for any additional adjustments to the design. As of Summer 2025, our platform has been deployed and ICR’s administrators (Scott and Matt) are loving it!
RESEARCH
Understanding ICR’s existing workflow
After conducting our first 2 interviews with our partners on the ICR board, we gained a better understanding of the project scope and who our target users are: present and future ICR administrators. As our partners have been the only and current administrators, we ended up conducting only these two interviews:
EXISTING USER FLOWS
Insights
In addition to better understanding our partners’ current meeting-management system, we uncovered some key insights and pain points:
Time-consuming and too many clicks
Administrators have to manually remove extraneous information (e.g., Zoom invitation text) that comes with creating Zoom meetings and Google Calendar events.
Meeting conflicts
No two meetings can happen in the same room or Zoom account at the same time. Administrators must keep track of lease agreements and which Zoom account is used for each online/hybrid meeting to avoid any conflicts
A need for adaptability
ICR offers 3 modes of meeting (in-person, hybrid, and online). Each meeting mode requires a slightly different scheduling process, and ICR needs a better way to streamline the process of creating each type.
We prioritized 4 main features:
Meeting management
Admin should be able to create, edit, and delete meetings.
Visibility
View meeting details, with an emphasis on time and location.
Flexibility
Meeting creation should account for meeting mode and adjust accordingly.
Attachments
Generate Zoom links and attach relevant documents, such as lease agreements.
IDEATION
With more insight into our users’ workflow and pain points, my co-designer and I set forward to flesh out a new user flow and information architecture.
We started by integrating our solution into ICR’s existing website...
Our first iteration of the information architecture was divided into 2 sections, each designed to address a specific goal:
An internal admin page for creating and managing meetings
A public-facing page displaying upcoming meetings
INITIAL INFORMATION ARCHITECTURE
We started by integrating our solution into ICR’s existing website...
Uncertain about how to integrate an administrative end to the website, we spoke with our clients, who clarified that they wanted us to preserve the overall structure and branding of the existing website.
Therefore, we shifted our primary focus to designing an admin platform for creating and updating meetings and outlined a user flow:
REVISED USER FLOW
Administrators typically receive requests for meetings and changes via email – we initially considered including an inbox feature containing these requests, but given our short timeline, did not include it in our MVP.
Our clients were also routinely checked their emails first and it would be tricky to reflect (in real time) any communicated changes made via email thread.
Finding a way to display existing meetings
We started off by creating different versions of a dashboard -- the main interface for administrators to view and search through existing meetings, as well as a place to create a new meeting.
DASHBOARD EXPLORATIONS
We initially considered a list view because the current website displays meetings in the same format, but soon realized that the tabs organizing meetings by type (AA, Al-Anon, Other) prevent users from easily identifying location or time conflicts.
We moved forward with the calendar view, which was the most intuitive and standard for meeting management. It displays all meetings at once while distinguishing meeting type with color coding.
Creating a new meeting
We experimented with 3 different UIs and flows for creating a meeting: a separate page, modal, and sidebar.
EXPLORATIONS: CREATING A NEW MEETING
We initially explored a separate page and modal, choosing the modal because it allows users to view the calendar while creating a new meeting. Our partners were also familiar with this UI through the Google Calendar interface. However, I felt that a sidebar might be a better option instead because:
Continuous context
A sidebar allows users to maintain total visibility of the calendar, so they can refer to other events and avoid conflicts.
Efficient use of space
Unlike a sidebar, a modal could disrupt the workflow by covering a significant portion of the calendar.
Fewer clicks
Having a sidebar reduces the number of clicks required from users.
Refining the UI for consistent branding
Moving into high-fidelity designs, our partners specifically requested that the platform’s overall branding remain consistent with ICR’s website (following a simple black and white color scheme). Although we preferred the dark periwinkle as our primary color, we honored our partners’ request to align with the existing branding and moved forward with a dark fuchsia.
HIGH-FIDELITY DESIGNS VERSION 1.0
We initially chose to organize and color-code meetings by type/calendar (AA, Al-Anon, Other) because the existing website is organized by this. However, a major realization led us to make some major changes.
PIVOTING
We had lost focus of the main goal: preventing double-booking by making rooms more visually distinct.
Our partners loved the earlier designs, but later re-emphasized how they wanted to be able to sort by rooms, rather than meeting type. Our earlier designs failed to address this concern and better highlighted time conflicts, which was not as big a concern given the many rooms and Zoom accounts available.
HIGH-FIDELITY DESIGNS VERSION 1.0
Given the limited amount of time left, we considered staying consistent with the overall structure of our designs and color-coding by rooms instead. However, we realized that in the case of multiple simultaneous meetings, meeting blocks would become much too narrow and difficult to read.
We considered creating color-coded columns for each room as well. This avoids overcrowding, but requires horizontal scrolling because not all rooms and Zoom accounts are on the same page.
Ultimately, we chose a stacked timeline format, where each row represents a color-coded room.
This design clearly indicates which room or Zoom account is occupied and therefore, best avoids the possibility of double-booking.
It is also a more efficient use of space and if ICR opens more rooms in the future, users can vertically scroll instead.
DESIGN SYSTEM
Preparing the final touches for hand-off
To maintain consistent visual design throughout the process and reduce developer lift, we continually updated a UI component library based off the ICR branding.
DESIGN SYSTEM
TAKEAWAYS
Never underestimate a challenge
This project would be very impactful for our clients but more experienced designers, we didn’t think this project would be particularly challenging. However, we later on realized we’d lost focus of the main goal and had much to learn.
Don’t get lost in the details, keep the bigger picture in mind
We spent a lot of time on smaller iterations but overlooked the need for broader iterations when we began exploring designs. We should’ve iterated more on a dashboard to prevent double-booking rather than perfecting the finer details.