YEAR
2023
ROLE
Design Lead
STATUS
In progress
Digital twin platform cover visual
01 / OVERVIEW

Simulating the training pipeline before committing to it

Despite the post COVID-19 travel boom, our client was facing significant difficulties ramping up resources to meet the surge in travel demand. Untapped business opportunities were lost to competitors who could capture the market share the client couldn't serve in time.

To address this, a Digital Twin was developed to generate comprehensive pilot training plans, with the capability to simulate those plans through a detailed probabilistic model. By evaluating potential scenarios, the client could anticipate resource bottlenecks earlier and ensure enough pilots were trained and available precisely when needed.

planned trainings starting on time
80%
planned trainings starting on time
in implementing a digital twin in the pilot training space
First mover
in implementing a digital twin in the pilot training space
from design to MVP launch
4 months
from design to MVP launch
02 / CONTEXT

Manual Excel plans, with half of trainings never executed

Existing pilot training plans were produced manually every month, based on static assumptions without clear insight into feasibility. Inaccurate estimates led to shortages or surpluses of pilots — with over 50% of planned trainings going unexecuted.

The client needed a solution beyond manual Excel-based methods to inform strategic decisions and ensure optimal pilot availability while minimising costs: both short-term fixes and a systematic, long-term approach. Introducing a Digital Twin aimed to simulate scenarios and project outcomes for those longer-term needs. As the designer, I was tasked with initiating the development of the MVP.

HOW MIGHT WE

Better cater for the right resources to enable future flight demands as accurately and efficiently as possible?
A pilot operating a flight simulator in a training facility
Simulator time is the scarce resource the plans allocate (stock photo)
03 / THE SOLUTION

Create, explore, simulate and compare training plans

  1. 01

    Generate a training plan

    Select a method for generating a plan — from existing inputs of a training plan, new inputs, or an existing file. Input key parameters, upload the necessary files, and a training plan is generated for the month.

  2. 02

    Explore your training plan

    A clear, organised view of training plan details lets planners review every aspect, from pilot assignments to training sessions, ensuring transparency and effective management.

  3. 03

    Simulate training outcomes

    The simulation tool projects and analyses the potential performance of a training plan, helping planners anticipate challenges and optimise pilot availability before implementation.

  4. 04

    Compare simulation results

    Comparative analysis lets planners evaluate and contrast different training plans and simulation parameters, providing the insight needed to make strategic adjustments.

PRODUCT IMAGERY

Interface screens for the four capabilities are being prepared for this page, pending confidentiality clearance. Each update is recorded in the log.
04 / DESIGN APPROACH

Designing for the long term amidst ambiguity

Rapid MVP development and strategic prototyping, in three phases. Each step below opens into the full story.

01. Defining the initial product scope

The broad MVP requirements provided for the Digital Twin initially seemed clear. But as I delved into the details, it became apparent that neither the client nor the initial scoping team had finalised specific requirements for the build. No journey specific to the platform had been drawn up, and questions about inputs, outputs and data acquisition were often met with a vague “we're still deciding”.

With time constraints in mind, rather than waiting for answers, I took the initiative to develop a preliminary user journey, site map and initial wireframes. These visual aids became invaluable tools for leading discussions, giving stakeholders a tangible foundation to make informed decisions and brainstorm together.

Insights and assumptions debunked during initial discovery

  • More complex than initially imagined: page structures and UI had to cater for far larger-scale inputs and outputs than assumed.
  • The client's simulation scenarios already contained adjustable parameters, rather than requiring multiple scenarios to be selected and simulated.
  • Reduced focus on key comparison metrics in the MVP risked being unable to highlight insights for users.
  • Initial capabilities couldn't yet integrate training plan generation for implementation and monitoring purposes.

OBJECTIVE 1

Generate an initial training plan based on supply and demand parameters, integrating initial solver logic.

OBJECTIVE 2

Simulate the performance of training plans based on defined parameters.

02. Milestones, mid-fidelity design and testing

Moving on from the initial scoping, the approach relied on agile collaboration between the client, developers and data scientists. Daily check-ins and reviews let us address challenges swiftly — decisions were made on the spot and designs iterated upon immediately, so the process could adapt to evolving requirements and implement changes promptly.

