Aircraft Maintenance Training
Simulation Authoring Tool Design
Overview
An aircraft manufacturer created an advanced simulation environment for maintenance training. But research showed that they needed to also create an easy tool for airlines to be able to customize training modules for their own needs.
My Contribution
As design team lead, I guided and performed research, ideation, concept testing, story mapping, MVP prioritization, UX and VX design.
Impact
Our highly effective design innovation and production design led to successful agile development and launch. The product transformed the manufacturer’s market position to that of an enhanced services provider.
“Paul was one of my favorite designers I’ve had the pleasure of working with and he always offered well-detailed explanations into his designs and wireframes. He brings a cheery atmosphere with him and always knows the right questions to ask to get us moving.”
“Paul is a talented designer, collaborative teammate, encouraging mentor, and an energetic spirit. He also has a superpower for digesting complex information and organizing it into an easy-to-understand manner for the rest of his designers to comprehend.”
What's Interesting?
Design Beyond the Hard Edge of MVP
Through concept design and testing, we created a long term product vision with key features and values. After sizing clusters of scope and presenting visually to the client, hard choices were made which left some items clearly in or out of scope. But in our agile work stream with this conceptual product, the edge of MVP could shift depending upon the architectural complexity of the cloud platform.
As a team we thoughtfully ranked those features that would live near the MVP edge. Between “in” and “out” we added two more tiers with items sequenced within.
As a design team we were able to preserve the longer term vision in our UX wires, but had to think and communicate modularly about how pieces of scope could be added in phases over time.
WYSIWYG-ISH Design
Through stakeholder and simulation Author interviews, we confirmed that the primitive legacy Authoring Tool (AT) was too detached from the highly visual Training Simulator. A key design value, therefore, was to drive the Authoring Tool toward WYSIWYG, although there were significant technical limitations and costs to do so.
We went WYSIWYG-ISH. A prime capability (shown above) was to feature graphic asset snapshots so that the Author could explore the dozens of scenes and hundreds of interactive components without relying upon cryptic asset names. Even this was at risk for MVP, though, so at an even more basic level, we were able to rearrange input and selection fields to mimic the end product.
Legacy Question Configuration
Inputs and selections in the legacy AT bore no visual similarities to what they would render. This forced Authors to preview after every step in a lesson.
WYSIWYG-ISH Inputs
The new input form wraps at the same break points and features similar visual styling to the sim.
Actual Sim
Authors can preview the actual lesson less often since it resembles the new input form.
Biggest Challenge
Core architectural scope competed heavily with appealing product scope. A transformative goal of this project was to move lesson management to the cloud, so that new airline authors could download and customize the manufacturer’s official lessons. This became a many-layered onion of scenarios and scope once a combination of usability scenarios and architectural complexities were unearthed.
From the user’s perspective, an instructor and their students must never have a lesson change drastically while mid-teach. Thus we gave instructors the ability to create playlists with pinned lesson versions. However, this created complexities around communicating when an updated simulation player could no longer handle pinned deprecated lessons. Compounding this, an author must also be able to edit lessons ahead to a pre-release version of the simulation player to create beta lessons before launch.
This all required deep and careful architectural explorations and mapping of roles and states, weighing architectural value against consumer appeal. In the end, vending and managing lessons was simply the highest core requirement, and this versioning and playlist strategy consumed a non-negotiable 35% of scope.
The consumer value items had to negotiate around this architectural iceberg. This completely pushed out things like storyboarding tools, approval workflows, and other collaboration and noting tools, and even put fundamental asset graphics at the edge of MVP. The client ultimately made the choice, and will need to seek funding to add these value-strengthening items post-release.
A Phased Approach
1 - Research & Envision
We interviewed stakeholders to understand their goals, needs, and pain points. From that, we created high level concepts which we tested and validated with end users.
2 - Define MVP
Define an MVP that incorporates features based on research and concept testing. Consider MVP as part of a larger vision and longer term road map.
3 - Design & Build
With the MVP defined, we designed and delivered UX flows, wires, and a visual UI component library, closely coordinating with the architects, developers and clients.
Research & Envision: a “Wedge Project” Model
In a design agency, many engagements are built around a 6 to 8 week “wedge project” model, where we swoop in to perform initial research and rapidly iterate on design concepts through prototype, feedback, and enhancement. In the end this generates a roadmap of prioritized features, grounded in research insights. I built the Phase 1 research plan to mimic this approach, and in the end it produced a strong, grounded set of features and understanding of the possibilities for this Authoring Tool.
Define MVP: Visualize to Facilitate Choosing
The team used a Miro board to expose and refine the key epics and user stories. All these stories were exported to a spreadsheet, where the team performed simultaneous cloud edits to the master documentation, fleshing out and refining the stories and acceptance criteria. After a round of dev reviews, we called out complexities, and performed a rough sequencing and prioritization. In the end we were able to walk the board with the client, easily dragging stories above or below the line, or into the candidate scope zone.
Design & Build: A Well Oiled Machine
As we entered the Design & Build phase of the project, we leveraged a standard SCRUM process. For this large project, I served as Design Director as well as a hands-on UX designer. I navigated the center track of this process, interfacing closely with our project managers, architects, developers, and clients, while at the same time coaching and supporting newer UX and VX designers on our team. We divided the workload, and had a healthy structure of collaboration, ownership, check-ins and cloud-based documentation strategies to keep this large effort on track.
Design Cycle - Simulator Asset Selection
Training Simulator: Grounded Example
To begin, we identified core examples, mapping and visualizing all capabilities of the current Training Simulation. Grounded examples helped shake out complexities and gaps in current the Authoring Tool. At the center of the simulator is its ability to render interactive scenes and components, allowing a student to explore and realistically perform maintenance activities. With this ability, they can prove their knowledge either by exploring and answering questions, or by directly performing the correct action to complete the repair.
Scenes
An Author has dozens of scenes across multiple aircraft to choose from. Their goal as instructors is to introduce enough complexity to allow a student to get a little lost, and to express their knowledge by finding the correct scene, component and action.
Components
Within each scene there may be one or two components, or there may be dozens. In the simulator, as in real life, an aircraft maintenance student must be able to identify where on or in the plane to access the component, then perform their work.
Baseline: Old Authoring Tool
Understanding the operation within the end product (the Training Simulator), we also thoroughly explored the current Authoring Tool. Through both a heuristic exploration and stakeholder interviews, we identified the Scene and Component selection process as a major weakness in the current design. This would especially limit its ability to be adopted by novice curriculum developers, who may not know all the technical names and abbreviations for scenes and components.
Scenes
Current scene selector has a long list of cryptic abbreviations and no visual display. Authors must add and preview in the simulator to confirm selection.
Components
Current component selector also has a list of cryptic items. What’s more challenging is that not just one image, but multiple may be required to explain location and operation within the sim.
Concept Wires and Testing
Based on stakeholder interviews, we created three diverging concepts, each with its strengths and weaknesses. We then walked today’s Simulation Authors through the concepts, compiled feedback and produced the following single concept. Both the experienced Authors and the Product Owner (seeking to reach a novice audience) had a strong positive response to the inclusion of asset images.
Scenes
In the final concept, our scenes were selected from a visual similar to that shown within the Training Simulator. Multiple scenes could be selected, and for each a single preview image would display.
Components
This concept allowed an Author to browse a long list of components within a scene. For each component, a primary image would be displayed, as well as supporting images.
UX Explorations & Wireframes
Although the concept was solid, there were some complex interactions that were imperfect that required further ideation and experimentation. After trying numerous approaches, we arrived on a final UX approach that supported fast and intuitive selection of multiple scenes and components for the export, as well as browsing and learning for the novice.
Scenes & Components
A combined selector shows a full list of all scenes, with components nested within. A shared preview pane provides either a scene’s plane-view image, or a component’s carousel of images. Additionally it provides other contextual info, such as the component’s available actions.
Explorations
Figma provided a powerful environment for team collaborative design.
VX Final
Our visual designer joined the project while UX was well under way. We had already been designing to Material Design standards, so the changes made in the final UX were rather minor.
Scenes & Components
The final VX designs applied simple styling and color changes, adjusted and perfected grid placement, and overall confirmed our selected design.
File Management
We set up Figma with progressive tabs for UX and VX.
Design + Dev + QA
A close partnership
Our design team was closely embedded within a larger team of PMs, architects, front and back end developers, and QA team members. As an agency, we typically ramp down our design staff during the final development, so our designs had to be well documented, and the relationship had to be strong from the start to reduce rework later.
Final Notations
I coached the team to note in such a way that both Dev and QA could understand the full set of features and functionality. Supplemental documents were provided in shared spreadsheets, confluence, lucid charts, and more.
JIRA Tickets
The team managed their SCRUM process in JIRA. Although the newer cloud based tools communicate much, the source of truth was JIRA. Thus, all stories and UX, VX, Dev and QA tickets were managed there, with cross links to other resources.
Design Inventory
To ensure that every design went through all steps, and to provide a single visual representation of readiness, a design inventory page was shared with the team. This acted as a quality gate checklist, and provided links as well as accountability.
Reflections
Research & Envision:
Start like a wedge project – Budgeting an intensive 8 week exploration paid off. The team generated and validated numerous concepts, and we were able to narrow and prioritize scope more easily.
Get grounded – Finding real examples uncovered complexities and opportunities. We might have attempted to design only from the Authoring Tool’s perspective, but really benefitted from seeing the results of each action in the student’s Training Simulator experience.
User Stories:
Cloud based story maps – Creating a Miro board allowed us to easily visualize and organize our epics and stories. Prime benefit was to facilitate discussions, where walking the board made it easy to understand the context of each particular capability.
Cloud based story spreadsheets – Group editing of spreadsheets was helpful when we needed to get more detailed. Again this was most helpful in facilitating discussions, but also empowered asynchronous work.
Internal technical review – Vital before bringing the final stories to the client, we met internally and went item by item through the 300+ stories with our dev and architect teams. This investment of time proved to NOT be a waste of time, as our stories were well understood, and alternatives were identified for at-risk items.
MVP Client Prioritization:
Visualization facilitates decisions – All our pre-work, and especially our interactive story maps helped us walk the entire 300+ item story board in under 4 hours with the client. This included not only understanding the features, but choosing and prioritizing – dragging items into candidate status or out of scope.
Design Leadership:
Project planning – Leveraging experience from prior projects, both with this client and those in other industries, we were able to structure something that works well, with high confidence.
Sprint planning – Close alignment with the client as well as QA and Dev helped us prioritize our sprints and deliver product designs that the clients loved and our team could confidently build.
Design ownership & support – We organized our design team for individual ownership of topics. Through regular checkpoints as well as frequent collaboration sessions, we moved quickly through a dauntingly large list of features to design. Individual team members (junior and senior) presented at demo and had a safe, supportive, constructive environment – both internally and externally.
1x1 relationship – I was Design Director on this project, but also had a 1x1 working relationship with my teammates. From donuts and coffee to career-oriented 1x1 meetings, I worked to help develop the team and ensure their success.
Team Connections:
Zooming together – The friendships and trust that we built were all the more remarkable given that this project was executed completely remotely via Zoom meetings, Slack sessions, phone calls, and shared online tools. Each of us grew in the process, delivered fantastic results, and had fun along the way.
Copyright © Paul Townsend