Digitising medical requirements for aircrew

by | Jul 1, 2020

RoleUX & UI Designer, UX Researcher
CategoryClient Management, User Research, User Experience
DateJuly 2019 – October 2019


The company released an industry pitch challenge statement inviting vendors to:

  • Redesign the process that pilots go through to meet their medical requirements
  • Improve the backend administrative processes for the Squadron Officer
  • Enhance user experience for all user groups involved in the process
problems faced by user personas
Manual and time-consuming to manage aircrew’s flight currencies

My Role

The project team comprised of 1 project director, 1 project manager, 1 designer, 1 developer and 1 part-time consultant. I served as the UI and UX designer, as well as the UX researcher. Together with the team, we created a project plan of 13 weeks to deliver a coded proof-of-concept (PoC) and a clickable prototype. For this project, I facilitated 2 design workshops, completed 4 sprints and trained 3 facilitators to conduct 1 round of usability testing (UT) with 9 users.

The Process

an overview of my design process
process overview

Design Thinking Workshops

We run 2 design thinking workshops with 3 groups of user representatives (pilots, squadron officers, and aeromedical doctors) to understand the current journey of meeting medical requirements. 12 pain points were identified which resulted from a lack of transparency and manual processes.

as-is journey map with pain points and "How Might We" statements
as-is journey map with pain points (purple post-its) and “How Might We” statements (yellow post-its)

Ideation Workshops

3 top-voted “How Might We” statements were selected for ideation. I facilitated 2 ideation workshops with 6 users, resulting in 12 awesome ideas and 2 winning sketches.

Wireframing & Concept Development

Before creating any digital screens, I conducted a design review with the user representatives to validate the end-to-end design concept. This session was extremely productive as I had the developer to co-facilitate alongside with me. He addressed all technical-related questions while I handled the remaining feedback.

wireframes with feedback documented on post-its
First concept review using wireframes

Project Scoping

I used the wireframes to align clients on our scope of work per sprint. As we had a tight timeline, I discussed with the Product Owner to prioritise workflows to be coded and parked the secondary flows in the product backlog. However, I made sure to conceptualise all workflows in the clickable prototype.

project scoping using wireframe flows
Defined and prioritised scope of work

Prototyping & Supporting Development

For this project, we did not use a Kanban board to track work progress because the project team is lean, and I had prior experience working with the developer. Instead, the developer approached me directly whenever he had queries on HTML/CSS design or interaction flows. Throughout the sprint, the clients could review our work process via a published prototype link.

Sprint Review

We met our Product Owner and user representatives bi-weekly to showcase our product increment (1 clickable prototype and 1 coded PoC). At the same time, I used this session to validate the iterated screen flows and requirements for the upcoming sprint.

concept review using wireframes
Refreshing everyone’s memory on the scope for the next sprint with an updated concept

Training UT Facilitators

Before the UT day, I prepared the UT facilitator guide, task scenario decks and System Usability Scale (SUS) for printing. Due to time constraint, two UT sessions had to be conducted concurrently. Therefore, I also trained the team on the best practices for facilitators.

UT facilitator guide and task scenario printouts

Usability Testing (UT)

The team conducted 9 usability test (UT) sessions and validated 32 user stories. Our product concept was widely accepted and received an average score of 89.5 on the System Usability Scale (SUS), which is “Best Imaginable” for usability.

The participants claimed that our design solution is “much better than existing manual processes!” and stated that they “cannot wait for the actual system to be released”. To add value to our clients, we took our concept further by gathering feedback from the minority groups of users who were not onboarded. These users expressed interest in getting their workflows incorporated into the system, thus we gathered 30 new ideas for the next project phase.

We asked our users to describe our product in 3 words, this is what they said:

feedback from users in word cloud format
Word cloud generated from users’ feedback

The Outcome

Overall, our final deliverables exceeded the clients’ expectation, so we were invited to showcase this project at the Innovative Symposium exhibition, 2019. At the same time, our project approach helped to secure the actual project tender. Therefore, this industry challenge was awarded as a significant win to the digital team and got featured as a project case study for sharing with all digital folks at the Townhall.

Our design solution:

  • Reduced >80% of manual yet non-value-add administrative processes
  • Connected 3 silo user groups by streamlining business processes
  • Validated as a very usable product with SUS score of 17.25 higher than the industry average
project group photo with the product owner
Exhibition was held at the Singapore University of Technology and Design (SUTD) in October 2019

My Learnings

This was my first time creating a project plan for an external client. The main reason I suggested running continuous sprints to deliver the prototype in smaller chunks, was because I was given very few and short sessions to interact with the users. My strategy was to be able to iterate the design multiple times before development started, yet be able to give clients a taste of using the Design Thinking processes to co-create a solution with their users.

Thankfully, this project approach worked, so I can reuse this plan in the future. The user representatives were glad to know the potential scope of work ahead of time, which allowed them to get involved only during sprints that covered their respective workflows.

error: Content is protected !!