by Melanie Lindahl
Overview
At Texas Law, reserving rooms had been an email-based process. You emailed the person in charge of the room, and if that room scheduler approved it, they added your request to the room’s Outlook calendar.
While simple on the surface, this approach had drawbacks.
- Administrators spent extra time double-entering information into spreadsheets, databases, and Outlook, which inevitably created inconsistencies.
- Workflows for approving requests weren’t streamlined.
- Approvals lived in scattered inboxes without a clear trail.
- Requesters weren’t always certain whether their reservation had gone through.
It worked, but not particularly well. We needed an upgrade from a tired, manual system.
The old, email-based way of reserving rooms
Starting Over, Smarter
Two years before this project began, Texas Law tried adopting a third-party room reservation system. Unfortunately, the tool became misaligned with our need after the rollout and fell flat. We landed right back at square one: managing reservations through email.
This time, though, leadership set some parameters. We weren’t going to buy an expensive system. If we wanted a better workflow, it would need to be cost-conscious, carefully designed, and rooted in what our users truly needed.
This made the project more than just providing a tool. It was an opportunity to rethink the process itself and challenge long-held assumptions.
Users & Needs
From the start, it was clear who our primary users were: the administrators, or “room schedulers.” They managed spaces every day, kept the records, and bore the brunt of the inefficient double entry. Their needs drove the project.
Our secondary users were the faculty, staff, and students requesting rooms. Their role was simpler, but no less important. They needed a clear way to make a request and know what happened to it afterward.
When we spoke with both sets of users, they emphasized that:
- Administrators needed approval workflows. Room reservations couldn’t move forward without admin oversight.
- Transparency mattered. Both groups wanted a record of what happened to a request and when.
- Services such as AV equipment, extra chairs, and catering needed to be tied directly to room reservations, not requested in a separate system.
- Notifications were critical. Everyone wanted timely communication when a request changed status.
- Users needed to see room details, like seating, equipment, and possible room layouts.
In short, administrators wanted control, requesters wanted communication and clarity, and both groups wanted a system that was easy to use.
A Break From Our Regularly Scheduled Programming
Knowing we didn’t want to build a tool that integrated with Outlook (writing code for repeating events… eek), we explored lightweight, third-party products that integrated with Outlook and came at a lower cost than our previous system.
The options were limited. We found one product that came close to meeting our needs, but after testing, it became clear it wasn’t reliable enough. In the end, we set aside the idea of purchasing a new product and moved forward with building our own system. We had lost valuable time and now only had four months to deliver a tool from scratch.
The Wayward Path
At the very beginning of the project, we asked: Do we need to integrate with Outlook?
Backed by conversations with our campus tech community, we decided yes, we did need Outlook. Administrators lived in Outlook every day, so surely requesters did too, right? Without checking with users about how they used Outlook (spoiler: they didn’t), we assumed room reservations had to integrate with Outlook calendars to be successful.
The deeper we went, the clearer it became. This assumption wasn’t true.
We assumed users made use of Outlook’s room availability tool.
Once we committed to building our own tool, we circled back to users and asked about their Outlook habits in addition to noodling further about the integration. We learned that:
- Requesters rarely checked Outlook room calendars. Many didn’t even know they existed.
- Outlook event ownership created problems. If our system created the calendar invite in Outlook, the requester wasn’t recognized as the owner, meaning they couldn’t edit details or invite others.
- Campus-wide settings introduced barriers. We couldn’t limit reservations to Texas Law community members, which was essential for managing our spaces.
These findings were both surprising and freeing. Outlook didn’t need to be in the equation. Once we let go of the assumption that integration was required, new possibilities opened up. We could focus on building a reservation system tailored to the law school’s needs without forcing it to bend around external constraints. We still had to build repeating event logic, sigh, but at least it would be ours, not constrained by Outlook.
Our old availability calendar, brought to you by Outlook. Ouch.
Iteration Through User Feedback
User feedback shaped the system at every stage. We didn’t want surprises at launch, so we made sure testing was continuous and layered.
Stakeholder Meetings
We held regular meetings with administrators to understand how they wanted the system to work. These conversations clarified the workflows for requesting and approving rooms in addition to specific features that created efficiencies for administrators.
Requester Interviews
We also interviewed our “power” room requesters. They emphasized the need for clear communication: confirmation that their request had been received and reassurance when the room scheduler approved the request. Their feedback highlighted how important transparency was for the requester experience.
Prototypes
Early in the project, we created Figma prototypes and tested them with both administrators and requesters. This allowed us to confirm core workflows and features before writing any code.
A portion of our Figma prototype
In-Development Testing
As features took shape, we tested them in the browser with users to make sure the functionality matched their expectations. This approach caught potential pain points early, when adjustments were easier to make.
Pre-Launch Testing
Before rollout, we tested the system again with a wider group of users. This surfaced late-breaking needs, such as rooms that required overlapping bookings and the desire to search for room availability during a date range.
Lost in Translation
At times, abstract concepts led stakeholders to reverse earlier decisions or add new requirements later in the project. Thankfully, by keeping communication lines open, we were able to resolve those misinterpretations.
The Choices Behind the Screens
As the project took shape, we had to make dozens of decisions, small and large. Many of these decisions came directly from user feedback, while others emerged as we tested workflows.
Significant decisions included:
Room Requests & Availability
Could users book a room that was already reserved or even requested? Administrators decided no, overlapping requests created too much confusion. If a time slot was taken or requested, it was simply unavailable. However, adjustments were needed after launch when we were informed that particular rooms did require overlapping requests.
Room requests and approved reservations both block room availability
Classroom availability
Because we already had class schedules with dates, times, and room assignments, we needed a way to block those class periods without overloading the system. Rather than importing every class as a reservation, we chose to read directly from the class data tables, display those time blocks as unavailable, and not allow users to book that time.
Class time blocks appears alongside room requests; however, class times are pulled from another system
Changing Reservation Details
At what point could requesters make changes? Allowing edits mid-approval made the workflow far too complex. We limited changes to after a room scheduler’s approval of a request, which kept the process manageable for administrators.
Changes to a reservation can only occur after the initial request is approved
Deleting Dates from Repeating Events
We recognized that users might need to remove individual dates from a repeating event, which was mostly straightforward to implement. Adding dates, however, introduced complexities. To keep things sane, we allowed users to drop specific dates from a repeating event, but adding new dates would require a change request for re-approval.
Deleting dates from a repeating event
Rooms vs. Services
Room reservations often came with add-ons: AV support, catering, extra chairs, and so on. These “services” were previously tracked in separate systems like FileMaker Pro or Smartsheet. We brought them into the new system so services could live with the reservation itself.
Users can select optional services, like tables or A/V equipment, when requesting a room
Special Rules
Requesters didn’t know all the many rules surrounding rooms and services. Rooms couldn’t be booked during final exams. Some services required a specific amount of lead time. With feedback from administrators, we applied error and warning messages when users tried to book rooms and services under certain conditions.
Warning messages tell users of potential issues while error messages prevent users from requesting unavailable time slots.
Notifications
Users and administrators wanted emails at every stage of the process: requests, approvals, denials, edits, and more. We suspected the volume of emails might become overwhelming, so we built consistent subject lines to make inbox filtering easy. That decision paid off when administrators later asked to “tone down” the volume of notifications.
Requesters and administrators both receive email notifications when a request has changed
Each of these decisions reflected a balance: meeting user expectations while keeping the system lean and sustainable.
Project Outcomes
By the end of the project, we delivered a custom reservation system designed specifically for Texas Law’s needs. The tool streamlined the entire process:
- For administrators, it reduced duplicate record-keeping, attached services with room requests, and provided a clear approval workflow.
- For requesters, it offered a straightforward way to submit reservations, receive timely updates, and keep a reliable record of their requests.
- For both groups, it replaced uncertainty with transparency.
Most importantly, the new system restored trust in the reservation process. Instead of relying on scattered inboxes and disconnected records, administrators and requesters now share a common source of truth.
A requester’s workflow for requesting a room
Reflections and Lessons Learned
This project was as much about rethinking process as it was about building software. A few lessons stood out:
- Assumptions are costly. Our early focus on Outlook integration pulled us off course for months. User interviews showed us it wasn’t needed, and clearing that assumption earlier would have saved loads of time.
- Process problems need process solutions. Technology alone doesn’t fix broken workflows. The success of this system came from in-depth discussions with administrators to understand the root of the problems and find solutions that worked for everyone.
- Continuous feedback prevents surprises. Involving users at every stage, from prototypes to pre-launch testing, caught problems early and ensured the system felt natural on day one.
- Planning with flexibility is key. Late-breaking needs, like overlapping room ownership or multiple bookings for certain rooms, were inevitable. By designing with adaptability in mind, especially in our database structures, we were able to respond without losing momentum.
In the end, what started as an effort to replace an email-based workflow became an exercise in listening, iterating, and remembering to leave our assumptions at the door.