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.
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.
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.
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.
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.
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.
This is a student project created during summer semester 2014 as part of a course in Interface Design by Thomas Techert.
Prototype on GitHub