Siemens · AX4 · Digital Logistics
Building design practice and system adoption for Siemens AX4
How I standardised design workflows, supported progressive design-system adoption and enabled designers and engineers inside a complex logistics platform.
Executive summary
Improving the system around design, not only the screens
I joined the Siemens product organisation to help establish more consistent and transferable design practices around AX4 — a complex enterprise logistics platform used to connect supply-chain processes, systems, data and stakeholders.
My contribution extended beyond individual interfaces. I introduced standards for Figma files and design documentation, helped organise reusable components, supported the gradual adoption of a new Siemens design system and mentored other designers in applying the new practices.
I also worked directly with developers to translate centrally defined standards into the realities of an established product that could not be redesigned all at once.
The product context
Designing for a complex logistics platform
AX4, from Siemens Digital Logistics, is a cloud-native platform for multi-enterprise supply-chain collaboration and end-to-end logistics execution.
It connects logistics stakeholders, systems and data, supporting processes such as shipment management, tracking, exception handling and operational collaboration.
- The product supported complex and specialised workflows.
- Many users were experienced operational users.
- Existing functionality and interaction patterns could not be replaced without considering established behaviour.
- Design changes had to remain compatible with technical dependencies and ongoing development.
- A central design system had to be introduced into a mature product incrementally.
The work required more than applying a new visual language. It required a practical model for introducing change without disrupting continuous product delivery.
Design operations
A shared structure for projects, components and decisions
Design work was being created across multiple projects and levels of complexity. Without shared conventions, files, components, variants and documentation could be structured differently by each designer.
I introduced a practical working system that made design files useful not only to their author, but also to other designers, developers, Product Owners and stakeholders returning to a project after an iteration.
Reusable foundations
Reusable components and a focused UI kit.
Project structure
Standard templates, covers, grouping and categorisation.
Delivery context
Structures reflecting project stage and design iterations.
Shared conventions
Component, variant and status conventions.
Implementation clarity
Annotations explaining behaviour and requirements.
Transferability
Documentation readable by design and development teams.
The standards reduced the amount of implicit knowledge contained only in a designer’s memory and made the work easier for other people to interpret and continue.
Progressive system adoption
Introducing a central design system without stopping delivery
When Siemens introduced a new design system across its product portfolio, AX4 also had to begin adopting it.
A complete retrospective redesign was not realistic. The platform was extensive, actively developed and constrained by existing technical and operational dependencies.
We therefore used a progressive adoption model. The first stage introduced the new button standards. Typography followed later.
Instead of redesigning the entire platform at once, new standards were applied to areas already being changed by developers. Whenever work entered an existing section, that part of the product also became an opportunity to introduce the updated design language.
- 01Active product change
- 02Interface assessment
- 03New standards applied
- 04Implementation in release scope
This connected design-system adoption with ongoing delivery and allowed the product to evolve without creating a separate redesign programme detached from development priorities.
Working with constraints
A design system could not always be applied one-to-one
Central standards provided direction, but AX4 had its own interaction patterns, technical constraints and legacy behaviour.
My role included helping developers understand the new library and determining how its components should work inside the existing product.
- Analyse the difference between the central standard and the product requirement.
- Propose an adaptation appropriate for AX4.
- Consult designers responsible for the central Siemens library.
- Align decisions concerning icons, sizing, visual weight and component states.
- Document the agreed solution for implementation.
This made design-system adoption a collaborative product and engineering process rather than a visual replacement exercise.
AX4 mobile
Modernisation without breaking continuity
I also worked on the mobile experience of AX4.
The existing product language limited how far the interface could be changed visually. A completely new aesthetic would have created inconsistency with the wider platform and could have disrupted established workflows.
The challenge was to improve the mobile experience while preserving continuity with existing interaction patterns, the broader product, technical feasibility and the expectations of experienced users.
Team enablement
Standards create value only when a team can use them
I trained and mentored other designers, including junior team members, in applying the new standards independently.
- Structuring projects in Figma.
- Using and creating reusable components.
- Documenting interaction and implementation behaviour.
- Working with variants and statuses.
- Preparing files another designer could take over.
- Communicating decisions to development and product teams.
My responsibility was not only to create a working model, but also to help the team adopt it independently.
Discovery and facilitation
Structuring collaboration around distributed expertise
AX4 was too complex for any single participant to understand every business, technical and operational dependency.
For complex functionality, I helped structure discovery workshops around different types of knowledge. Domain and implementation experts clarified constraints, people close to users contributed operational expectations, and technical participants explained system realities.
I translated the workshop output into an initial concept and shared it as a short narrated screen recording. Participants could review the proposal asynchronously before a focused validation meeting.
Their feedback exposed constraints, implementation difficulties and unintuitive elements before the concept moved into more detailed design.
Wider Siemens contribution
Supporting teams beyond my primary AX4 responsibility
I supported a German Siemens product area that did not have its own dedicated UX team. The work included UX/UI support and visual design for an administrative product related to training management.
I also introduced Product Owners to accessibility considerations before the European Accessibility Act became an immediate delivery requirement.
These activities were secondary to my AX4 responsibility, but they demonstrate that my contribution extended beyond individual interface assignments.
The outcome
A more structured way to create, transfer and implement design work
No approved quantitative metrics are available for this work, so I do not attribute numerical efficiency or business outcomes to the changes.
- Shared standards for structuring design projects.
- More reusable design assets.
- Clearer documentation for designers and developers.
- Progressive adoption of the Siemens design system within active delivery.
- A repeatable approach to adapting central standards to product constraints.
- Mentoring and enablement of other designers.
- Stronger continuity when work moved between people and iterations.
The value of the work was not one redesigned screen. It was a more consistent system for producing and implementing design decisions.
Leadership perspective
Design maturity grows through operating practices
A design system alone does not create consistency.
Consistency depends on how teams document decisions, structure files, introduce changes, resolve exceptions and transfer knowledge between people.