IXD303: Week 6 Reflect – Design Sprints

This week we worked in groups on a design sprint. Usually, this would take place over the span of 1 week, therefore, doing it in 5 hours was going to be a challenge.

How might we ease the pressure on accident and emergency departments?

This was the problem we were given. It is an issue that is much needed to be solved so we were up for the challenge. This is an example of the process of the design sprint and what the layout of our day would be:

  1. Understand

The first step was understanding the problem. In our group, we began to research different areas of healthcare including waiting issues, what stresses patients and staff, information patients may need, and reasons why people go to the hospital. One thing that stood out to us was the number of people who go to the hospital unnecessarily.

Affinity mapping

Next, we took post-it notes and began brainstorming areas we can try to improve with design. This included “how might we” statements such as:

  • How might we: Save time.
  • Reduce loneliness
  • Reduce stress/anxiety
  • What information do patients/health professionals need?

After discussing these, we voted on which area to focus on. Together, we decided to solve the issue of having too many people in A&E unnecessarily and the long waiting times. We decided on this because, through research, we found that thousands of people who attend A&E did not require any medical attention or treatment. This of course wastes the time of staff that they could be spending on those that need it. It also means waiting times for patients are very long. Therefore, we wanted to solve both these issues in one app.

Empathy map

The next step was to create an empathy map to get into the mindset of our users and focus on their needs. We wrote and discussed what they say, think, do, and feel.

I found that thinking like your user makes you imagine what it would be like in their situation and helps uncover what they need at that moment. Our users may think that they don’t want to go to the hospital because they would be waiting there all day. Another concern may be catching an illness from someone in the waiting room. These things may make them feel anxious, stressed, and may even worsen their condition. We thought that this could lead to people not going to the hospital at all, even if they really need to.

User journey maps

Our user journey map included the user’s actions, questions, happy moments, pain points, and opportunities.

From this, we learned that many people may not know if their issue is serious enough to go to A&E. Therefore, part of our app could be a self-assessment to help people figure this out. This would prevent unnecessary visits and give people alternative options.

We thought of lots of pain points when patients are waiting. For example, waiting while in pain is an unpleasant experience, their wait time may increase, or their anxiety might be heightened. Therefore, taking waiting out of the equation would take away these issues.

  1. Define

We sat together as a team and discussed the area we wanted to focus on and how we were going to solve it. Our idea was to design an app that allows users to carry out a self-assessment to guide them on whether they need to visit A&E. The app would also place patients on a digital waiting list so they don’t have to go to the hospital until they are ready to be seen.

  1. Ideation

To come up with as many ideas as possible, we all did some quick sketches. Here is mine:

We then pitched each of our ideas to the group. I found this very useful as it shows you different perspectives. It also enabled us to take all the best ideas and put them into one app.

Here is our final solution sketch:

These sketches show what screens the user would encounter if they had an injury. They would give their type of injury, their pain levels, the option to add an image, etc. We tried to make this as short and simple as possible as the user may be in a lot of pain. All of these answers would be recorded, and health professionals would have access to them. This way, they already know about the patient and what they are dealing with before they get to the hospital which would save time.

The accident is then registered, and the patient is given an action plan. If their issue is serious, they are told to go to the hospital. If not, they are given other options to take into consideration e.g. visit your GP. The user then gets put in a queue and is given an estimated wait time. This prevents them from having to wait in the waiting room for a long period of time. Once they reach the top of the queue, they will get a notification with information about where to go and what doctor will see them.

 

The next two steps would be to decide and prototype. However, we didn’t do these today. Our idea was well-received, and I think it is a good solution to the waiting issue A&E has. I really enjoyed getting an insight into what is involved in a design sprint as I will be using these methods in the future.

Leave a Reply

Your email address will not be published. Required fields are marked *