The most common mistake a designer makes when working on a HUD for the first time is opening Figma and thinking about it like a regular screen.
Speed: 32 px. Icon: 48 px. Arrow: 120 px. Spacing: 16 px.
For a mobile app, this is normal. For a HUD, it is not.
A HUD is not on the windshield. It is not on the dashboard either. It is a virtual image in space. That is why the main design language here is not pixels, but degrees.
A HUD should not be designed as a small screen in front of the driver. It should be designed as an optical system built into human visual behavior.
Imagine an invisible 360° sphere around the driver’s head. It covers space along two axes: horizontally, to the left and right around the driver, and vertically, up and down relative to the line of sight.
You can think of this sphere as a grid. Each cell in this grid is 1° × 1° of the visual field. In a regular interface, a designer might think: “this element is 80 pixels wide.” In a HUD, it is more useful to think: “this element takes, for example, 1.5° horizontally and 0.4° vertically.”
That is the main shift in thinking. We are not designing a rectangle on a screen. We are designing a fragment of the driver’s visual field.
Pixels are still needed for mockups, assets, and implementation. But the meaningful size of a HUD element is not defined by how many pixels it takes. It is defined by the angle it occupies in the driver’s field of view.
That is why HUD work constantly involves terms such as FOV, VID, eyebox, look-down angle, and virtual image plane. For a designer, this is not some strange engineering language. It is the basic coordinate system.
FOV means Field of View. It is the angular size of the area where the HUD image can appear. For example, 10° × 4° or 13° × 6°. If we imagine the spherical grid around the driver, the FOV is not the entire field of vision. It is a small rectangular area of that grid in front of the driver’s eyes. All HUD content lives inside this area.
VID means Virtual Image Distance. It is the distance at which the driver perceives the HUD graphics. Physically, the image is created by a projector and optics, but the eye may perceive it as an object located several meters in front of the vehicle.
Look-down angle is the angle by which the driver needs to lower their gaze from the natural forward line of sight to see the HUD. If the information is placed too low, the HUD becomes almost like an instrument cluster, just moved higher. If it is placed too high, the graphics can start to interfere with the road scene.
Eyebox is the area within which the driver’s eyes need to be positioned for the HUD to be seen correctly. In a real car, the driver does not sit like a camera in a 3D editor. People have different heights, seating positions, seat adjustments, and head positions. This means the HUD must be readable not from one perfect point, but from a realistic range of eye positions.
Virtual image plane is the plane on which the image is perceived. In a simple HUD, this may be one conditional plane. In an AR-HUD, graphics can be perceived closer to the road, lane, object, or navigation maneuver.
HUDs themselves can also be different.
A combiner HUD uses a separate transparent plate. It is easier to control optically, but it often feels like an additional object inside the cabin.
A windshield HUD projects the image through the windshield. It feels more integrated, but the windshield itself becomes part of the optical system, with all its distortions, coatings, and limitations.
A conventional HUD shows basic information: speed, speed limit, navigation, ADAS status, and warnings. It does not attach graphics to the real world, but it still requires thinking in degrees, not pixels.
An AR-HUD connects graphics with the road scene: the lane, maneuver, object, or risk. Here, the designer works not only with interface, but also with spatial perception, latency, sensor accuracy, and driver trust.
A panoramic HUD extends the display area across a larger part of the windshield. It gives more space, but also increases the risk of visual noise in front of the driver’s eyes.
Let’s say a designer is working on HUD navigation.
In Figma, everything looks clean: a large arrow, distance to the maneuver, street name, current speed, speed limit, and ADAS status.
But in a HUD, the questions are different.
How many degrees does the arrow occupy? Where is it placed relative to the line of sight? At what virtual distance is it perceived? Will it remain visible when the driver moves their head? Does it conflict with the road, signs, headlights, snow, glare, or brake lights?
In pixels, the composition may look perfect. In the car, it may turn out to be noisy, too small, too low, too bright, or simply inappropriate for the driving context.
For example, an arrow that is 120 px wide in a mockup does not mean much by itself. What matters is how many degrees it occupies inside the FOV. If the HUD has a field of 13° × 6°, an element that is 2° wide already takes a noticeable part of the horizontal space. If an element occupies 0.2°, it may technically be rendered, but in practice the driver may not be able to read it while driving.
This is the new logic a HUD designer has to get used to: a pixel is a way to render an element; a degree is a way to understand how a human will see it.
HUD changes the designer’s way of thinking.
On a regular screen, the designer controls a surface. In a HUD, the designer controls attention in space.
Pixels remain a technical tool. But the design must be shaped through degrees, virtual distance, line of sight, eyebox, road context, and driver behavior.
A good HUD does not try to show everything. It shows the minimum necessary information, in the right place, at the right moment.
Author
Alexey Dmitriev