Feasix AI

Summary

On a control screen, the most important thing was not showing all the information. It was letting the operator judge, first, whether they can still control the robot.

20

Final screens

Output · 1920×1080 · single dark theme

30

Components

Output · multi-axis state variants

220

Design tokens

Output · primitive · semantic · spacing · radius · text

Hongik University × Feasix AI industry–academia research – screen design for the base-layout (team A) track in phase two, and the merge of both teams' work

Overview

I designed the screen an operator uses to drive a patrol robot through an underground car park. The operator sits in a control room and drives with a gamepad and a PC monitor, watching several camera feeds, driving state, warnings and licence-plate recognition for hours at a time. The screen is a fixed 1920×1080 with a single dark theme for a dark room.

The formal study title translates as "Foundational design for improving the remote-driving UX/UI of a Vision AI mobile robot". It runs in two phases: phase one (Jun–Jul 2026) set out the problems and the design criteria; in phase two (Aug–Oct 2026) a base-layout team and a wide-layout team designed in parallel and then merged. I lead screen design for the base-layout track in phase two.

There are two dates. I joined the project in June 2026, at the start of phase one; my formal appointment as an Undergraduate Student Researcher at Hongik University began in August 2026. The first date is when I joined the work, the second is when the appointment started.

Problem

Phase one recorded three UX issues.

1. The camera views had no clear roles or priority. Front, rear and auxiliary cameras sat at similar weight, so the eye kept travelling between them.
2. Driving information and warnings had weak visual hierarchy. Figures watched continuously, like speed and distance, were not separated from warnings that demand attention at once.
3. Plate-recognition results didn't lead to the next action. The result is shown, but the next move – reshoot, check by hand – is not.

Phase one concluded that the current interface increases the operator's cognitive load and decision burden. That conclusion came from the literature and from screen analysis. It is not a measurement.

Key decisions

1. 01Fix the width of the top buttons at their ‘on’ state

   While driving, operators press buttons by remembered position, not by looking. If a button's width changes with its state, its neighbours move too.

   →Widths are pinned to the ‘on’ state (AEB 186px, REC 260px). Across all eight state combinations, no button's x position moves by even 1px – measured from the delivered file.

2. 02The front camera biggest, the minimap only when asked for

   The first piece of stakeholder feedback was “make the front camera the largest”. An always-on minimap was covering the view needed to drive.

   →The front feed grew to 780×616 – 2.4× the area, measured from the file – and the minimap moved into a popup behind a MAP button.

3. 03A red background means only ‘unregistered vehicle’

   One colour should mean one thing. Based on the recognition performance confirmed with the developer, telling registered from unregistered mattered more to the operator than the rare recognition error.

   →Unrecognised or misread cards sit on a neutral surface with a coloured dot; a red card means one thing – a vehicle that isn't registered.

4. 04The alert bar always holds its 56px

   Layout moving during control is the worst case; video mustn't jump every time an alert appears.

   →With no alerts it shows “Normal · patrolling” and keeps its place. The cost – video height down from 888px to 852px – was written down as a deliberate trade.

›Five more decisions

• The card's title became the plate number, not the status word – in a plate-recognition panel, the cards were titled "Unregistered" and "Unrecognised" while the number itself was nowhere on screen. The title is now the recognised number, with status demoted to a tag on the right. A failed read says "Plate not recognised".
• The alert log's hierarchy was inverted – the timestamp was the largest thing and what happened was the smallest. Now: message 16px, detail 12px, time 12px right-aligned, and an absolute time (02:14) became a relative one (3 minutes ago). An operator needs "what happened" before "at what time".
• One way in for each function – settings lived in both a large window and the right panel; the alert log lived in both a popup and the panel. Settings are now one window, the alert log one popup in the top bar. Two entry points make the user decide which one every time.
• Popovers grow out of the button that opened them – windows opened below the alert bar, so you couldn't tell which button they came from. A window's top now aligns to the button's top (y=20) and centres on the button, keeping the same icon in its header. Only irreversible actions – reconnecting, handing over control – open a centred modal.
• What survives being collapsed – three options were compared: a 56px rail, hiding it entirely, and a pill floating over the video. Hiding it entirely wins 96px of video and loses "how many are queued right now". The rail won: collapsed, it still shows whether recognition is on and how many unregistered vehicles are pending.

Process

Research

• Narrowed to remote driving – the macro journey is onboarding → preparing → remote driving and monitoring → ending. The main control tasks and UX issues concentrated in remote driving, so that stretch became the critical journey. It was split into three tasks – driving and situational awareness, plate checks, connectivity and exceptions – each broken into a five-step micro journey, tabulating the activity, the information needed, the operator's judgement, the current problem and the implication.
• Three insights from the journey analysis – operators spend more attention watching several screens at once than on driving the vehicle. Making the current state clear matters more than presenting the result itself. When connectivity fails, operators check whether the vehicle is safe and still controllable before they look for the cause.
• Three design criteria – camera hierarchy and expanded driving field of view; grouping information by task purpose; support for unrecognised and emergency situations. Set in phase one from eight prior studies and four industry cases, they became the standard for all of phase two's screen design.
• A quick phase-one usability test – about ten people, with an RC car, several cameras, OBS Studio and the Figma UI combined. The vehicle was kept out of sight so it had to be driven from the screen alone. Four things were checked: field of view, sense of control over the vehicle, task feedback and emergency handling.
• Development constraints taken before design – a technical meeting with the developer established what was buildable before screens were drawn, so constraints were inputs rather than obstacles found afterwards. Six items of stakeholder feedback were tracked one by one to completion.

