Training Library for Complex Aviation Workflows
Designing an enterprise training library and distribution system to replace fragmented workflows across technical and operational teams.
I worked as the sole UX designer on a training library and distribution system for Boeing. I conducted discovery across teams to understand how training materials were actually created, maintained, shared, downloaded, and distributed, then translated those workflows into a product structure supporting different roles, permissions, and access needs.
The initial product served internal teams, but needed to expand quickly to support external partner organizations as well. That meant organizational boundaries, content visibility, permissions, and distribution could not be treated as later additions.
The work focused on replacing processes fragmented across FTP, internal tools, and email with a clearer system for organizing, managing, and distributing training materials.
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 differences between documented processes and how people actually worked
- 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
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 create, upload, or manage content. Others needed to find, download, or distribute materials. As the system expanded to external partner organizations, the same content would also need different levels of visibility and access.
A previous design direction had already been explored and was not well received, so part of the challenge was establishing a new product direction grounded more closely in how people actually worked.
The offshore development model added another constraint. Designs needed to communicate not only what screens looked like, but how workflows, permissions, states, and edge cases were expected to behave across time zones and handoffs.
I started by talking with people involved in different parts of creating, maintaining, and delivering training materials. I interviewed users across teams to understand how materials were created, updated, stored, shared, and distributed. These conversations helped separate the official process from the real process. Formal workflows were only part of the story. Much of the work depended on habits, workarounds, local knowledge, handoffs, and team-specific expectations. Understanding those differences helped me identify which needs were shared across the organization and which workflows needed to remain specific to particular roles or teams.
After the interviews, I mapped workflows across teams and roles. This made it easier to see where users shared needs, where their workflows diverged, and how work and information moved between people and systems. The mapping was especially important for understanding access and visibility. The system needed to support internal teams first, but its underlying structure also needed to make sense when external organizations were added.
A major part of the design work focused on roles, permissions, and access. The system needed to answer practical questions: Who could upload training materials? Who could edit or replace them? Who could see which materials? Who could download them? Who could share them with another group? What changed when an external organization was involved? Rather than treating each permission as an isolated exception, I worked toward a structure based on the user's role, organization, relationship to the material, and the actions they needed to perform. The goal was to support meaningful variation without creating a separate product experience for every group.
One early design had accumulated too much information and too many decisions on a single screen. Continuing to rearrange the same elements would not solve the underlying interaction problem. I broke the task into a clearer multi-step flow, separating decisions into a sequence users could understand and complete individually. This reduced the amount of information users needed to process at once and created clearer moments for review and decision-making.
Because the development team was offshore, I created detailed UX documentation describing flows, states, rules, permissions, and expected behavior. I met regularly with project managers and developers to answer questions, resolve gaps, and identify edge cases. Those conversations often exposed states or conditions that needed additional definition and helped us distinguish between issues that needed to be resolved immediately and those that could be scoped for later.
I also collaborated with UX designers working on related products. We looked for places where shared patterns could improve consistency across systems, particularly for users who would move between tools.
Although the first users were internal, external partner organizations were expected to follow. I treated organizational boundaries, visibility, and permissions as part of the core system rather than something that could be bolted on later.
Different teams needed access to the same system without necessarily needing the same actions or information. I separated common interaction patterns from behavior that depended on role, organization, or access.
When an important task became too dense for a single screen, I stopped trying to optimize the existing layout and instead broke the task into a sequence of smaller steps. This made the workflow easier to understand and gave individual decisions clearer context.
The offshore development model made ambiguity expensive. My documentation covered interaction behavior, states, permissions, rules, and edge cases so developers did not have to infer important parts of the experience from static screens.
The project produced a product structure, workflows, role and permission model, interaction designs, and implementation documentation for a training library capable of supporting both internal teams and future external partner organizations.
The work replaced a previously unsuccessful design direction with a system grounded in how training materials actually moved across teams and gave the offshore development team detailed guidance for implementation.
Because my role focused on research and initial product design, I was not involved through launch and did not have access to post-implementation usage metrics.
This project reinforced that enterprise UX is often less about individual screens and more about understanding how work moves across people, teams, organizations, and systems.
It also reinforced the importance of designing for meaningful variation early. When a product is expected to expand across organizations with different roles and access needs, permissions and organizational boundaries need to be part of the product structure from the beginning.
Finally, the project demonstrated how much of senior UX work is communication. Research synthesis, workflow models, documentation, and ongoing conversations with product and development were as important to successful implementation as the interface designs themselves.