Back to Portfolio
Enterprise ToolsInternal SystemsWorkflow MappingPermissionsUX Documentation

Training Library for Complex Aviation Workflows

Designing an enterprise training library and distribution system for technical and operational teams in the aviation space.

Project Type
Enterprise product design
Context
Large aviation organization
Role
Sole UX designer
Platform
Web application
Aviation training library interface
Overview

I worked as the sole UX designer on a training library and distribution system for a large enterprise organization in the aviation space.

The goal was to help teams manage, access, and share training materials across technical and operational groups. The system started with internal training content, but it needed to expand quickly to support external partner organizations as well.

That meant the product needed to handle multiple organizations, different roles, different access levels, and team-specific workflows from the start. The work focused on replacing fragmented processes spread across FTP, internal tools, and email with a clearer product for content organization, permissions, and distribution.

My Role

I led the UX work for the project.

  • Planning and conducting discovery with users across multiple teams
  • Mapping how training materials were created, managed, shared, downloaded, and updated
  • Identifying where existing workflows were fragmented or unclear
  • Modeling roles, permissions, and access needs across internal and future external users
  • Designing interaction flows for complex tasks
  • Breaking dense screens into clearer multi-step workflows
  • Creating detailed UX documentation for offshore development
  • Working with project managers and developers to clarify behavior, states, and edge cases
  • Collaborating with UX designers on related tools to align shared patterns across systems
The Challenge

Training materials were being managed across a mix of FTP, internal tools, and email. Teams could get the work done, but the process created confusion around versions, downloads, ownership, and sharing.

Different groups had overlapping needs, but their workflows were not identical. Some users needed to upload and manage content. Others needed to find, download, or distribute materials. As the system expanded to support external partner organizations, permissions and visibility would become more complicated.

A previous design direction had already been explored and was not well received, so part of the challenge was rebuilding confidence in the product direction. The offshore development model also meant the design needed to be especially clear, with enough documentation to support implementation across time zones and handoffs.

Research and Process
Understand real workflows

I started by talking to the people doing the work. I interviewed users across teams to understand how training materials were created, updated, stored, shared, and distributed. These conversations helped separate the official process from the real process. The formal workflow was only part of the story. A lot of the work depended on habits, workarounds, local knowledge, and team-specific expectations.

Map the system

After the interviews, I mapped workflows across different teams and roles. This helped clarify where users had shared needs, where their needs diverged, and where the product needed to support different behavior for different groups. The mapping work was especially useful for understanding access and visibility. The system needed to support internal teams first, but the structure had to make sense when external organizations were added.

Workflow map documenting the training library process across roles and handoffs
Workflow map documenting the training library process across roles and handoffs
Design for roles and permissions

A major part of the design work focused on roles, permissions, and access. The product needed to answer practical questions: Who can upload training materials? Who can edit or replace them? Who can see which materials? Who can download them? Who can share them with another group? What changes when an external organization is involved? The goal was to design a model that could support variation without making the product feel overloaded.

Role and permissions modeling across internal and future external users
Role and permissions modeling across internal and future external users
Simplify dense workflows

One early screen had become too dense and difficult to use. Instead of continuing to refine it as a single screen, I broke the task into a clearer multi-step flow. This made the process easier to follow, reduced the amount of information users had to understand at once, and created clearer moments for review and decision-making.

Multi-step interaction flow documentation, each step scoped, sequenced, and independently validatable
Multi-step interaction flow documentation, each step scoped, sequenced, and independently validatable
Support implementation

Because the development team was offshore, I created detailed UX documentation that described flows, states, rules, and expected behavior. I met regularly with project managers and developers to answer questions, resolve gaps, and identify edge cases. Those conversations helped us catch missing states and decide what needed to be addressed immediately versus what could be scoped for later.

UX documentation produced for offshore development handoff
UX documentation produced for offshore development handoff
Align with related tools

I also collaborated with UX designers working on related products. We looked for places where shared patterns could improve consistency across systems, especially for users who would move between tools.

Key Design Decisions
Design for future external access early

Even though the first users were internal, the product needed to support external partner organizations soon after. I designed the structure with that future complexity in mind instead of treating it as an add-on.

Separate shared workflows from role-specific needs

Different teams needed access to the same system, but not always the same actions or information. The design separated shared patterns from role-specific behavior.

Use multi-step flows for complex tasks

When a task became too dense for a single screen, I broke it into steps. This helped users understand where they were, what decisions they needed to make, and what would happen next.

Document behavior clearly for development

The design work included detailed documentation for edge cases, permissions, states, and interaction behavior so the offshore development team could move forward with fewer assumptions.

Outcome

The project established a clearer direction for a training library that could support internal teams and future external partner organizations.

The work helped turn fragmented processes into a more structured system for organizing content, managing permissions, and supporting different user needs within a shared platform. It also gave the development team clearer guidance for implementation.

Learnings

This project reinforced that enterprise UX is often less about individual screens and more about understanding how work moves across people, teams, systems, and handoffs.

It also highlighted the importance of designing for variation early. When a product is expected to grow across organizations with different needs, roles and permissions cannot be treated as a late-stage detail.

The project also reinforced how much of senior UX work is communication. Clear documentation, direct conversations, and ongoing alignment were as important as the interface itself.

Tools and Methods
User interviewsWorkflow mappingRole and permissions modelingInformation architectureMulti-step interaction flowsEnterprise product designUX documentationEdge case documentationCross-functional collaborationDeveloper handoffPattern alignment across related tools