Ithaca Community Recovery: Streamlining Management of Rental Spaces for Recovery-Oriented Meetings
Overview
Client: Ithaca Community Recovery (ICR)
Team: Cornell Hack4Impact — Project Manager: Afran Ahmed; Technical Lead: Joseph Ugarte, Designers: Tiffany Lee, Katherine Chang; Developers: Sophie Wang, Srija Ghosh, Sneha Rajaraman, Mohammad Islam, Sanya Mahajan
Timeline: Spring 2024 (3 months)
Task: To update ICR’s current website platform to streamline the process of scheduling and managing meetings.
Context
Ithaca Community Recovery (ICR) is a non-profit organization working to serve as a community resource for around 30k+ members a year — they provide 12 Step and other recovery-oriented groups. They do so by offering safe and affordable events and meeting spaces that can be used to facilitate said meetings.
ICR is looking to design and deploy systems aimed at both streamlining the necessary processes that go into offering and facilitating a rental space as well as making their services more accessible to those that are technologically disconnected or lacking thereof.
The Problem
Currently. there is no centralized location for administrators to create meetings, book and keep track of their locations, make any updates. Additionally, services become difficult to keep track of and utilize for those who lack technology.
Our Solution
To help Ithaca Community Recovery manage meetings, we created a scheduler platform to simplify the process of setting up and facilitating group meetings. Administrators will use this platform to create and schedule meetings, book rooms for in-person and hybrid meetings, manage Zoom links for remote and hybrid meetings, and keep track of a group’s lease agreement.
Additionally, we hope to implement digital signage that will be present in the actual ICR facility to display meeting details (time, location, date). This solution will tackle the problem of limited access to participating in recovery groups for those who lack necessary technologies.
User Research
Initially, we had planned to interview 3 different groups — website administrators, ICR volunteers, and members seeking help. After our first two interviews with our partners on the ICR board, we better understood the scope of our project and the users our implemented redesign would target (present and future ICR administrators). Therefore, we only conducted two user interviews:
- ICR Board President (previously treasurer, IT, developer, and more) — He is also currently the rental agent, managing room rentals and necessary paperwork
- Communications Committee Member — Maintains the ICR website and meetings using Google Calendar and Zoom.
Currently, these two interviewees are the main/only people managing ICR’s online schedules and maintaining the website displayed to the public. However, because ICR is run on a volunteer basis, they will likely need to recruit the help of other volunteers in the future.
Therefore, our solution should both solve their problem and be simple enough such that future volunteers who might not be as tech-savvy can still navigate the system easily.
Key Insights
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:
- Too many clicks — Administrators have to manually sort out extraneous information (e.g., Zoom invite information) that comes with creating Zoom meetings and Google Calendar events.
- Conflicting meetings — No two meetings can happen in the same room at the same time, just as no two meetings can be hosted by the same Zoom account. Administrators must keep track of lease agreements and which Zoom account is used for each online/hybrid meeting to avoid any conflicts.
- Different scheduling processes for different meeting types — ICR offers 3 modes of meetings (in-person, hybrid, and remote), and needs a way to streamline the process of creating each type.
End Goal: A “single source of truth”!
We moved forward with the following goals in mind:
- To empower ONE person to create and update meetings on ONE centralized platform
- To provide digital signage in the ICR facility so that members and people looking to participate in recovery groups to view meeting information.
Information Architecture
Our first iteration of the information architecture diagram split into two sections, each aimed to address a separate end goal:
- An internal administration page where admin can create and update meetings
- A page visible to the public that displays upcoming meetings (sorted by the three types of meetings ICR offers on their current website: AA, Al-Anon, and Other)
We were unsure of how to integrate this into ICR’s current website. During one of our partner calls, they explained that they wanted us to preserve the branding and overall structure of the existing website. They also indicated that we should prioritize designing the administrative side (creating and updating meetings), so we created a user flow that does such…
In order to create a meeting, the administrator receives an email containing information about the new proposed meeting (what mode, location, date and time). They then go to their dashboard which shows existing meetings, and create a new meeting. They will have to choose if it is fully online, hybrid, or fully in person before proceeding as the processes for the three different modes highly differ. Then, they can input all the necessary information, create a Zoom link if necessary, and this new meeting is uploaded to the meeting calendar.
Medium-Fidelity Explorations
Dashboard
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 3 different view types: list, cards, and calendar.
Ultimately, we chose Option D.
- Option A (List view) organizes the meetings by type and chronological order, but having separate tabs prevents users from seeing whether meetings are happening at the same location.
- Option B (Card view) also organizes the meetings by type and day of the week. However, cards aren’t an intuitive way to represent meetings because they can become visually overwhelming. The most important elements — when and where the meeting happens — are not emphasized here.
- With Option D, a calendar displays all meetings at once, and can still distinguish the types by color-coding. Administrators can visualize all the meetings in one place without an excessive number of steps, filter by type/mode, and create new meetings.
- I chose Option D over Option C because having a smaller CTA allows for users to navigate the calendar by month
Creating a New Meeting
We also experimented with the flow of creating a new meeting: choosing between either a modal or 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:
- Continuous Context. A sidebar allows users to maintain total visibility of the calendar while creating a meeting. This continuous context can be crucial for users who need to refer to other scheduled events to avoid conflicts, providing an uninterrupted workflow and reducing the need for toggling back and forth between views.
- Efficient Use of Space. Sidebars use space more efficiently than modals. The modal could disrupt the workflow by covering a significant portion of the screen, potentially obscuring important information
- Fewer Clicks. Having a sidebar reduces the number of clicks or interactions required from the user compared to a modal that needs to be opened up
Viewing an Existing Meeting’s Details
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.
High Fidelity Explorations
Transitioning into high fidelity designs, we received specific requests from our partners for color scheme. They expressed that the overall branding of the platform should remain consistent with the main website (simple, black and white), but gave us the freedom to use a dark fuchsia as the primary color. We preferred the dark periwinkle that we were working with, but ultimately went with our client’s request because the fuchsia is used as a secondary color on the current website.
Exit Point for Creating a Meeting
We ended up choosing Option C. The back caret in Option A could be confusing, as “New Meeting” could potentially be understood to be what clicking the caret leads to. Option B’s cancel button was not ideal because it forced the user to scroll to the bottom to exit the flow. Option C’s X button clearly indicates an exit point to leave the Create Meeting Mode.
Calendar Meeting Blocks
A major design decision made in this stage involved the calendar blocks. We first decided on content requirements:
- Meeting name
- Time
- Location
- Calendar (AA/Al-Anon/Other)
- Type (Remote, In-Person, Hybrid)
- Zoom link
Our clients expressed that since this platform is essentially a room and meeting booking system, being able to filter by rooms, calendar, and meeting type is crucial.
We first needed to figure out how best to indicate a meeting’s calendar and type. I decided to use color to represent the calendar, an industry-standard calendar design pattern. However, we struggled to find a way to indicate meeting type, and came up with 5 different iterations:
A major issue with the blocks was keeping in mind the vertical spacing between each hour on the calendar and how that would limit block height. We did not want too much vertical spacing to accommodate for all the information on a block, as users should be able to at least see meetings during business hours (9am-5pm) without having to scroll.
- Option A went with a more implicit approach. Having a Zoom link, physical room, or both would indicate whether a meeting is remote, in-person, or hybrid. However, once the calendar is filled with meetings, users would struggle to identify meetings of different types.
- Option B utilizes tags to categorize different meeting types. Tags are more visible and explicit, but blocks would be too tall.
- Option C simply follows what the current website does: indicating meeting type in the meeting title. This is redundant because users already select meeting type as a property when creating a meeting. Moreover, as with Option A, it would be difficult to identify different types of meetings as they fill up the calendar.
- Option E uses icons to differentiate meeting types — however, we were unsure what the icon would represent a hybrid meeting.
Ultimately, we went with Option D. It solves the problem of block height in Option B by removing the row for Zoom links. We realized that adding the Zoom link in another row didn’t really serve much purpose because:
- The link isn’t clickable from the block — users have to click the calendar block first to view meeting details on the sidebar and click the link.
- Tags already indicate whether a meeting is hybrid or remote.
Calendar Daily View
Our calendar would also allow 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, on what to do if the user deselected one of the calendars with the sidebar filters. We considered options:
In this first option, all 3 columns remain on the page, and if a calendar is filtered out, its respective meeting cards would disappear. An issue with this is that if the user doesn’t notice that a calendar isn’t selected,
In the second option, a calendar column is removed once a user filters it out. The one concern about this was that we were unsure what the calendar would look like if all 3 calendars were filtered out (would it just be an empty screen?). However, we ultimately decided to choose this option and require at least one calendar to be selected at all times.
A Big Change
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 iterated further 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.
Reflection
This project was meant to last for one-semester, but since we made such a large change right at the end of our timeline, Katherine and I will be wrapping up designs with edge cases and a revised design system over the summer.
As designers who have completed several design projects in the past, we initially felt that while the project itself is very impactful, it wasn’t quite the challenge. However, little did we know, we learned a great deal from this last minute change…
ITERATE. ITERATE. ITERATE!!! (on a higher level)
We created a lot of iterations at a smaller level, focusing on the little details. However, we could’ve iterated more at a higher level and keep in mind the importance of not double-booking rooms.
We would like to thank our team: our PM and TL, and developers, for making this semester so enjoyable! Next semester, the Recovery subteam will be working on developing the frontend of the platform. We are very excited to see our designs come to fruition and for the volunteers at ICR to begin using the platform!
