A set of apps to improve communication between mothers and midwives at the maternity ward.


19. April 2021 – 23. May 2021

Project Type:


My Role:

User Testing


Stork is a set of niche apps aimed to be used at a specific maternity ward in the local hospital. Stork’s main promise is to improve communication and information flow between the midwives and mothers. Stork allows mothers to:

  1. Learn more about the protocols and process they need to go through before they can leave.
  2. Easily manage and schedule their time at the maternity ward.
  3. Communicate with the midwives when they’re not around.

Stork also helps midwives have more control over their schedule so they’re more effective and waste less time.

Target Audience

  1. Midwives
  2. Women who have recently given birth.

Design Process

  1. Empathise
  2. Define
  3. Ideate
  4. Prototype
  5. User Test

The Challenge

This concept sprung from asking a simple question:

How can we ensure that mothers feel supported at the hospital after childbirth and what could be done differently at the hospital to ensure that?

With that in mind, I conducted seven in-depth interviews with both mothers, fathers and midwives at a maternity ward to find out what, where and why things go wrong.

Lack of information. Poor Communication.

The interviews revealed several problems at the maternity ward. Most of them come down to two very simple things. Lack of information and poor communication.

Here are the main findings condensed into two problem statements based on the 4W’s that go hand in hand.

The midwives at the maternity ward find it difficult to plan and schedule their day as it is up to the mothers to decide what they will do at that certain day. This results in a lot of confusion and wasted time planning for things that won’t happen. Our solution should deliver an efficient way to get an overview of what needs to be done and when.

The mothers at the ward feel like they’re not well enough informed of why they are there. This results in them not knowing it’s up to them to decide when they want to complete the procedures they are there to do. Our solution should let mothers know why they are there and let them select when it is an appropriate time to do the procedures.

Potential Solution

After an intensive ideation session with a midwife we came up with a potential solution to the problem. A set of apps to be used at the maternity ward. Similarly to Uber with its Rider and Driver apps, Stork has two different apps that work together. One is meant for the midwifes to allow them to manage and communicate with all mothers at the ward, whilst one is meant for the mothers to allow them to learn more about why they’re there, schedule their stay there and communicate with midwives when they’re not around. In short, two apps that speak to each other with scheduling, communication and informational capabilities.

Speaking of capabilities.

The ideation session went a bit over board and Stork quickly became an app that solved all the problems in the world. I took a step back and made a list of the bare minimum requirements that would be needed to solve the problems at hand.



Information Architecture

Having a set of clear requirements made it easy to create a good and functional information architectures. These were both subject to later change after user testing.

User Flows

The clear requirements and IA helped set the user flow of the apps. These were once again both subject to later change after user testing.



First Prototypes

Based on the user flow I sketched rough wireframes on how the app would look. You’ll have to excuse my drawing skills.

Midwife Low Fidelity

Mother Low Fidelity

I then turned the low-fidelity sketches into a mid-fidelity prototype using Framer. You can click through an early version of it here.

Final Prototypes

Using Framer I created two fully functioning high-fidelity prototypes of both apps. I did this to make user testing easier.

View Stork Midwife here.
View Stork Mother here.

Testing and test results

During the testing phase I put the prototypes in front of real users and observed how they interacted with them. I collected feedback on how the participants felt during the process. I did this to see if the app had any major flaws, or if any features were missing.

One of the participants pointed out that their app wouldn’t necessarily make it any easier to schedule their day as the hadn’t got a feature to see their full schedule.

This shows the importance of user testing the application. I couldn’t believe I missed such an important feature, so, I made improvements to the prototype. It now has that feature front and center on the homepage of Stork Midwife.

Learnings and conclusion.

The final question still remains. Is this an application that can help improve the lives of midwives and mothers at maternity wards?

Based on the overwhelmingly positive feedback I’ve gotten, especially from midwives who would use this app on a daily basis, I strongly believe that.

As always, there are a few obstacles in the way before that becomes a reality. Mainly, the development and how to make the two apps communicate seamlessly with each other. There’s also the concern of privacy. How do we ensure that no sensitive details about a patient gets in the wrong hands?

Either way, those are questions that I have decided not to answer. The app has also potential to be expanded upon. A lot of features were suggested during the ideation session. A few of those were ability to order food from the kitchen, or the ability for cleaning staff to see if a room is empty or not. These are all things that I’ve decided to not focus on. My main focus was on the core functionality and main problems all along.

One of the midwives asked me when they will be able to start using this application. This is pretty much the highest praise I could ever hope for.