Ithaca Community Recovery (ICR) is a non-profit organization dedicated to serving over 30,000 members annually by providing safe and affordable event and meeting spaces for Twelve-Step programs and other recovery-oriented groups. We collaborated with ICR to design and deploy a system that streamlines the processes involved in offering and facilitating rental spaces, including scheduling meetings and updating any changes.
Ithaca Community Recovery (ICR) is a fully volunteer-based non-profit organization dedicated to providing safe and affordable event and meeting spaces for Twelve-Step programs and other recovery-oriented groups. Each year, they help over 30,000 people in the greater Ithaca area, and their work has time and time again proven to be incredibly important and impactful for the community.
The problem: their current process for scheduling and updating meeting details is extremely tedious and manual, involving many steps that are not manageable or intuitive for most volunteers.
The solution: we were tasked with designing a new scheduling platform to streamline the process of setting up and managing group meetings. This platform will allow ICR administrators to create and schedule meetings, book rooms for in-person and hybrid sessions, manage Zoom links for online and hybrid meetings, and track group lease agreements.
Initially, we planned to interview three different groups: website administrators, ICR volunteers, and members seeking help. After our first two interviews with our partners on the ICR board, however, we gained a better understanding of the project scope and the target users for our redesign (present and future ICR administrators). Therefore, we ended up conducting only two user interviews:
These two interviewees are currently the only individuals managing ICR’s online schedules and maintaining the public-facing website; however, because ICR operates on a volunteer basis and this is not their full-time job, their capacity is limited and will likely need to recruit additional volunteers in the future.
Therefore, they hope to streamline the existing user flow for creating and updating meetings on the ICR website, ensuring that future volunteers—even those who may not be tech-savvy—can easily navigate the system.
In addition to better understanding what the existing system of managing the ICR website looks like, we gained important insights into pain points our partners were struggling with:
We moved forward with the following goals in mind:
Our first iteration of the information architecture diagram was divided into two sections, each designed to address a specific end goal:
We were uncertain about how to integrate this into ICR’s current website, as during one of our partner calls, they emphasized that they wanted us to preserve the branding and overall structure of the existing website. They also indicated that our primary focus should be on designing the administrative side for creating and updating meetings, so we developed a user flow that met these priorities:
To create a meeting, administrators receive an email containing details about the proposed meeting, including the mode (online, hybrid, or in-person), location, date, and time. They then access their dashboard which displays existing meetings, and initiate the creation of a new meeting. First, they must select the meeting mode—fully online, hybrid, or fully in-person—since the processes for each mode differ significantly. After selecting the mode, administrators can input all necessary information, create a Zoom link if required, and upload the new meeting to the meeting calendar.
We first created different versions of the dashboard — the landing page for administrators who want to view and search through existing meetings, as well as a place to create a new meeting. We considered three different view types: list, cards, and calendar.
We moved forward with Option C as we believed that displaying meetings via a calendar was the most intuitive and standard approach.
We also experimented with the flow of creating a new meeting: choosing between either a modal or a separate page.
We chose Option B (a modal), primarily because it allows users to view the calendar while creating a new meeting, ensuring that there is no overlap.
However, after some discussion with our partners, we decided to instead allow users to create a new meeting in the sidebar, rather than having a modal because:
When an existing meeting is clicked into, the sidebar appears similar to when it’s in Create a Meeting mode, except the information is non-editable. We decided on this design because it’s intuitive and simple to develop. The user can also click the ellipses to reveal a dropdown that allows them to edit or delete the meeting.
When editing a meeting, the sidebar also appears very similar to the “Create a Meeting” mode. Additionally, when a meeting is being edited, a dashed line moves around the border of its occurrence cards to indicate that this specific meeting is being edited.
As we transitioned into high-fidelity designs, our partners provided specific requests for the color scheme, emphasizing that the platform’s overall branding should remain consistent with ICR’s main website (simple, black, and white). Although we initially preferred the dark periwinkle we had been working with, we ultimately honored our partner’s request and used a dark fuchsia that aligns with ICR’s existing branding materials.
Our calendar also allows users to switch between daily, weekly, and monthly views. In the daily view of the screen, the three ICR calendars — AA, Al-Anon, and Other — are separated into three columns.
We were confused, however, about what to do if the user deselected one of the calendars with the sidebar filters. In Option A, all three columns are always visible, and the meeting cards of each calendar disappear as the user unselected said calendar. One large concern with this, however, is if the user doesn’t notice that a certain calendar is unselected, they might end up believing that there are no meetings on that calendar for that day, when in reality the meetings are simply not visible at the moment.
In Option B, the calendar column would be removed once the user deselected that specific calendar. Our primary concern was that we didn’t know what the calendar would look like if the user deselected all three calendars. To address this, we decided to implement this option but design it so that at least one calendar must remain selected at all times, ensuring the calendar is always populated and functional.
Our partners loved and approved of these designs for the most part, but they recently re-emphasized how they wanted to be able to sort by rooms rather than by calendar, as the primary concern for the admin was to prevent double-booking of rooms and to make room differentiation more visually distinct.
With this in mind, we went back to the drawing board and iterated on our dashboard:
We tried to maintain the rest of our original designs in Option A and simply differentiate rooms by color rather than calendar. However, in the likely case that there are several meetings happening at the same time, meeting blocks would become much too narrow and difficult to read.
In Option B, we created columns for each room and color-coded by room. While this avoids the issue of crowding in Option A, we want all the rooms and remote meetings to appear on the screen at the same time, without additional scrolling.
Ultimately, we chose Option C, which took on a more different approach with a timeline format in which each room has a row. This design clearly indicates which room or Zoom account is being occupied at a certain time and therefore, best avoids the possibility of double-booking. It is also a better use of space, all rooms and Zoom accounts can fit on one page, and if, in the future, ICR has more rooms, users can vertically scroll to view more.
As more experienced designers on the team, we initially thought this project, though impactful, wouldn’t be particularly challenging. However, we quickly realized how much we had to learn, especially after a last-minute change.
While we focused on many small-scale iterations, perfecting the finer details, we overlooked the necessity of higher-level iterations. In hindsight, we should have emphasized broader iterations to prevent issues like double-booking rooms and to better align with the overall project goals. In other words, we should have kept the bigger picture in mind.
Moving forward, we will focus on addressing edge cases and preparing for developer handoff during the summer; the developers are scheduled to implement much of the front end in the fall.
It was amazing getting to work so closely with friend and fellow designer Tiffany Lee, as well as all the other designers on Hack4Impact and members of the ICR team. It’s been a great semester and I couldn’t have asked for cooler peeps to work with! #HAGS ❤ 🌎
