2
Primary surfaces
Cluster and infotainment had different attention contexts while still needing to behave like one HMI system.
MAN Truck & Bus / 2018-2022
Case study
Designing embedded HMI foundations for truck interfaces.
Working across cluster, infotainment, iconography, prototypes, and internal design foundations where detailed UI craft had to scale into a coherent embedded product system.
Embedded HMI
Overview
The work centered on embedded truck HMI: cluster and infotainment surfaces where precision, consistency, and technical constraints all had to move together.
At MAN Truck & Bus, my work started close to the interface details for the new TGX truck. I produced graphical content and layouts across cluster and infotainment surfaces where legibility, state clarity, and implementation limits mattered from the beginning.
Over time, the contribution expanded into prototypes, icon-system work, process improvements, and internal design-system foundations. The case is important because it shows how precise UI execution became a broader product-system contribution inside a high-constraint automotive environment.
At a glance
Scope in one pass
3
Contribution modes
Detailed UI production, prototypes for behavior review, and shared foundations for consistency across outputs.
1
System language
Icons, layouts, interaction behavior, and implementation constraints had to work as one product language.
Contributions
Worked from detailed UI production into prototypes, icon systems, and reusable HMI foundations.
The role began with precise graphical production for embedded truck interfaces. That work required disciplined hierarchy, consistent layout decisions, and attention to how interface details would survive the constraints of vehicle implementation.
From there, I contributed to prototypes, icon systems, process improvement, and internal design-system work. The useful signal is not only that screens became cleaner. It is that behavior, language, and shared decisions became easier for the team to review, align, and scale.
Three connected use cases
Three projects show how the work changed as the product problem changed.
The workstreams focus on different product problems. Together, they show how the design approach adapted while the underlying need for clarity stayed consistent.
Driver surface
Cluster
A high-attention surface where hierarchy had to stay disciplined, stable, and instantly readable.
System surface
Infotainment
A broader interaction surface where flexible product behavior still had to respect the HMI language.
Design foundations
Systems
Prototypes, iconography, and process work turned detailed interface output into a more scalable product foundation.
Driver surface
Cluster
A high-attention surface where hierarchy had to stay disciplined, stable, and instantly readable.
The instrument cluster had different rules than a normal digital surface. It had to communicate quickly, keep hierarchy stable, and support driver attention without relying on decorative interface energy.
The work required precision at the component and layout level, but the larger design problem was structural: every detail had to support legibility under real operating conditions and fit into the broader HMI language.
Design pressure
Driver-facing information where weak hierarchy, unclear state, or inconsistent visual language becomes visible quickly.
What it demonstrates
Ability to make interface decisions inside a safety-adjacent, implementation-bound product surface.
Surface logic
Hierarchy
Information had to be ordered by attention context and driving relevance, not by visual preference.
Consistency
Shared patterns mattered because the cluster was part of a larger cockpit system rather than an isolated display.
Constraint
Embedded limits made disciplined structure more useful than decorative variation.
System surface
Infotainment
A broader interaction surface where flexible product behavior still had to respect the HMI language.
Infotainment carried a different interaction rhythm than the cluster. It could hold deeper flows and more user choice, but it still needed to align with the same visual and behavioral language.
That made the design problem less about one finished screen and more about cross-surface coherence: how screens, icons, labels, states, and interaction rules continued to feel like the same embedded product.
Design pressure
More flexible interaction space without permission to drift away from the shared HMI language.
What it demonstrates
Ability to connect product surfaces instead of treating each deliverable as a separate artifact.
Cross-surface system
Interaction
Flows needed enough flexibility to support infotainment use without weakening embedded HMI discipline.
Language
Icons, labels, and layouts had to remain recognizable across multiple product contexts.
Review
Work became stronger when interaction behavior could be reviewed before implementation made changes expensive.
Design foundations
Systems
Prototypes, iconography, and process work turned detailed interface output into a more scalable product foundation.
The strongest part of this chapter is the role shift. The work moved beyond producing screens into helping the team create shared foundations for how the HMI should look, behave, and be reviewed.
Prototypes made behavior concrete before it hardened in implementation. Icon systems reduced fragmentation. Process improvements helped the work move from individual output toward a more durable product language.
Design pressure
The team needed decisions that could survive more than one screen, review, or delivery moment.
What it demonstrates
A clear transition from UI execution into UX, system thinking, and scalable design operations.
Foundation layer
Prototypes
Made interaction behavior easier to evaluate before it became expensive to change.
Icon systems
Helped the HMI maintain a shared visual language across multiple outputs.
Process
Supported a more systematic way to review, refine, and scale design decisions.
Icon creation
Concept development
What connected the work
The workstreams were different, but they shared one embedded-product pattern: precision becomes valuable when it turns into reusable structure.
01
Precision under constraint
Small interface decisions mattered because embedded HMI leaves little room for weak hierarchy, unclear state, or inconsistent language.
02
Cross-surface coherence
Cluster and infotainment could not be designed as isolated worlds; they had to read as one product system.
03
Reviewable behavior
Prototypes and shared foundations made behavior easier to discuss before implementation made it rigid.
Impact
What it proved
This chapter shows the move from detailed embedded UI craft into prototypes, icon systems, and shared foundations for a constrained HMI environment.
Impact read
What the work established
UI
Starting point
The contribution began with precise graphical and layout work for embedded HMI surfaces.
UX
Role expansion
The work widened into prototypes, interaction behavior, process improvement, and shared foundations.
HMI
Product context
The case shows automotive design discipline where consistency, legibility, and technical constraints shape the work.
Learnings
Embedded products expose weak structure quickly because every surface has to work inside real constraints.
From craft to system
Precision is the entry point, but the long-term value comes when detailed decisions become repeatable structure across surfaces and teams.
Design systems in context
Design systems matter most when they reduce fragmentation across behavior, language, and delivery rather than existing as a separate artifact.
Career relevance
MAN is the bridge between Bragi's embedded-product ambiguity and later enterprise systems work: it shows how clarity scales when the environment becomes more formal and constrained.
The point of this chapter is not that every screen can be shown publicly. It is that the design judgment is visible: structure the system, make behavior reviewable, and keep quality consistent across real product constraints.
Career sequence
You are on chapter 3 of 4. Continue through the sequence for the clearest career story.
Newer chapter
Supporting chapterFleet Charging product bridge
Elli
Elli Fleet Charging across driver app, console context, shared components, and process.
A bridge into mobility-service complexity, focused on making driver charging journeys, fleet oversight, and reusable product foundations easier to work with.
Earlier chapter
Supporting chapterStartup ambiguity
Bragi
Startup hearables work where hardware behavior, onboarding, QA, and production constraints kept moving.
Early product-systems work across device behavior, companion experiences, feature validation, and screenless interaction logic.