EIS — Expedition Interface System

Cargo in EIS follows an established relationship: an article can be assigned to packaging, and articles or packages are moved into the final freight. Import, drag and drop, submission and subsequent approval were already part of the system.

AWI’s documentation identified needs around large and repeated shipments: better overview, search, reuse and operations across multiple items. Requirements and feedback reached our team through AWI and the product owner. I did not conduct the user research referenced in that documentation myself.

This made the redesign a specific kind of task. It involved changing how people saw and worked with the process while retaining the data model and business rules beneath it. A new visual layout could not simply replace the relationships between articles, packaging and freight.

The wider platform also had a legacy technical environment and central and satellite installations. That was the development context. It does not, by itself, explain every interface decision, but it mattered that the work belonged to an existing application rather than a standalone concept.

The Standard view keeps instructions and a more explicit structure visible. That guidance makes sense for people who use the workflow less often. For regular cargo work, however, it occupies space that could otherwise show articles, packages and freight.

The Expert direction addresses that difference through presentation. It reduces supporting text, compacts the basic information and gives more of the workspace to lists and working areas. The process remains recognizable across both views.

I worked on the cargo redesign and Expert-view variants as part of this scope. My recollection of exclusive authorship across every Expert variant is less certain, so I distinguish the work I contributed from ownership of the entire concept.

The important design question was how much guidance should remain visible during a task. Removing it everywhere would change the experience for occasional users. Keeping the same amount everywhere would limit the space available for repeated operational work.

The two views express different balances. Standard uses space to explain the task; Expert uses more of that space to expose its working material. The Expert designs also show layout controls and ways to expand working areas, extending that emphasis on workspace flexibility.

This was an accepted design direction according to my recollection, but I cannot identify the exact illustrated variant as a production release. The screens show the intended differences, not a measured increase in speed or efficiency.

The final freight list, or Frachtliste, represents a different stage from the article and packaging areas. It shows the shipment being assembled. Its position therefore affects how the workspace communicates the relationship between preparation and the final freight.

In the Standard and Expert layouts shown here, Frachtliste sits below the article and packaging areas. My later variants explored a different placement and organization of that space.

The aim was to make the final state of the freight more visible and use a larger screen more effectively. With long lists, the user has several related areas to work between. I wanted to explore layouts in which the freight list had a more prominent relationship to the two preparation panels.

The criteria were the visibility of articles, packaging and freight, and the ability to inspect more of those related elements together. This is a spatial problem as much as a visual one: changing a heading or color does not alter where the user has to look across the workspace.

The later designs vary the placement and heading of Frachtliste and retain separate working panels. They let us compare how the same product model could occupy the screen differently.

I cannot establish which layout was formally selected, which alternatives were rejected or which reached production. The value of this material is the exploration and its criteria. It should be read as a set of design variants rather than a sequence ending in a proven winner.

I redesigned the existing article-creation form while preserving its data model and business rules. The design separates the task into stages and presents different cargo-related information within that structure.

The form includes actions for saving and closing, saving and creating another article, and continuing towards packaging. Those actions represent different ways of proceeding through the task. They are part of the interface design, rather than new logistics rules.

For repeated entry, the option to save and move to another article is particularly relevant. It gives that continuation an explicit place in the UI. I cannot attach a time-saving result to it, but the design makes the option visible rather than leaving the user to infer the next step.

Another screen in the cargo designs covers review before submission. It includes a warning that only complete positions moved into the final freight area will be included, and that remaining working items will be lost when submitting.

That message reveals an important distinction in the interface: creating an article is not necessarily the same as including it in a shipment. Reading the designs today, I see a potential mismatch between a user’s sense of progress and the system’s completion state. That is my interpretation of the material, not a finding from an observed usability session.

The review screen makes the inclusion condition explicit before submission. I do not claim authorship of every element on that screen, or that the warning verifies the exact behavior of a production release. It provides context for the rules that the redesigned article flow had to sit within.

EIS already had a UI Kit and work from earlier designers. I extended and organized that material for the redesign rather than creating the visual system from scratch.

The work supported consistency across forms, tables, actions and layout patterns. Figma designs and specifications provided references for development, followed by implementation review where that was part of my work.

I describe this as development of an existing UI Kit. The available material does not establish a complete governed Design System or a component library fully synchronized with code.

AWI and the product owner brought needs from the use of EIS. I prepared UX/UI proposals in Figma. The PM helped clarify scope and priorities, while developers assessed proposals against the existing application.

Designs were reviewed with AWI and iterated before handoff. I also reviewed implementations. This kept the work connected to product requirements and development rather than ending at a presentation of screens.

I remember that collaboration model clearly. I do not retain a specific comment or ticket that explains the final change to an individual variant, so I have not reconstructed one here.