Overview
Context & Challenge
Understanding the Problem
Key Insight
Design Framework
Final Design
Reflection
Overview
Redesigning Nothing Diagnostics
Turning a backend QA tool into a user-centered support experience
In November 2025, I joined Nothing as a Product Design Intern, becoming the first product design intern on the team.
During this internship, I worked on improving product experiences across the system. One of the projects I contributed to was redesigning the device diagnostic experience.
Nothing devices include a built-in diagnostic system used to identify hardware issues and determine repair eligibility.
Originally designed for internal QA and service workflows, the tool was later exposed to users as part of the self-service support experience.
This redesign focused on helping users troubleshoot device issues with greater clarity and confidence, without increasing reliance on customer support.
<
week project duration
+
modules
+
steps guided test interactions
The Team
I led the UX redesign of the diagnostic experience while working closely with cross-functional partners.
Product Designer
Product Manager
Engineers
QA
As the product designer, my responsibilities included:
redesigning the diagnostic interaction model
improving system transparency and feedback states
creating a consistent framework across hardware tests
ensuring compatibility with existing system infrastructure
Final Product Overview
Project Context
Diagnostics are part of the device support pipeline, helping identify hardware issues and determine repair eligibility.
As Nothing expanded its self-service support strategy, the diagnostic tool became a customer-facing feature.
However, the interface still reflected its engineering-oriented origins, creating a gap between system logic and user understanding.
The Design Challenge
Supporting self-service without increasing frustration
If the diagnostic process is confusing or difficult to follow, the result is not simply task failure—it can damage the entire support experience.
The design challenge was to increase diagnostic clarity while preserving technical accuracy and system constraints.
System Constraints
Rather than redesigning the infrastructure, my approach focused on improving interaction structure and system transparency.
Original Experience
The system worked technically but failed experientially.
The original After Sales diagnostic tool was built more like a QA backend than a user-facing experience.
No user guidance
No indication of next step
Too technical
Off-brand UI
System uploading
but no estimated time or confirmation
Poor feedback
To understand where the experience broke down, I evaluated the original interface using Nielsen’s usability heuristics.
The findings below highlight how the system reflected an internal QA tool rather than a user-facing support experience.
Heuristic Evaluation
Match between system and the real world
Severity
The navigation is organized around internal system modules such as:
Customer Test
Storage Status
Advanced Features
These labels reflect engineering workflows rather than user goals.
Impact
Users must interpret the system’s structure before starting diagnostics, increasing cognitive load at the very beginning of the experience.
AFTER SALE CIT Home
Enter Key Access
QR Code Result Screen
Test Result List
Manual Test Modules
Uploading / Processing State
Heuristic Evaluation
Match between system and the real world
Severity
The navigation is organized around internal system modules such as:
Customer Test
Storage Status
Advanced Features
These labels reflect engineering workflows rather than user goals.
Impact
Users must interpret the system’s structure before starting diagnostics, increasing cognitive load at the very beginning of the experience.
AFTER SALE CIT Home
Enter Key Access
QR Code Result Screen
Test Result List
Manual Test Modules
Uploading / Processing State
Key Findings
Across the evaluation, three issues emerged as the highest priority for redesign:
Unclear system status feedback
Technical terminology not aligned with user language
Inconsistent interaction patterns across diagnostic modules
These issues became the primary focus for improving the diagnostic experience.
Competitive Analysis
To understand how diagnostic experiences are structured across the industry, I reviewed diagnostic flows from Apple, Samsung, and Google Pixel.
The goal was to identify common design patterns and uncover opportunities for improving the Nothing diagnostic experience.
Key Observations
From this comparison, three dominant diagnostic patterns emerge:
Automated diagnostics
Apple prioritizes automation, reducing user effort but offering limited transparency.
Modular hardware tests
Samsung exposes hardware tests directly, providing coverage but creating fragmented experiences.
Guided troubleshooting
Google focuses on step-by-step support flows, improving clarity but offering fewer hardware diagnostics.
Meanwhile, Nothing's original system mirrors internal QA modules, making it technically comprehensive but difficult for everyday users to interpret.
2 x 2 Matrix
Opportunity for nothing
Position the redesigned experience between system transparency and guided interaction, combining:
clear user guidance
understandable test explanations
comprehensive hardware diagnostics
Design Goals
Improve clarity and transparency of diagnostics
01
Provide step-by-step guidance through hardware tests
02
03
Create a consistent interaction framework across modules
technical coverage
system compatibility
Preserve
04
Key design tradeoffs
I intentionally prioritized:
clarity > speed
predictability > technical density
user confidence > exposing complexity
Interaction Framework
To make diagnostics easier to understand and scalable across multiple hardware modules, I designed a consistent interaction framework that structures how each diagnostic test behaves.
Example Flow
The following example shows how a display diagnostic test follows this framework.
Diagnostic System States
Beyond the basic interaction flow, diagnostics also needed to support several system states that occur before and after tests.
These states ensure the experience remains reliable even when tests are interrupted, completed, or submitted for support.
Resuming and finalizing previous results...
Cancel
Diagnostics may finish at different scopes depending on the user's progress.
The system distinguishes between:
Diagnostics can be interrupted by navigation changes or session breaks.
To make the system feel more reliable, I designed resume states that allow users to:
continue unfinished diagnostics
restore previous progress
finalize pending results without restarting
This helps preserve trust in the diagnostic process.
Hardware diagnostics may take time to complete, especially when interacting with system components.
To prevent users from assuming the test has frozen or failed, the system provides timeout feedback when a test takes longer than expected.
If no response is detected within a certain duration, the interface prompts users with a message indicating that the system is still processing.
This helps reassure users that the diagnostic process is still running and reduces uncertainty during testing.
I treated result submission as a follow-up support flow rather than a single action.
The reporting flow supports:
user consent and agreement
authentication when required
upload progress visibility
success confirmation
retry paths when sending fails
This helps diagnostics connect more clearly to downstream support actions.
individual test completion
full diagnostic completion
This allows results to remain meaningful without forcing all tests into a single completion screen.
Test All
Completion State
Continuity / Resume
System Feedback & Timeout Handling
Report Handoff
Next
Detection timed out without any external device recognizing the NFC-emulated card. Would you like to retry the NFC emulation test?
Yes
Skip
Fingerprint not detected. Have you placed your finger on the fingerprint sensor area?
Yes
Skip
Designing for Scale
To support diagnostics across 7+ hardware modules, I designed a reusable system of components and visual assets instead of creating flows individually.
Audio and Microphone
Cameras and Imaging
Display and Screen
+
hardware modules
Collaboration
To ensure the system worked across real device conditions, I collaborated closely with engineering and QA.
Impact
Reduced cognitive load for users navigating different diagnostic tests
Improved clarity of system feedback during failure scenarios
Lowered the risk of support escalation caused by unclear diagnostics
Reflection
Diagnostics are not used in ideal scenarios.
Users enter the experience when something is already wrong, often with low patience and high uncertainty.
This project shifted my focus from designing individual screens to designing systems that support users through these moments.
I learned that:
clarity is not only about UI, but about how the system communicates its state
consistency across flows is critical to building user trust
scalable design requires thinking beyond single features, toward reusable systems
Designing diagnostics is ultimately not about helping users complete a task, but about helping them regain confidence in their device.
+
reusable diagnostic assets
icons, device visuals, and instruction graphics
+
QA issues tracked and resolved
Across interaction, visual consistency, and edge cases
shuyii0315@gmail.com
resume
Overview
Redesigning Nothing Diagnostics
Turning a backend QA tool into a user-centered support experience
In November 2025, I joined Nothing as a Product Design Intern, becoming the first product design intern on the team.
During this internship, I worked on improving product experiences across the system. One of the projects I contributed to was redesigning the device diagnostic experience.
Nothing devices include a built-in diagnostic system used to identify hardware issues and determine repair eligibility.
Originally designed for internal QA and service workflows, the tool was later exposed to users as part of the self-service support experience.
This redesign focused on helping users troubleshoot device issues with greater clarity and confidence, without increasing reliance on customer support.
<
week project duration
+
modules
+
steps guided test interactions
The Team
I led the UX redesign of the diagnostic experience while working closely with cross-functional partners.
Product Designer
Product Manager
Engineers
QA
As the product designer, my responsibilities included:
redesigning the diagnostic interaction model
improving system transparency and feedback states
creating a consistent framework across hardware tests
ensuring compatibility with existing system infrastructure
Final Product Overview
Project Context
Diagnostics are part of the device support pipeline, helping identify hardware issues and determine repair eligibility.
As Nothing expanded its self-service support strategy, the diagnostic tool became a customer-facing feature.
However, the interface still reflected its engineering-oriented origins, creating a gap between system logic and user understanding.
The Design Challenge
Supporting self-service without increasing frustration
If the diagnostic process is confusing or difficult to follow, the result is not simply task failure—it can damage the entire support experience.
The design challenge was to increase diagnostic clarity while preserving technical accuracy and system constraints.
System Constraints
Rather than redesigning the infrastructure, my approach focused on improving interaction structure and system transparency.
Original Experience
The system worked technically but failed experientially.
The original After Sales diagnostic tool was built more like a QA backend than a user-facing experience.
No user guidance
No indication of next step
Too technical
Off-brand UI
System uploading
but no estimated time or confirmation
Poor feedback
To understand where the experience broke down, I evaluated the original interface using Nielsen’s usability heuristics.
The findings below highlight how the system reflected an internal QA tool rather than a user-facing support experience.
Heuristic Evaluation
Match between system and the real world
Severity
The navigation is organized around internal system modules such as:
Customer Test
Storage Status
Advanced Features
These labels reflect engineering workflows rather than user goals.
Impact
Users must interpret the system’s structure before starting diagnostics, increasing cognitive load at the very beginning of the experience.
AFTER SALE CIT Home
Enter Key Access
QR Code Result Screen
Test Result List
Manual Test Modules
Uploading / Processing State
Heuristic Evaluation
Match between system and the real world
Severity
The navigation is organized around internal system modules such as:
Customer Test
Storage Status
Advanced Features
These labels reflect engineering workflows rather than user goals.
Impact
Users must interpret the system’s structure before starting diagnostics, increasing cognitive load at the very beginning of the experience.
AFTER SALE CIT Home
Enter Key Access
QR Code Result Screen
Test Result List
Manual Test Modules
Uploading / Processing State
Key Findings
Across the evaluation, three issues emerged as the highest priority for redesign:
Unclear system status feedback
Technical terminology not aligned with user language
Inconsistent interaction patterns across diagnostic modules
These issues became the primary focus for improving the diagnostic experience.
Competitive Analysis
To understand how diagnostic experiences are structured across the industry, I reviewed diagnostic flows from Apple, Samsung, and Google Pixel.
The goal was to identify common design patterns and uncover opportunities for improving the Nothing diagnostic experience.
Key Observations
From this comparison, three dominant diagnostic patterns emerge:
Automated diagnostics
Apple prioritizes automation, reducing user effort but offering limited transparency.
Modular hardware tests
Samsung exposes hardware tests directly, providing coverage but creating fragmented experiences.
Guided troubleshooting
Google focuses on step-by-step support flows, improving clarity but offering fewer hardware diagnostics.
Meanwhile, Nothing's original system mirrors internal QA modules, making it technically comprehensive but difficult for everyday users to interpret.
2 x 2 Matrix
Opportunity for nothing
Position the redesigned experience between system transparency and guided interaction, combining:
clear user guidance
understandable test explanations
comprehensive hardware diagnostics
Design Goals
Improve clarity and transparency of diagnostics
01
Provide step-by-step guidance through hardware tests
02
03
Create a consistent interaction framework across modules
technical coverage
system compatibility
Preserve
04
Key design tradeoffs
I intentionally prioritized:
clarity > speed
predictability > technical density
user confidence > exposing complexity
Interaction Framework
To make diagnostics easier to understand and scalable across multiple hardware modules, I designed a consistent interaction framework that structures how each diagnostic test behaves.
Example Flow
The following example shows how a display diagnostic test follows this framework.
Diagnostic System States
Beyond the basic interaction flow, diagnostics also needed to support several system states that occur before and after tests.
These states ensure the experience remains reliable even when tests are interrupted, completed, or submitted for support.
Resuming and finalizing previous results...
Cancel
Diagnostics may finish at different scopes depending on the user's progress.
The system distinguishes between:
Diagnostics can be interrupted by navigation changes or session breaks.
To make the system feel more reliable, I designed resume states that allow users to:
continue unfinished diagnostics
restore previous progress
finalize pending results without restarting
This helps preserve trust in the diagnostic process.
Hardware diagnostics may take time to complete, especially when interacting with system components.
To prevent users from assuming the test has frozen or failed, the system provides timeout feedback when a test takes longer than expected.
If no response is detected within a certain duration, the interface prompts users with a message indicating that the system is still processing.
This helps reassure users that the diagnostic process is still running and reduces uncertainty during testing.
I treated result submission as a follow-up support flow rather than a single action.
The reporting flow supports:
user consent and agreement
authentication when required
upload progress visibility
success confirmation
retry paths when sending fails
This helps diagnostics connect more clearly to downstream support actions.
individual test completion
full diagnostic completion
This allows results to remain meaningful without forcing all tests into a single completion screen.
Test All
Completion State
Continuity / Resume
System Feedback & Timeout Handling
Report Handoff
Next
Detection timed out without any external device recognizing the NFC-emulated card. Would you like to retry the NFC emulation test?
Yes
Skip
Fingerprint not detected. Have you placed your finger on the fingerprint sensor area?
Yes
Skip
Designing for Scale
To support diagnostics across 7+ hardware modules, I designed a reusable system of components and visual assets instead of creating flows individually.
Audio and Microphone
Cameras and Imaging
Display and Screen
+
hardware modules
Collaboration
To ensure the system worked across real device conditions, I collaborated closely with engineering and QA.
Impact
Reduced cognitive load for users navigating different diagnostic tests
Improved clarity of system feedback during failure scenarios
Lowered the risk of support escalation caused by unclear diagnostics
Reflection
Diagnostics are not used in ideal scenarios.
Users enter the experience when something is already wrong, often with low patience and high uncertainty.
This project shifted my focus from designing individual screens to designing systems that support users through these moments.
I learned that:
clarity is not only about UI, but about how the system communicates its state
consistency across flows is critical to building user trust
scalable design requires thinking beyond single features, toward reusable systems
Designing diagnostics is ultimately not about helping users complete a task, but about helping them regain confidence in their device.
+
reusable diagnostic assets
icons, device visuals, and instruction graphics
+
QA issues tracked and resolved
Across interaction, visual consistency, and edge cases
shuyii0315@gmail.com
resume
Overview
Redesigning Nothing Diagnostics
Turning a backend QA tool into a user-centered support experience
In November 2025, I joined Nothing as a Product Design Intern, becoming the first product design intern on the team.
During this internship, I worked on improving product experiences across the system. One of the projects I contributed to was redesigning the device diagnostic experience.
Nothing devices include a built-in diagnostic system used to identify hardware issues and determine repair eligibility.
Originally designed for internal QA and service workflows, the tool was later exposed to users as part of the self-service support experience.
This redesign focused on helping users troubleshoot device issues with greater clarity and confidence, without increasing reliance on customer support.
<
week project duration
+
modules
+
steps guided test interactions
The Team
I led the UX redesign of the diagnostic experience while working closely with cross-functional partners.
Product Designer
Product Manager
Engineers
QA
As the product designer, my responsibilities included:
redesigning the diagnostic interaction model
improving system transparency and feedback states
creating a consistent framework across hardware tests
ensuring compatibility with existing system infrastructure
Final Product Overview
Project Context
Diagnostics are part of the device support pipeline, helping identify hardware issues and determine repair eligibility.
As Nothing expanded its self-service support strategy, the diagnostic tool became a customer-facing feature.
However, the interface still reflected its engineering-oriented origins, creating a gap between system logic and user understanding.
The Design Challenge
Supporting self-service without increasing frustration
If the diagnostic process is confusing or difficult to follow, the result is not simply task failure—it can damage the entire support experience.
The design challenge was to increase diagnostic clarity while preserving technical accuracy and system constraints.
System Constraints
Rather than redesigning the infrastructure, my approach focused on improving interaction structure and system transparency.
Original Experience
The system worked technically but failed experientially.
The original After Sales diagnostic tool was built more like a QA backend than a user-facing experience.
No user guidance
No indication of next step
Too technical
Off-brand UI
System uploading
but no estimated time or confirmation
Poor feedback
To understand where the experience broke down, I evaluated the original interface using Nielsen’s usability heuristics.
The findings below highlight how the system reflected an internal QA tool rather than a user-facing support experience.
Heuristic Evaluation
Match between system and the real world
Severity
The navigation is organized around internal system modules such as:
Customer Test
Storage Status
Advanced Features
These labels reflect engineering workflows rather than user goals.
Impact
Users must interpret the system’s structure before starting diagnostics, increasing cognitive load at the very beginning of the experience.
AFTER SALE CIT Home
Enter Key Access
QR Code Result Screen
Test Result List
Manual Test Modules
Uploading / Processing State
Heuristic Evaluation
Match between system and the real world
Severity
The navigation is organized around internal system modules such as:
Customer Test
Storage Status
Advanced Features
These labels reflect engineering workflows rather than user goals.
Impact
Users must interpret the system’s structure before starting diagnostics, increasing cognitive load at the very beginning of the experience.
AFTER SALE CIT Home
Enter Key Access
QR Code Result Screen
Test Result List
Manual Test Modules
Uploading / Processing State
Key Findings
Across the evaluation, three issues emerged as the highest priority for redesign:
Unclear system status feedback
Technical terminology not aligned with user language
Inconsistent interaction patterns across diagnostic modules
These issues became the primary focus for improving the diagnostic experience.
Competitive Analysis
To understand how diagnostic experiences are structured across the industry, I reviewed diagnostic flows from Apple, Samsung, and Google Pixel.
The goal was to identify common design patterns and uncover opportunities for improving the Nothing diagnostic experience.
Key Observations
From this comparison, three dominant diagnostic patterns emerge:
Automated diagnostics
Apple prioritizes automation, reducing user effort but offering limited transparency.
Modular hardware tests
Samsung exposes hardware tests directly, providing coverage but creating fragmented experiences.
Guided troubleshooting
Google focuses on step-by-step support flows, improving clarity but offering fewer hardware diagnostics.
Meanwhile, Nothing's original system mirrors internal QA modules, making it technically comprehensive but difficult for everyday users to interpret.
2 x 2 Matrix
Opportunity for nothing
Position the redesigned experience between system transparency and guided interaction, combining:
clear user guidance
understandable test explanations
comprehensive hardware diagnostics
Design Goals
Improve clarity and transparency of diagnostics
01
Provide step-by-step guidance through hardware tests
02
03
Create a consistent interaction framework across modules
technical coverage
system compatibility
Preserve
04
Key design tradeoffs
I intentionally prioritized:
clarity > speed
predictability > technical density
user confidence > exposing complexity
Interaction Framework
To make diagnostics easier to understand and scalable across multiple hardware modules, I designed a consistent interaction framework that structures how each diagnostic test behaves.
Example Flow
The following example shows how a display diagnostic test follows this framework.
Diagnostic System States
Beyond the basic interaction flow, diagnostics also needed to support several system states that occur before and after tests.
These states ensure the experience remains reliable even when tests are interrupted, completed, or submitted for support.
Resuming and finalizing previous results...
Cancel
Diagnostics may finish at different scopes depending on the user's progress.
The system distinguishes between:
Diagnostics can be interrupted by navigation changes or session breaks.
To make the system feel more reliable, I designed resume states that allow users to:
continue unfinished diagnostics
restore previous progress
finalize pending results without restarting
This helps preserve trust in the diagnostic process.
Hardware diagnostics may take time to complete, especially when interacting with system components.
To prevent users from assuming the test has frozen or failed, the system provides timeout feedback when a test takes longer than expected.
If no response is detected within a certain duration, the interface prompts users with a message indicating that the system is still processing.
This helps reassure users that the diagnostic process is still running and reduces uncertainty during testing.
I treated result submission as a follow-up support flow rather than a single action.
The reporting flow supports:
user consent and agreement
authentication when required
upload progress visibility
success confirmation
retry paths when sending fails
This helps diagnostics connect more clearly to downstream support actions.
individual test completion
full diagnostic completion
This allows results to remain meaningful without forcing all tests into a single completion screen.
Test All
Completion State
Continuity / Resume
System Feedback & Timeout Handling
Report Handoff
Next
Detection timed out without any external device recognizing the NFC-emulated card. Would you like to retry the NFC emulation test?
Yes
Skip
Fingerprint not detected. Have you placed your finger on the fingerprint sensor area?
Yes
Skip
Designing for Scale
To support diagnostics across 7+ hardware modules, I designed a reusable system of components and visual assets instead of creating flows individually.
Audio and Microphone
Cameras and Imaging
Display and Screen
+
hardware modules
Collaboration
To ensure the system worked across real device conditions, I collaborated closely with engineering and QA.
Impact
Reduced cognitive load for users navigating different diagnostic tests
Improved clarity of system feedback during failure scenarios
Lowered the risk of support escalation caused by unclear diagnostics
Reflection
Diagnostics are not used in ideal scenarios.
Users enter the experience when something is already wrong, often with low patience and high uncertainty.
This project shifted my focus from designing individual screens to designing systems that support users through these moments.
I learned that:
clarity is not only about UI, but about how the system communicates its state
consistency across flows is critical to building user trust
scalable design requires thinking beyond single features, toward reusable systems
Designing diagnostics is ultimately not about helping users complete a task, but about helping them regain confidence in their device.
+
reusable diagnostic assets
icons, device visuals, and instruction graphics
+
QA issues tracked and resolved
Across interaction, visual consistency, and edge cases
shuyii0315@gmail.com
resume
shuyii0315@gmail.com
resume