MRO, what?

In order to meet the challenges of this project, our prior knowledge from a previous project in the aircraft modification environment was very helpful. This allowed us to draw on a solid basic understanding of this complex market. Understanding the specific requirements was not only an exciting and interesting process due to the close exchange and open cooperation with the responsible parties, but also an extremely pleasant one. All questions were considered intensively and in detail and discussed without reservation. In the process, we and thus the project result were able to benefit from the extraordinary expertise of our contact persons.

By the way, MRO is the abbreviation for Machine Repair and Overhaul.

Design process

We iterated over our designs for the service cut, the operating concept, and the design of the user interfaces in regular cycles, incorporating stakeholder feedback. This enabled us to create a basis that had been evaluated in terms of technicality, usability and feasibility to such an extent that it was possible to proceed very purposefully in further development.

We described the results of the technical and user workshops in the form of written documentation - especially for the project team - and used this as a basis for recording use cases in the form of user flows. These were refined in the form of wireframes and finally transformed into an interface design. With simple prototypes we were able to give a comprehensive impression of the product within a short time.

Since we started at a very early stage to understand the user interfaces as a composition of UI components and to keep these in a design component library, we were able to deal with adjustments at short notice and to work in parallel with the design team on the various services.

In its documented form, the resulting component library served as a content interface between the design and front-end development disciplines.

Frontend realization

To meet the business and operational requirements, it made sense to use Angular as the frontend application framework.

Angular brings the necessary tooling to implement and deploy reusable UI components - but only in the Angular context. Since we had to use other frontend technologies - e.g. the interfaces of the Keycloak instance are delivered as Plain HTML - we decided against Angular components as the central UI technology and instead used a standards-compliant technology with Web Components (also called Custom Elements). Web Components offer the advantage of being able to be presented in modern browsers without any further dependencies. In addition, we were thus able to make the technical cut between the frontend application and the frontend presentation to ensure that we could implement the specified frontend architecture in a clean and distinct manner.

Another significant advantage of this approach was the possibility to work on the application and the UI components simultaneously and with a larger team. Thus, we produced a first version of each UI component as a functional component that was used directly in the application. Subsequently, we worked on giving each component its own specific look and feel. These new components could be distributed just like adaptations of existing components over the package management - in this case npm.

The result is a project-specific design system that is a relevant and consistent part of the entire process, starting with the UX design process and ending with the front-end implementation. We can react to adaptations and extensions by intervening in a domain- and technology-independent tooling and thus meet current and future requirements without constraints and dependencies while strictly adhering to the content constraints.

Next Project