Case description:
Our requester – AskCody – have created a case, on the hunch that we within the nearest future, will be witness to a change within the way the hospitals are run. With the arrival of the so called “Super Hospitals”, the patients will have to adjust gravely to a new system – that according to askCody, will drastically degrade the patient care, and the perceived experience of the entire trip to and through the hospital. These problems will be in direct relation to changes with less room pr. patient, and in the end, less time pr. patient. This includes fewer bed places, waiting rooms and the time the doctors have with the patients, because the doctors will have to be more effective with their patients.
The systems within the current hospitals, are not ready to handle the logistical trouble this is going to cause, and the patients will therefore experience a severe degradation of the care, they might feel entitled too. The staff is already very busy, which means that the logistical trouble and patient care, would be unlikely to get solved by it self, with more man hours. Any time used to try and solve these issues, will come directly out of the time, that they could have spent helping patients, and will furthermore decrease the possibility for good patient care.
It therefore seems like obvious to try and solve this issue with automated technology.
Which is why askCody have asked us, to create an intelligent queue system, that can handle the problems that we are currently having, as well as the ones we are going to experience soon.
To get some insight with the case, we have made contact with IdeKlinikken, to gain an important insight in how the system works at the present time – in this case within the emergency room.
Group participants:
Lasse Rasmussen
Birk Thisted
Camilla Christensen
Stefan Larsen
Gabriel Alexe
Konceptvideo:
Designprocess:
Method: Object theater
How it worked: Fairly good by opening other scenarios than the ones we focused on. At the same time the limitations in the insight were so limited that not all were equally useful.
How to communicate: AskCody gained the insight by our presentation without getting told how these were obtained.
Method: Design service cycles
How did you use this method: We used the method for discovering the actors involved in the process, from when an injury occurs till the finished and treated result. By mapping out these actors involvement it was possible to gain the needed insight in to the area we are working in without ourselves actually experiencing it.
How it worked: This was a beneficial method for uncovering the aspects needed in order to formulate an area of interest. The problem the group faced before using this was that the area we were working on was restricted and the problem not documented, at least not available to us. After mapping this and triangulating the results with both experience from group members that themselves had tried the process and an employee at Ide klinikken.
How to communicate: Askcody gained insight in this method by being given some sort documentation that the hypothesis speculated in by AskCody themselves. At the same time the insight we gained through the above mentioned triangulation were passed on to the company.
Method: Design fiction
How did you use this method: We used the method for discovering the actors involved in the process, from when an injury occurs till the finished and treated result. By mapping out these actors involvement it was possible to gain the needed insight in to the area we are working in without ourselves actually experiencing it.
How it worked: The idea of the method was actually more helpful to the project than any actual steps from the method. By ideas generated from this method is transferred to the snippets section, and any parts of the methods that were used but not helpful have been removed during this process.
How to communicate: Through the snippets we can generate a complete sketch for the company in the final week, at the same time the company can come with ideas and or corrections at the next meeting.
Method: Storyboard
How did you use this method: Going from observing the problems the storyboard technique offered an idea process where the group individually could present their version? When generating the different problems the group was able to discuss which problems that could be evaluated and investigated further, thereby ensuring the highest possible fit between the groups observations and Ask Cody’s expectations from the collaboration.
How it worked: When needing to visualize different problems and thereby also emphasizing different solutions for those problems, the storyboard offers a reasonable process of achieving that. When the different problems sketched by every group member was presented the group easier could choose which problem were more critical and from this, be able to work on the best solutions for this.
How to communicate: AskCody was presented with the video sketches generated by using the chosen storyboards, this lead to a specific problem the group could generate ideas for solutions to.
Video sketching:
Throughout this workshop, we have used several methodical tools, with the purpose of processing our problem. The task at hand, was to design a queueing system, that can solve the issues that will exist in the future within the hospital service.
Our requester has a focus on the patients experience, and improvement thereof, and the queue is meant to somehow enhance patient “happiness”.
In our analysis of the problem, we have identified, that time is the key factor determining if the patient will perceive the experience as either good or bad. There is several factors that can be enhanced within the queue, that can somehow improve the actual time the patient have to wait, but the improvement here is minimal, and in the end finite. The key part is therefore perceived time, from the patients point of view. Our choice of focus is to work on the information, that the patient is presented with. This is because our initial analysis showed that this information was essentially not present, and that the presence of this information in it self, potentially could improve the experience of the patient. Knowing that our prototype will mainly be about the nature of the information to show, when and where?
Due to the nature of our problem, that has its root in the future, vi have used a technique called design fiction to help us visualize and understand our scenario. This is necessary because, we are not able to test the settings of the scenario, in any existing environment. The environment does not exist, and we therefore need to predict problems, that will happen within this future hypothetical environment. Since it is not possible to measure, or observe, the problem, we need to somehow act the scenario out, to make the problem relatable and understandable for both us, and others. For this we used a technique, within design fiction, called design oriented research. With this technique it is possible to simulate an environment, where in we can speculate about the nature of the problem, and therefore solutions as well.
To help us process the problem, we have chosen to visualize the environment through a drawn stop motion video. The advantage of this method, is that our design fiction is kept very low fidelity. This means – according to Roger, Sharp & Preece (2011) – that the viewer of the design fiction prototype, will stay more open and critical towards the product. This is essential, because we with our design fiction, are working on a problem, that is based on our observations and assumptions, as well as our requesters. It is therefore necessary to stay open to the problems that we can determine through this processing, as we are not able to guarantee that authenticity.
Through the scenario, we get an opportunity to design communication platforms – as well as technologies, that can handle the many different problems that we determine to cause issues with the patients experience.
The intention with the entire design oriented research, is therefore to outact the environment, so that we have to tools to understand the process, and what imagine we could do to prevent it. This is ofc. not a method that shows the complete nature of the problem, more like an insight. There is therefore the possibility that several issues will go unnoticed, until it is possible to test it in a more complete environment.
The scenario we have created, takes ground in the experience of one specific patient, which we have named Mr. Smith, we will then guide him through the process of booking a slot for the emergency room, and then simulate, what happens next, and how could this be handled? Is is important to know, that this is not necessarily pain free for the patient, and the video is just one example of how to do it. Also in our case, we are trying to solve the problem, through more information.
The entire story, is of a patient, that gets hurt, and contacts the emergency room. He then goes to the emergency room, to get treated. In our case, he will have to wait, because there are patients more important than him, and in the end, he will go home. This scenario is not uncommon, as this happens to up to 8% of all the people who enter a line – in this case the numbers are from the emergency room in norway.
The entirety of the scenario, can be tought of as one, but we are able to devide it up into three pieces, as to best handle the different problems in the specific moments. This is because we in our initial, analysis have determined that the problem with the information can be divided into several catagories. We have chosen to simplify the information between either: “Need to know and” “Nice to know”. Also if the patient is present or absent at the hospital. These two catagories define how we determine to handle the different scenarios, and what information is important to show, to change the experience of the user, and in the end, give them the information they need to make well informed choices.
Videosketch #1
This video shows our patient getting hurt, and going to the emergency room.
In this video we determined, that the information needed when Mr. Smith is home, is completely different from what he needs to know when he is present. We decided to alow him to join the line from home, so that he didn’t need to leave to the emergency room right away. In this way, we could ensure that he didn’t have to wait that long in the waiting room, so when he decided to leave, he had already been in the line long enough, to be placed high in the hierarchy. The information he needed to make this informed choice, was initially how many there were in line, and if they were busy. But we have later determined that this needs to be improved upon, to better enable the patient to arrive when he needs to.
Videosketch #2
This video shows Mr. Smith waiting in the waiting room, this time we introduce alot of emergency patients that will push him down in the hierarchy.
Normally this information is not shown, so this video gave os the opportunity to play with a what if scenario, where we could act out the consequences of what could happen, if the patient knew is approximate position in the queue, and what would happen if he got pushed down. This video illustrates, that if the information is known, it is also important for the patient, to know if there are big changes in the schedule. This is because the sudden change in wait time, would be inexplicable if they do not receive extra information that explains the situation. The marriage between info screens and handheld information, gives us the opportunity to both deliever the need to know information, that is possible to deliever to everyone without sharing personal information. But also gives a personal hotline, where we can give a more personal connection, that will handle the bigger issues within the information. Like: “yes, you got pushed down, but we have not forgotten you”.
Videosketch #3
This video draws a scenario, where our patient have waited to long, and now wants to go home.
This would normally be discouraged by the patient himself, if the patient were uncertain if lost his place in the line. With the possibility of the personal information gateway, the hospital can tell if the patient leaves, and actually ask him, if he wants to leave the queue. This way the patient won’t have to fear if he is till in the line, and the hospital, will know if they have a patient that intents to come back tomorrow. This opens up for several improvements within the queue, as this information is key to determine if they are busy or not.
All in all, the design oriented research has given us a lot of insight, that enable us to go even further down within the problems of this specific case.