Back
ExpertLumi
ExpertLumi
Designing lighting
as an interface
Turning system states into intuitive visual feedback through light.
WORK AT
ASUS
TYPE OF WORK
Hardware–Software Integration
DURATION
2025-2026
CONTEXT
ASUS ExpertLumi uses a laptop light strip to signal system events, helping users notice important changes beyond the screen.
As use cases grew, lighting definitions became inconsistent. I established shared lighting behavior rules and drove the development of a WYSIWYG lighting tool to simplify handoff and speed up development.
THE PROBLEM
◆ System: Lighting and UI feedback lacked shared rules for new scenarios.
◆ Process: Gaps between design specifications and actual lighting behavior required repeated clarification and adjustments with engineering.
◆ Experience: Whether users would notice and understand light signals during focused work was still unverified.
WHAT I DID
◆ Defined shared rules: Clarified the roles of lighting and UI feedback, establishing a common design basis across scenarios.
◆ Partnered with engineering : Initiated requirements for a lighting editor and worked with engineers to enable direct preview and adjustment.
◆ Tested and refined: Used hardware testing to identify when signals went unnoticed, then refined the lighting behavior.
RESULT
95%
Signal Noticeability
95% of participants noticed the lighting signal, and 100% of those who noticed it correctly understood its meaning.
10+
Scenarios Built on Shared Lighting Tokens
Defined reusable lighting rules as development tokens, enabling new and similar scenarios to reuse standardized parameters and behaviors.
-60%
Design-to-Engineering Handoff Time
Built a lighting editor that streamlined configuration and review, reducing handoff and iteration time between design and engineering by 60%.
LIGHTING BEHAVIOR IN CONTEXT
These examples show how the lighting rules translate into device feedback. Each signal is designed around a specific event, the user’s immediate need, and its relationship with on-screen information.
Power on
User need: Know startup has begun.
Design decision: Confirm startup without implying Windows is ready.
How it came together
3 min read · 6 sections
THE FULL CASE STUDY
01
Learning from Existing Feedback Patterns
I compared how products across gaming, smart home, appliances, and mobility used lighting alongside other feedback channels. I focused on how these channels communicated events, confirmed states, and guided users’ next actions.
These observations informed four considerations for ExpertLumi: feedback roles, state transitions, attention demand, and the handoff from lighting to on-screen guidance.
02
Defining shared feedback rules
For each event, I considered what the user was doing, what they needed to understand or do, and what could happen if they missed the signal.
I used these questions to define two aspects of the feedback strategy: how actively it should draw attention, and whether it should be momentary, continuous, or repeated.
Event & Context
Who or what triggered the event? Did the user expect it? Where was their attention?
User Need
Confirm an action, understand a state, or take action?
Feedback strategy
How actively and for how long? What are the roles and timing of lighting and UI?
Two dimensions shape the feedback strategy
Attention demand : Describes how actively the feedback should attract attention.
Feedback persistence : Describes feedback duration and repetition.
These are typical strategies, not fixed categories. An event may shift strategies across stages, and persistent feedback may be continuous or repeated.
Once the feedback strategy was defined, I determined whether the event needed lighting, UI, or both, and clarified what each should communicate.
For events requiring lighting, I specified the behavior through four dimensions: color, motion, timing, and spatial coverage.
Feedback Channels
Lighting, UI, or both? What should each communicate?
Color
Which color communicates the intended meaning ?
Motion
How does the light change or move ?
Timing
How long, how often, and when to stop?
Spatial
Where does it appear, and how much of the strip lights up?
The feedback channels work together to communicate the event. When lighting is used, its meaning depends on the combined behavior and context.
03
Applying the Rules：Low Battery
I applied the framework to a low-battery event, where users need to notice the change and connect power before their work is interrupted. Lighting draws attention to the event, while the UI explains the battery status and the next action. The specifications below define the signal’s color, motion, timing, and spatial coverage.
Feedback Channels
Lighting makes the low-battery event noticeable; the UI provides the remaining battery level and prompts the user to connect power.
Color
Red ( # DF0000)
signals low battery and the need to connect power, consistent with the existing light-guide indicator.
Motion
Blink: alternate between illuminated and dark states.
ON
→
OFF
→
ON
→
OFF
→
ON
→
OFF
Timing
Three flashes within one 5750 ms sequence · Once per trigger
On
Off
Flash 1
Flash 2
Flash 3
0 ms
5750 ms
Total sequence: 5750 ms
Spatial Behavior
LEDs 04–24 illuminate together; the remaining LEDs stay off
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Illuminated range: LEDs 04–24
04
Making the Behavior Testable
The shared rules described how the lighting should behave, but reviewing that behavior still required repeated clarification between design and engineering. I proposed an internal editor so we could configure lighting parameters, review playback, and check the result on hardware.
Under a tight deadline, engineering preferred to continue with Excel-based scripts. To make the proposal concrete, I used Claude to build an interactive prototype demonstrating parameter editing and playback. It gave the team a working example to discuss and helped us agree on developing the editor.
Engineering implemented the tool. I defined its interaction requirements, checked the editing and playback behavior against those requirements, and used it to inspect and refine lighting on the device. This gave us a practical way to test the rules against actual hardware behavior.
Core requirements
Data format: Specify each LED’s color and the duration of each step.
Editing workflow: Configure, save, and export lighting scripts.
Playback: Play scripts sequentially to review lighting behavior.
Whiteboard & Requirements: Editing, saving, exporting, and playback requirements, mapped with engineering.
ASUS LED Lighting Helper
File
Player
Editor
About
LED script editor
charge_v0829.csv
Editing line 3
Frame parameters
Duration (ms)
10
ms
Color (RGB)
Brightness (%)
LED 01
B6F4FF
2
%
LED 02
B6F4FF
5
%
LED 03
B6F4FF
8
%
LED 04
B6F4FF
10
%
LED 05
B6F4FF
0
%
LED 06
B6F4FF
0
%
LED 07
B6F4FF
0
%
LED 08
B6F4FF
0
%
LED 09
B6F4FF
0
%
LED 10
B6F4FF
0
%
LED 11
B6F4FF
0
%
LED 12
B6F4FF
0
%
LED 13
B6F4FF
0
%
LED 14
B6F4FF
0
%
LED 15
B6F4FF
0
%
LED 16
B6F4FF
0
%
Line ID
Add
Insert
Delete
Read
Overwrite
Fill all
B6F4FF
0
%
Apply
Script frames
Color / brightness per LED
Line
Duration (ms)
LED 01
LED 02
LED 03
LED 04
LED 05
LED 06
LED 07
LED 08
0
10
B6F4FF
2%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
1
10
B6F4FF
2%
B6F4FF
5%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
2
10
B6F4FF
2%
B6F4FF
5%
B6F4FF
8%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
3
10
B6F4FF
2%
B6F4FF
5%
B6F4FF
8%
B6F4FF
10%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
4
10
B6F4FF
0%
B6F4FF
2%
B6F4FF
5%
B6F4FF
8%
B6F4FF
10%
B6F4FF
15%
B6F4FF
0%
B6F4FF
0%
5
10
B6F4FF
0%
B6F4FF
0%
B6F4FF
2%
B6F4FF
5%
B6F4FF
8%
B6F4FF
10%
B6F4FF
15%
B6F4FF
20%
6
10
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
2%
B6F4FF
5%
B6F4FF
8%
B6F4FF
10%
B6F4FF
15%
7
10
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
0%
B6F4FF
2%
B6F4FF
5%
B6F4FF
8%
B6F4FF
10%
Interactive Prototype: An interactive prototype built with Claude to discuss the proposed editing and playback workflow.
Interactive Prototype: The engineering-built editor, reviewed against the agreed requirements and used for hardware testing.
06
Learning from User Testing
I tested five lighting scenarios on hardware with 20 internal participants to assess noticeability and comprehension.
Low battery · Charging · Mute · Important email · Performance Mode
I extended the duration of system-initiated lighting alerts to give users more time to notice the light and connect it with the UI notification.
In the follow-up test, noticeability increased to 95%. I updated the existing Timing rules to consider users’ attention to the accompanying UI notification when setting lighting duration.
06
Helping Users Discover and Use ExpertLumi
To connect on-screen settings with the physical lighting experience, I introduced two types of video guidance: one to show users where the light bar is, and another to explain how to enable its features and when the effects appear.
Locate the Light Bar
A video at the top of the settings page helps users identify the light bar’s location on the device.
Locate the Light Bar
A video at the top of the settings page helps users identify the light bar’s location on the device.
06
Conclusion
On the surface, ExpertLumi was a lighting feature. The real challenge was making a single physical light strip clearly communicate different device states. Shared lighting rules brought consistency across scenarios, while turning those rules into development tokens and a lighting editor made the system reusable for future scenarios without redefining each effect from scratch.
What I'd do differently
I would evaluate noticeability and comprehension as separate measures from the start. In testing, everyone who noticed the lighting signal understood its meaning, but a small number of users missed the signal entirely.
Next, I would test under more realistic conditions — different viewing angles, ambient lighting, and competing notifications — to see how well the signals hold up in real-world use.
What I'd still defend
I would still establish shared lighting rules first and push for an internal tool to test and fine-tune the lighting behaviors.
For a system that requires repeated parameter adjustments and validation on the actual device, documentation alone isn't enough. A hands-on testing tool allows design and engineering to validate behaviors, tune parameters, and review results faster — turning the lighting rules into part of the development workflow rather than leaving them as design specifications.
THE FULL CASE STUDY