Austin Public Library Meeting Rooms

Designing and building an end-to-end meeting-room reservation prototype for Austin Public Library

2026
Austin Public Library meeting-room search results showing real branch availability beside a map of Austin

As a volunteer with Open Austin, I partnered with the Austin Public Library (APL) to help them redesign the library’s web presence. The engagement began when APL’s new UX designer reached out to Open Austin for help and it seemed like the exact kind of project my skills would be well suited for. The website team was just her and one developer, who wanted technical peers and guidance toward modern web practices.

After a January 2024 goal-setting workshop surfaced room reservations as the first service to tackle, we set to work with our motley crew of part-time volunteers. By July 2026, the Open Austin APL team delivered a working end-to-end prototype built in the open on the library’s own GitHub organization: search real inventory, compare branches on a map, book a slot, add a confirmed reservation to a calendar, and cancel functionality.

The Existing System

The library’s current reservation flow is managed via Drupal and displayed to the users using vanilla HTML, CSS, and JavaScript. Due to the manual JavaScript wiring with no true relational database or locks on the backend, conflicting requests could claim the same room and time slot, requiring staff to reconcile the problem manually when multiple people showed up for the same reservation.

The earlier Austin Public Library team documented a direction in the Rooms repository: separate the frontend from the backend, prioritize accessibility, and build something sustainable enough for the library to keep running. Those recommendations became the prototype’s constraints.

Approach

We made a series of decisions along the way as we discussed the prototype with the library team in the lead up to development:

  • Use their existing design system: The UI is built on the US Web Design System (USWDS) via react-uswds. Rather than inventing something new, we decided to reuse the design system they already had in place and were familiar with. With it came the bonus of WCAG 2.1 AA accessibility standards. I bridged the USWDS design tokens from Sass into Tailwind with a small plugin so the team had access to utility styling and intellisense editor features, while adhering to the design system itself.
  • Back the lifecycle with server routes: Search uses a server-side data loader, while booking and cancellation use server-side form actions; confirmation renders from persisted reservation records rather than client state.
  • Combine real sources deliberately: The prototype makes requests to the same live room inventory and branch data APIs that the existing room booking site uses, combines them with encoded operating hours and live upstream reservations, and derives availability at query time. libSQL via Drizzle stores the prototype’s own reservation records, while actual branch locations are displayed visually via Mapbox.

The Prototype

The Austin Public Library prototype homepage separates shared learning rooms from meeting rooms and explains who can use each

The first decision is explicit. Individuals and small groups can reserve a shared learning room; larger, non-commercial groups can request a meeting room. Eligibility is visible before either path asks for information.

The booking flow we built out for the prototype was designed entirely in Figma by the Open Austin UX designer on our team, Jerri Zhang, which made it easy to follow her UX intentions when writing the code for the actual prototype. The flow covers the entire reservation lifecycle:

  • Search by room type, date, duration, capacity, and amenities, with real branches and availability beside a map
  • Review and submit with the relevant policy rules inline. Shared learning rooms can be confirmed immediately; meeting-room requests remain clearly marked as awaiting staff approval
  • Export confirmed bookings to a calendar as an .ics file
  • Cancel from the reservation record, returning the slot to availability

A completed meeting-room request form using synthetic Open Austin demo details and a required policy agreement

The review step keeps the reservation facts, eligibility rules, and contact fields in one place. It does not imply that a meeting room is confirmed: that happens only after staff approval.

The live prototype confirms that a synthetic meeting-room request was submitted and is awaiting staff approval

These live screenshots use synthetic contact details and a demo request.

My Roles

Over the two years it took to complete this project, I held a few different roles and worked with a rotating set of team members. My two primary roles were:

  • Product Manager: At the beginning, I managed stakeholder relationships, understanding the needs at APL and translating those into a set of shared goals. From there, I developed those goals into SMART Goals and farther into a concrete product vision. I worked again with Liani to develop a roadmap and high-level set of epics, which we reviewed again with the stakeholders at APL, before I started writing user stories and acceptance criteria for each epic as we begun developing the prototype. From here, my role changed as we brought in another volunteer to serve as product manager while I transitioned to…
  • UX Engineering Lead: As the UX Engineering Lead I worked closely with both our UX Designer, Jerri, and the rest of the developer volunteers at the team (who rotated over the years and ranged from 2 to 4 other people) to lead the development effort of translating the UX design and interactions into a functional prototype with which we could user test. Most of the hands-to-keyboard work here involved translating the Figma designs and interaction specifications Jerri had provided for us into a React Router application, which involved a combination of prompting an LLM for the boilerplate heavy work (building API clients, scraping existing, undocumented API contracts, etc.) necessary for this prototype and handtyping the React code for the UI to match the designs pixel-to-pixel, which turned out to be fairly easy thanks to the combination of the design system components we had access to and the Tailwind CSS utility classes I was already very familiar with.

The Timeline

From start to finish, the entire process took about two years to complete, without about a year total of development work. Coordinating with the library folks at the beginning to align on technology and practices (assuming they might want to adopt our development practices in addition to the design and UX of the prototype) took a bit of time and once that was settled, writing the initial user stories and coordinating the team of developers took some time to get off the ground as well.

The rest of the time was mostly consumed by other obligations or outside time conflicts that naturally came with the volunteer aspect of the work. Had we been able to work on this project in a full-time capacity, I’m confident — based on the other work I’ve done — that we could have produced a prototype in a matter of weeks instead of a matter of years.

Status

The prototype is live on Railway and our UX designers and researchers are in the process of writing user testing scripts for individual interviews with real library patrons to get feedback. The code, tests, backlog, planning board, user stories, and changelog are public in the APL Innovation Lab’s GitHub organization and repos.

The prototype is not a drop-in replacement for the library’s current service, but after we’ve gathered user feedback, we plan to discuss any new technical constraints with the library and help them understand what it would take to implement the prototype’s UX on their production servers with their existing stack. Known gaps we left unimplemented to get the prototype out in a reasonable amount of time are visible in the backlog, including overlapping reservation windows with different starts, reservation-frequency enforcement, and unfinished policy content on the homepage.

Try the prototype →

View the code on GitHub →