OPMS is an interface for managing a hospital’s surgery department.

Project Description

As Interaction Designers we live in a world filled with beautiful apps and software packed with “delightful details”. It is easy to forget that this doesn’t reflect the realty for many people. Especially in work environments there are many outdated, complicated interfaces, designed without asking the actual users about their workflow.

For our project in Interface Design we decided to challenge ourselves and create a data heavy, workhorse interfaces whose power users work with it up to ten hours a day for several years. The topic of the course was medical interfaces and so we set out redesign the interface of the software that is used for managing a hospital’s surgery department.

Research

The current interfaces uses scrollable tables to represent surgeries. The data of one surgery is spread across multiple screens in no logical order. This is one person’s workspace!

To get the know the real user’s workflow we spent two days with the surgery management team of the university clinic Tübingen. They are responsible for one of Germany’s largest surgery centers and were kind enough to explain their tasks and needs to us in detail. We also observed them during their actual duty and asked them to fill out a questionnaire.

We learned a lot about the vast amount of data needed and which parts of it are actually important in everyday use. We followed through the process of a surgery from its commission to its closure and listened to what the users believed to be the best possible flow of work.

The Interface

The interface is optimized for working on a large screen, but it is fully responsive.

Our result is an interface that doesn’t try to be very delightful or intuitive (the users don’t care about either of those), but one that is based on the actual needs of the users. It is visually reduced and seems simple, but is rich in functionality.

We only show the data that is necessary but always keep all data in reach in case it is needed. The user is guided and supported but not constrained or patronized. The interface is designed to be easy on the eyes and very clear about timeframes, states and the relationship between different parts of data. But just because it’s utilitaristic doesn’t have to mean it isn’t nice to look at.

Overview

We decided to encourage the use of trackpads: They are reliable and can be easily cleaned.

The main part of the interface is the overview: It shows a complete day across all surgery rooms in the style of a calendar. The surgeries are presented as little cards fitted with the most important information and a color coded status. They can be freely moved around via drag and drop and be extended or shortened. If a card is clicked the column slides open revealing more detailed information the surgery.

Detail View

Multiple detail views can be opened simultaneously to compare the details of surgeries.

In the Detail View the entire data of one surgery is shown in tables that can be edited individually. The most important part is at the top: a bar chart that represents the current state of the surgery and gives information about the prior timestamps. The next state can be started by one click.

Adding a surgery

Instead of the chaotic and irreversible process that user had to follow in the current software to add a new surgery, we keep the process linear and allow them to jump back the previous steps to correct data any time. All data that can be gathered is filled into the corresponding fields when the user selects a patient.

Once the surgery is created its card pops up in the column of surgeries that have not been assigned a room and a time yet. The user can drag and drop the surgeries from this column into the calendar view – the surgery rooms that are better suited (because of less planned surgeries or special requirements) are highlighted while dragging.

Bar chart

On mouseover the data of past stages is shown.

A bar chart that uses a color coding system to show the state of the surgeries in all rooms is one of the most important tools for the surgery management team: It is displayed on the walls of the floors and is used in daily meetings to predict which surgeries have to be delayed.

Since the one in use was programmed under instruction of the team we didn’t have to change much about the functionality or structure. We just redesigned it to be more clear and easier to understand. We kept the existing color code but chose new shades that have a higher contrast. We also implemented the bar chart natively into the system.

Process & Technology

My focus in this project was on research, process design and prototyping. After we finished our wireframes together my team partner went into visual design while I built the prototype, integrating and refining her static designs as we went.

We worked with several research techniques such as interviews, observations and a questionnaire including a semantic differential. After creating the wireframes and the actual design we built a high-fidelity web prototype in HTML, CSS and JavaScript. That way we were able to test the interface and present it so that people could actually explore how the information is shown.

Meta

This is a student project created during summer semester 2014 as part of a course in Interface Design by Thomas Techert.

Team partner

Anna Foltinek

Links

Prototype on GitHub