Lab Reservation 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.

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

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.

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.