Lab Reservation System

Client: Impinj

This was an independent project.

Duration : 4 weeks sprint

Process: Research, Re-design, Iterate, Hand-off and communication to delivery team.

My Role: I was solely responsible for the entire process mentioned above.

Tools : Photoshop, Sketch, InVision.


This is a lab equipment reservation system for engineers to schedule and run tests on shared test equipment. This system can be accessed via APIs or through a basic HTML page. The goal of this project is to build a powerful and better user interface for this system.
Some of the challenges in this project are:

  • Lot of RFID related technical jargon to learn and comprehend.
  • Understanding how the current lab reservation system works.
  • Varied number of use cases (API vs UI)
  • What features the users currently like the most?
  • How to help engineers in running their tests fairly quickly by optimizing the current reservation system?
  • Understanding the problems faced by the engineers in using the existing system ?


During the research phase I explored the following:

  • Understanding how the engineers use the current reservation system.
  • Identifying missing features.

Project Goals:

  • To empower more Impinj employees to use the reservation system to run their own tests.
  • Improve the experience for current and prospective users while preserving its value as a work tool for the team.

Current Home Page

Current Details Page

Current Details Modal

What's working in the current app?

To find what’s working and not working, I interviewed 6 engineers.

  • To run tests against a reader, the engineer has to reserve a reader that belongs to the correct reader family, model and hostname. To make the selection easier, each type is given a test fixture name. example name — “awesome-lily”. The engineers were able to reserve a reader by remembering the test fixture name.
  • The engineers were able to set a time for their reservation.
  • The reader reservation releases automatically once the time expires.

Areas of improvement in the current system:

I did Heuristic Evaluation for the current system. A few things to highlight:

  • Visibility of the system status
    • The current UI shows if a reader is available or not. But the status is not highly visible. There is no significant difference between “Available” and “Unavailable” states.
  • Match between the system and the real world
    • IP address is not a very user friendly choice for naming testers. Using a friendly name instead will be more easier for the users to remember.
  • User control and freedom
    •  There is no "undo” action available in the UI. There is no fallback or restore to default available for a reader.
  • Consistency and Standards
    •  There is a disconnect between what is in the page versus default values.
  • Flexibility and efficiency of use
    •  Currently, there is no easy way to search or find the necessary reader. The engineer has to go through the entire list to find the one needed.
  • Aesthetic and minimalist design
    •  The current UI has most information needed by the users, but is lacking the aesthetic and minimalist design.

Scope of work (Research Summary):

  1. Search / Filters / Sort:
    • Add search / filters to the home page. This will help testers to find the right reader fast.
  2. Release / Queueing:
    • Change the button state to release once the reader is reserved. Queueing option for testers to make request to wait on particular reader.
  3. Reservation Dialog:
    • Add filters for reader network, reader power, beaglebone network, reservation minutes and usage description.
  4. User sign in:
    • Sign in options for all testers.
  5. Notifications:
    • The notification icon should have the following options:
      a) Readers reserved b) Extend the reservation time c) Pending requests for reservations.
  6. History:
    • Show the history of the readers and the tests currently running.


The design process included the following steps:

  • Userflow.
  • Sketching.
  • Wireframes.
  • Usability Testing with clickable prototype.
  • More iterations of the above and refining the final design.

User Flow

User Testing, Iterations, & Process

In my initial design, I came up with couple of ways to make a reservation.

  • Make a quick reservation on a reader that they are very familiar with.
  • Provide filters and options to search and schedule tests.
  • Based on user research I eliminated option (a) because it was confusing to the users and they felt they missed context.

Lesson learnt: “Multiple ways to achieve the same task is not always useful to the users. It confuses than helping them.”

V1 : Quick Reservation

"Quick Reservation" button at the very top to help users reserve a test fixture quickly. Turned out to be confusing.

V2 : Filter Options

Filter options to find the right test fixture. Users found it very useful during usability testing.


Final mockup of the home page.



I added a quick filter component to ease the process of finding the right reader. Such a filter can scale when many number of resources are added. I added notification for when the reservation ends. This will help the engineers not to hold a reader even after the reservation is done and also make it available for the next engineer waiting on them.

Next Steps

During the research phase, I was exposed to two themes. One being, the current UI is not helping the engineers to find a reader quickly and allows bad practices like keeping the reservation on a reader for infinite number of minutes. Second, improving additional functionalities similar to what the API provides. The following were identified to be included in the v2 of the project.

  • User Login — this will help adding next set of features personalized to the user.
  • Notifications — adding notifications like frequently reserved reader, history, reservation related notifications, etc.
  • Queueing on readers — this helps the engineer to request a particular reader already in use.
  • Extending the reservation time — this feature helps the user to extend the reservation time when they find that their tests are not going to end soon.

User Login

Home Page

Notification window expanded

Profile window expanded

Queuing on Test Fixture

Call to action change of state