Prison Visit Booking
The success of the Visit Someone in Prison service meant that prison staff were dealing with a much higher volume of visit bookings than before. As such, the admin interface and tools needed to be overhauled in order to let the prison staff manage bookings as efficiently as possible.
Examining the existing interface, I identified a number of problems. Staff had difficulties with the layout of the page, the interface's lack of clearly defined sections, the readabilty of prisoner and visitor details, and the fact that some interface elements were hidden until their parent was selected.
ProcessIn discussions with the team's user researcher, it came out that the primary reason visits were rejected was because the prisoner had no visiting allowance left. However, the interface presented the booking slots at the top of the interface. As such, most staff checked to see if the dates and times were available before moving on to check the prisoner's details and visiting allowance.
With this (and a copious amount of other research!) in mind, I sketched out a number of potential solutions in my sketchbook. I eventually settled on the sketch below:
Because having no visitor allowance was a single point of failure for booking a visit, I placed it at the very top of the interface. I also created defined sections for the interface and specified new typographic and visual design styles for better readability and comprehension.
With the above sketch in hand, I sat down with the team and re-drew the sketch on a whiteboard (right). This allowed me to take the product manager and the developers through the design, step by step, to communicate my thinking behind the solution as clearly as possible.
Two days later, the front-end developer sent me a working prototype (below) which we immediately put into testing with prison staff.
User testing revealed that staff were able to navigate the new interface with no difficulty and were able to process visit bookings more efficiently than before.
In order to ensure that our solution was as robust as possible, I also developed another solution (right) that was to be tested at a later date. The slots for the visitor's dates are more clearly identifiable and the visitor information is easier to understand. Additionally, interface elements (such as banning a visitor) are no longer hidden and are built into the visitor information section.