›Eight prior studies and four industry cases

The literature and cases behind each design criterion:

• 01 Camera hierarchy and a wider driving view – Gnatzig (2013), Tener & Lanir (2022), Wolf (2025), and Hyundai–Kia's SVM. Gnatzig proposes presenting driving state through a fused sensor display rather than a single feed. SVM is a production case that merges four cameras into one view with distortion correction, viewpoint transformation and compositing.
• 02 Grouping information by task purpose – Wolf (2025), Kettwich (2021).
• 03 Support for unrecognised and emergency situations – Tener & Lanir (2025), Parasuraman (2017), Fernride. Parasuraman shows network state as a colour band around the video. In Tener & Lanir (2022), 14 expert interviews name the missing sensory feedback of being physically separated from the vehicle as a main difficulty of teleoperation.

The four industry cases: Vay (commercial teledriving, where the operator drives on screen and sound alone), Hyundai–Kia SVM, Ottopia (a multi-screen teleoperation console) and Fernride (network bonding and prediction, stopping and calling for help on edge cases).

Design

• Six areas – top navigation, status, camera view, driving and control bar, map, plate-recognition panel.
• State by colour only – on and off differ only in colour; a button's position never changes.
• Three alert levels – general (toast), urgent (red gradients at the top and bottom edges), and log.
• Fewer states – the right panel went from eight states to four. The camera layout rearranges itself when reversing, and ultrasonic distance shows in millimetres, turning yellow at 800mm and red at 180mm. Both thresholds are design values.

Design system

Two teams designed in parallel, and their output was merged into one token system. The other team's design language was kept; only its structure was rebuilt into our system. 431 hard-coded colours were bound to tokens.

›220 tokens, and how two teams' work was merged

Tokens are split into primitive 139 · semantic 44 · spacing 15 · radius 6 · text 16; adding amber and blue ramps took primitives from 128 to 139. The semantic layer had been four empty shells, all of them white. It was rebuilt as 44 tokens that reference primitives. The layers exist for the cost of change – change a value in one place and every screen follows.

431 hard-coded colours were bound to tokens. An audit script then reported zero direct primitive references, zero unstyled text and zero clipped text; the 274 items left unbound are listed as deliberate exceptions.

Moving everything at once by script caused damage of its own. 11 lost screens and 20 labels were restored and 50 clipped text layers re-measured. Edits to a master sometimes didn't reach the screens: the top bar's eight variants carried instance overrides, so the change had to be applied directly in 32 places. Now overrides are checked before a master is touched. Where a hidden node had dropped out of the tree and could not be edited, the node was deleted and recreated in the master so its id changed and the override broke. All of these numbers are the scale of the output.

Results

0px

Layout shift across 8 state combinations · measured in file

2.4×

Front-camera area · measured in file

6 / 6

Stakeholder feedback resolved · output

Six phase-one concepts became 20 final screens. The final deliverables: 20 screens, 30 components, 220 design tokens. Merging the two teams' parallel work absorbed 431 hard-coded colours into this token system. Both layouts – base and wide, each in light and dark – were handed to the developer on September 2, 2026.

Where a person steps in

• What the AI does – the plate-recognition AI classifies each vehicle as registered, unregistered, uncertain or unrecognised and shows the result on screen.
• What the person does – the operator makes the final call on what the recognition returned. When recognition fails, the operator drives the robot back to that spot and reshoots. Design criterion 03 (support for unrecognised and emergency situations) put a reshoot control on screen, and connectivity faults and emergencies are flagged immediately with a toast so a person can judge right away.

Reflection

What held up

• Development constraints are inputs before design, not obstacles after it. The technical meeting settled what was buildable before any screen was drawn.
• On a screen under constant watch, coordinates must not depend on state. For someone pressing buttons by remembered position, the position matters before the information. Across eight state combinations, nothing moves.
• Colour is allocated by frequency × need to act. Strong colour on common events buries the ones that matter.
• Merging is translation, not copying. The other team's design language stayed; only the structure moved into our system.
• An exception screen starts with safety, not diagnosis. The journey analysis showed operators check whether the vehicle is controllable before they look for the cause, so the first line on screen answers that.

What failed

• I assumed that showing state well would carry the next action with it. It didn't. The plate panel showed status words and not the plate number. Presenting a result and telling someone what to do next are different jobs.
• I assumed a bulk change was finished once the script ran. Instance overrides and clipped text appeared in quantity. 11 screens and 20 labels had to be restored and 50 clipped text layers re-measured. Errors made by automation are only caught by automation.
• I assumed more layout combinations would make comparison easier. The more there were, the harder it became to see what had changed. It came back to changing one thing at a time.

What I would test next

• Cognitive load and error rates. Eye-tracking is in progress; the numbers go on this page when it produces results.
• Which layout – base or wide – is actually better to drive with. A second round of user research will answer it.
• Whether giving up 36px of video height to keep the alert bar always present was the right trade. Which one operators would choose is still unknown.
• Whether the collapsed rail keeps enough. Showing only recognition state and the count of unregistered vehicles has not been tested.