Uncovering usability and technical issues through user testing

Regular testing — arranged sessions and ad-hoc reviews with our client counterparts — uncovered usability issues and generated valuable feedback, which we used to refine the designs iteratively. Given the technical nature of the platform, we went through every single input and output element to make sure it made sense.

Introducing a wizard menu

Testing made it evident that users wanted a more intuitive, efficient way to reach the platform's main functions. Recognising the diverse priorities of the stakeholders using the platform, we introduced a wizard menu: users select their preferred main actions on entering the platform, for a personalised and efficient experience from the outset.

Redesigning the training plan and simulations view

The initial design put everything about a training plan into a single page of tabs. User testing showed most of that content was really projections of simulated plans — which logically belonged with the simulations for easier comparison — while the training plan itself needed multiple content-heavy views of its own, and simulation-centric users needed a way in that didn't route through individual training plans. We refined the information architecture accordingly.

  • FROMTraining plan with projection details spread across tabs

    TOOnly training plan details shown first, with its different variations and views to explore

  • FROMSimulation details accessed only via each training plan — hard to switch between planned and simulated results

    TOPlanned and simulated results on one common page for seamless analysis, reachable from the main navigation and from the plan itself

SCREENS

The artefacts for this step — journey maps, trackers and the before/after views — are being prepared, pending confidentiality clearance.

03. High-fidelity refinement and handoff

With no comprehensive design library available and time running short, we agreed with the client to prioritise the build first, with a commitment to refining the design post-handoff. To expedite design and development, we leveraged NextUI components, customised them to align with the client's branding, and developed additional local components where necessary — efficient progress without losing fidelity to the brand.

Twice-weekly designer–developer sessions handled clarifications and explanations, with ad-hoc calls slotted through the week for urgent questions and for me to verify development accuracy. That flexible working arrangement between the developers and myself met the urgent timeline while safeguarding the quality of the build. Figma files were annotated and organised by module with interactions drawn up, scenario variations laid out to explain the technicalities, and deprioritised items labelled — with unconfirmed requirements masked.

SCREENS

The annotated handoff files for this step are being prepared, pending confidentiality clearance.
05 / KEY SHIFTS

From manual guesswork to simulated confidence

  • FROMExcel-based manual data entry

    TOAutomatic plan generation

    The planning team previously used Excel tables to manually generate training plans — time-consuming and error-prone. The new system generates comprehensive training plans from key parameters and predefined conditions, streamlining the process and reducing errors.

  • FROMManual past data analysis

    TOAutomatic results projection

    Analysing past training plan performance previously relied on manual data analysis that lacked forward-looking insights. Automating performance results and projecting trends against scenario-based constraints gives teams actionable insight to evaluate plans with confidence.

  • FROMFragmented manual work processes

    TOStreamlined collaboration

    Centralising planning and analysis in one platform, with real-time updates and shared access to data, keeps everyone working from the same page.

  • FROMInconsistent, error-prone data

    TOReliable automated data checks

    Automated data checks and processing maintain data integrity by mitigating human error, so the team can trust the accuracy of the data behind their decisions.

06 / REFLECTIONS

Opportunities to enhance outcomes through more structured groundwork

  1. 01

    Aligning technical feasibility with project scope

    The team faced challenges enhancing Digital Twin capabilities to fully automate actions and optimise simulations, because the absence of required data and data pipelines only surfaced during testing later in the project. We implemented workarounds to achieve partial functionality, reserving advanced features for future releases.

  2. 02

    Bringing a service design lens to scoping

    Initial research and scoping were limited and vague, gathered by a time-tied, multi-tasking business scoping team. The project would have been more impactful with a thorough assessment of the pre- and post-journey through a service design lens: how the tool would actually be used, and its effects on other departments.

  3. 03

    The need for a dedicated product owner

    With no product owner on the project, I stepped in to bridge the gap, since I was most involved in day-to-day requirement gathering. I acquired subject matter expertise, planned the roadmap and ran check-ins and follow-ups — but splitting attention meant requirements, prioritisation and usability testing all got less time than they deserved.