Steve Barzilay TalGraphic & UX/UI Designer

All work

08 / 09

sidurofe

Shift management for doctors

A browser system for managing a work schedule, with interfaces for the doctor, the shift lead and the administrator.

Browser applicationThree kinds of userPrototype

Where it sits in the mixA bit of everything
The doctor’s home screen in the mobile app: a monthly hours target with a progress bar, the next shift and quick actions.

Doctor · mobile

The shift lead’s screen on the desktop: a timeline of the shifts by doctor, with filtering by speciality and type of work.

Shift lead · desktop

The administrator’s screen on the desktop: a weekly board of 24 hours a day, with the staffing requirements and the scheduling in each hour.

Administrator · desktop

The work schedule in the doctor’s, the shift lead’s and the administrator’s interfaces.

Note Every doctor and account on the screens is invented: the prototype’s demo data. Sending e-mail and exporting files are still simulated in the prototype.

The animation has no sound.

My contribution
Product specification, interface design and development with the help of AI tools.
Discipline
Creative Labs · UI/UX
Product state
Prototype · Private demo

01

The challenge

A work schedule for a medical contact centre that operates around the clock has to connect the staffing requirements, the specialities and the hours in which the doctors can work. At the same time, quotas, shortfalls and swap requests have to be tracked, and doctors have to be assigned to the right calendars or queues.

Everyone who uses the schedule has a different need: the doctor chooses hours and follows their own shifts, the shift lead manages the shift, and the administrator is responsible for planning and for changes in the schedule as a whole.

02

The principle

One system with three user configurations, built around the way the service works. Doctors choose hours from the open shifts, follow the hours target and submit swap requests. The shift lead sees the schedule, records events and checks availability for reinforcement. The administrator defines the staffing requirements, manages the assignments and approves swaps.

The scheduling is done by human choice, while the system calculates occupancy, shortfalls and fit in the interface.

03

Interface and user experience

For the doctor, an interface designed mainly for mobile, with the next shift and choosing hours in three steps. The shift lead works with a timeline and filtering by speciality and type of work. The administrator gets a weekly board of 24 hours a day, in which a shortfall and a surplus in the staffing are shown in colour and in numbers.

Options that are not available come with an explanation, so it is possible to understand what limits the choice and to continue from there.

Choosing hours

  1. The open-shifts screen in the doctor’s app: a strip of days with one day chosen, and below it the two open shifts of that day, with the number of free hours in each.
    Choose a dayFrom the days with open shifts, you choose the right day.
  2. An open shift opened for choosing: the possible start times as buttons with one chosen, and lengths from one to six hours. The two longest lengths are blocked, and a line below them says they exceed the daily quota allowed, ten hours.
    A start time and a lengthYou open a shift and choose a start time and a length. A length that is not available is blocked, with an explanation of why.
  3. The open-shifts screen after the choice: a green message that the shift was registered successfully from 16:00 to 19:00, and below it the shift divided into the free hours that are left.
    The shift is registeredA confirmation appears, and the hours that are left free in the shift are shown again.

Choosing hours from the open shifts.The mobile screens in demo data. An option that is not available is blocked, with an explanation beside it.

A close-up of the administrator’s requirements board: the last seven hours of the day against five days, with the required number in each cell and below it the existing scheduling by speciality, in the colour of a shortfall, sound or surplus, and under the table a legend of the three colours and explanations of the marks.
The staffing requirements against the existing scheduling.A close-up of the administrator’s requirements board, in demo data: a legend and numbers inside the cells. Each cell shows the number required and below it those assigned out of those required, by speciality: this is how you see at which hour and in which speciality staff is short.

Swapping a shift

  1. The swap-request dialog in the doctor’s app: the original shift, 08:00–14:00 on Wednesday, the choice of the range to swap, from 11:00 to 14:00, and the button that sends the request.
    The doctor asksA doctor submits a swap request, and chooses which part of their shift to hand over.
  2. The swaps screen in the app of another doctor: an open request for Wednesday, 11:00–14:00, in paediatrics, with no requester’s name, and a button to volunteer for the shift.
    Another doctor volunteersThe request is open to volunteers, with no names, and another doctor of the same speciality offers to swap. After volunteering, it waits for the administrator’s approval.
  3. The swap-requests screen of the administrator: two requests awaiting approval, each with its checks (speciality match, hour quotas, personal availability, overlap with an existing assignment) and approve and reject buttons, and below them a history of decisions. In the first request one check failed, and its approve button is blocked; in the second, the request of the story, the checks passed.
    The administrator decidesThe administrator sees the request and its checks, and approves or rejects. A request that fails a blocking check, like the first one here, cannot be approved.

A swap request, a volunteer and an approval.A prototype demonstration in demo data: the move between the screens of three role holders. Sending e-mail is still simulated.

04

Technology

Next.js, React and TypeScript, styling in Tailwind CSS and an SQLite database on the server. The prototype includes sign-in, basic permissions by role and data saving. Logic shared by the interface and the server gathers the schedule updates; some of the scheduling rules still need to be fully enforced on the server.

05

Information security

Passwords are not stored as plain text. The server limits actions and information by role, so a doctor does not receive the personal details of other doctors. Disabling an account also blocks a user who has already signed in.

Before a pilot, the authorisation and data-integrity checks on the server must be completed, sign-in attempts limited, and the information exposed to the shift lead reduced. Encryption, backups and the audit log also have to be completed.

06

State of the project

A functional prototype that can be demonstrated with demo data. To start running it in the service itself, the enforcement of the scheduling and swap rules on the server has to be completed, saving and synchronisation have to be made reliable when several users work at the same time, and the handling of dates and time zones has to be completed. Sending e-mail and exporting files are still simulated, and they have to be completed alongside notifications and information protections.

07

More about the system

  1. Doctors choose hours and the administrator manages the requirements and the assignments. The system helps by calculating occupancy and shortfalls and by presenting the scheduling options. It currently has no engine that creates a schedule automatically.

  2. Hour quotas, requirements and availability can be changed in the settings. The two main specialities and types of work are currently built into the logic, so adapting it to a different structure of queues requires development. The system is also not yet meant for managing several organisations in one installation.

  3. Each role has its own interface. The server limits actions and information by role, so a doctor does not receive the personal details of other doctors. Before a pilot, the authorisation checks on the server still have to be completed and the information exposed to the shift lead reduced.

  4. A doctor submits a request to swap a shift or part of it. The request stays open to volunteers, with no names, and another doctor offers to swap. The administrator sees the request and its checks and approves or rejects; a request that fails a blocking check cannot be approved.

  5. Not for real yet. Sending e-mail and exporting files are simulated in the prototype, and they have to be completed alongside notifications and information protections.

  6. Not yet. It is a functional prototype that can be demonstrated with demo data. To start running it in the service, the enforcement of the scheduling and swap rules on the server has to be completed, saving and synchronisation have to be made reliable when several users work at once, and the handling of dates and time zones has to be completed.

The full presentationFor development, information systems and management: all the detail - how it is built, what was tested, what is missing and from whom.