Gotion, 2025 • Enterprise Platform
Type
Web & Mobile
Tools
Figma
Role
Sole Product Designer
Status
Launched in 2025
OVERVIEW
A 0–1 platform designed to manage energy storage and EV charging products for internal teams.
1.1
Monitor dashboard.
IMAGE
1.2
Data Analytics.
IMAGE
1.3
OTA update.
IMAGE
1.4
Repair order list, desktop & mobile.
IMAGE
1.5
Repair order detail, desktop & mobile.
IMAGE
1.6
Repair record & local authorization list.
IMAGE
CONTEXT
An innovative new type of hardware product that integrates energy storage and EV charging capabilities.
It started with a visionary concept.
“This is one of the visionary charging concepts that Volkswagen hopes will expand the charging infrastructure over the next few years.”
2.1
Volkswagen Group newsroom.
IMAGE
Hardware took the lead.
An innovative new type of hardware product was developed and deployed, which integrates energy storage and EV charging capabilities.
At that time, there was no other direct competitors of this product category in the market.
2.2
Hardware product deployment.
IMAGE
Software behind the full lifecycle of hardware products.
Software need to be clearly defined and specified as supporting services to operate, monitor, and scale hardware products in real-world deployments.
2.3
System architecture.
IMAGE
MY ROLE
The sole software product designer within a small, multidisciplinary team.
Start small, dream big.
Started from around 20 members, we believe in innovating and creating the next generation of energy storage and EV charging product.
3.1
Gotion Shanghai team in 2021.
IMAGE
Cross-functional collaboration is the key.
I worked closely with industrial designers, brand designers, engineering team, manufacturing team, marketing and sales team across different countries.
3.2
Working with cross-functional teams.
IMAGE
Design software, based on hardware.
Understanding the industrial design philosophy is extremely important for building the software design language and foundations.
3.3
Industrial design prototypes iterations.
IMAGE
PROBLEM
A system-level software solution is needed.
Fast-evolving complexity.
At early stage, internal teams relied on fragmented tools and manual processes to monitor product status, diagnose issues, and manage field operations. As the number of products and stations grew, these workflows became increasingly inefficient and error-prone.
So a customized platform was urgently needed for everything related to hardware products.
PROBLEM ANALYSIS
Challenges from 0-1 platform.
Multiple user roles with different priorities
High-frequency daily usage requiring fast decision-making
Complexity from global deployment.
Multi-language and cross-cultural usability required
Adaptation to both early-stage trials and large-scale deployments
Distributed cross-functional teams across different countries
Constraints from innovative project.
No direct market reference for this type of integrated hardware product
Limited dedicated design resources as part of an innovation initiative
No existing design system or foundation at start
DISCOVERY
Finding clarity through progressive discovery.
Understanding scope within ecosystem.
In the hardware-driven product development process, it is essential to understand the design scope within internal ecosystem context.
6.1
Design scope positioning.
IMAGE
Bringing structure to requirements.
Without existing design frameworks or clear requirements, I built understanding through continuous cross-functional collaboration.
Technical constraints from Engineering Team
Real-world usage issues from Operation Team
Customer expectations from Sales Team
Design for the “early stage”.
At the early stage of the product lifecycle, trade-offs were inevitable, especially relating to real-world operations and deployment.
5.1
Hardware products in mass production.
IMAGE
TRADE-OFFS
Strategy & Delivery
How to move fast without compromising the future of the product.
Innovation vs Stability
Speed to Market vs Scalability
Short-term Features vs Long-term Architecture
Hardware & Software
Designing software under hardware-based limitations and challenges.
Physical Constraints vs Digital Experience
Embedded Capabilities vs Platform Responsibilities
Hardware-driven Decisions vs Software Design Autonomy
Fleet & Platform
Balancing local needs with a unified platform experience.
Deployment Flexibility vs Control Consistency
Regional Compliance vs Unified Management
Unit Customization vs Platform Standardization
UX & Ops
Where ideal user experience meets real-world operations.
Customer Experience vs Technical Feasibility
Operational Efficiency vs Platform Process
Automation vs Human Oversight
STRATEGY
Making decisions in complex, evolving real-world environment.
Business goals & Design goals.
Design decisions acted as a bridge between business strategy and real-world execution, ensuring that software, hardware and operations evolved together.
6.1
Business goals → Design goals.
IMAGE
An untypical decision-making flow.
Rather than following a predefined linear framework, I used an adaptive and iterative approach — a continuous discovery and delivery process.
Design decisions were made progressively through continuous exploration, validation and refinement, shaped by evolving hardware capabilities, real-world deployment feedback and user expectations.
6.2
Decision-making factors.
IMAGE
Design principles shaped by uncertainty.
Without clear requirements, mature reference or stable constraints, I developed a set of practical design principles through continuous iteration, cross-functional collaboration and real-world deployment.
These principles guided day-to-day decisions across multiple products, platforms and regions, balancing innovation, scalability and operational realities.
DESIGN PRINCIPLES
Design in Ambiguity
Embrace and adapt to emerging requirements.
Design with Reality
Align real-world user flow with digital experience.
Design for Hardware
Deconstruct and comply with hardware capabilities.
Design as Process
A continuous decision-making process of trade-offs.
PROCESS
An exploratory design process adapted to reality.
An adaptive loop.
The circular approach reflects how design evolved quickly alongside uncertainty and change without blocking progress. Each phase informed the next, while new constraints or learnings could trigger a return to earlier stages.
7.1
High-level design process.
IMAGE
Key iterative milestones.
The major design decisions were adjusted at each milestone stage, focusing on moments where constraints shifted and meaningful trade-offs were required, to meet large-scale and long-term expectations.
7.2
Key milestone stages and goals.
IMAGE
Design patterns → Systemized solutions.
Design standards emerged after design patterns were repeatedly tested and validated across different use cases. These patterns were gradually consolidated into a scalable design language and component system.
7.3
Design system emerging organically.
IMAGE
SOLUTION
A “control center” to fix chaos for all.
A platform for everything.
A unified software platform supporting the deployment, configuration and user experience of hardware products, spanning internal operations, field management and end-user charging across web and mobile.
8.1
Information architecture.
IMAGE
A coherent physical & digital experience.
User experience is shaped by the continuous interaction between physical hardware and digital systems.
Users move seamlessly between touching the device, observing its physical state, and interacting with software interfaces that monitor, configure, and operate it.
8.2
Physical & digital touch points.
IMAGE
An intuitive and role-based user flow .
The core user flow was designed to align physical device states, system logic and user intent into a predictable, end-to-end experience that supports both daily operation and long-term vision.
8.3
Core flows.
IMAGE
A transparent, recoverable and safe firmware update experience.
“Over-the-Air” makes big difference.
Remote firmware updates are a critical capability for hardware customization, regulatory differences and large-scale deployment, ensuring that devices could maintain and evolve in the field across regions without disrupting operations or compromising reliability.
9.1
Hardware OTA update capability.
IMAGE
Focusing on stability.
The ultimate design goal for OTA update was to significantly reduce on-site efforts and enable remote upgrade for hardware capability at scale.
Making system state and upgrade readiness explicit
Reducing the risk of device downtime or failure
Supporting rollback and staged upgrades
Clearly communicating progress, impact, and exceptions to operators
Clarifying update process.
Broke down the OTA update journey into clear, sequential steps, giving a better understanding of what to expect and reducing uncertainty throughout the update process.
9.2
Firmware update process.
IMAGE
“Double-check” ensures safety.
Use two verifications to prevent unintended actions and ensure the device was ready, giving greater confidence in a safe and reliable upgrade.
9.3
Two verification stages.
IMAGE
Clarifying every status.
Define clear, contextual label for every update status, helping quickly understand what was happening, whether their action was needed, and when the process was complete.
9.5
Every status in every stage.
IMAGE
Updating as a group.
Adopt group updates to reduce repetitive actions when managing multiple devices, making large-scale updates faster and more efficient for users.
9.4
Update list interaction.
IMAGE
9.6
Update list collapsed.
IMAGE
9.7
Update list expanded.
IMAGE
An end-to-end workflow connecting real-world issues with digital tracking and decision-making.
Issues across the product lifecycle.
As the number of deployed devices increased, hardware faults, configuration issues and field failures became unavoidable.
The issue and service management workflow was designed to support fault reporting, diagnosis, repair coordination and resolution across distributed teams, ensuring that every problem can be identified, assigned, resolved, and audited.
10.1
Products in manufacturing.
IMAGE
Focusing on troubleshooting.
The ultimate design goal for this workflow was to significantly reduce operational blind spots and enable scalable after-sales support.
Clear fault reporting linked to device context
Status visibility across different workflow stages
Role-based flows for different user types
Traceability from issue creation to closure
Solution iterating with workflow evolving.
There are different workflow requirements and operation priorities during each product lifecycle stage, so a specific solution is needed for every stage.
10.2
Solution v1.
IMAGE
10.3
Solution v2.
IMAGE
10.4
Solution v3.
IMAGE
IMPACT
Created structure where there wasn't much structure before.
Establish the design foundation.
From an exploratory concept to an evolving operational ecosystem, the platform provided the software foundation needed to deploy, operate, maintain, and scale a new generation of energy storage and charging products.
IMPACT
Built the Foundation
Established the UX foundation for a new hardware category with no mature product precedent.
Scaled Operations
Shifted from reactive, device-by-device management toward a systematic and scalable model.
Enabled Evolution
Created flexible experiences evolving alongside changing capabilities and requirements.
Unified the Ecosystem
Established shared interaction patterns and design language across web and mobile products.
REFLECTION
Making trade-offs, and building systems adapting to change.
Design for the product it is becoming.
What started as a loosely defined software initiative eventually became an interconnected ecosystem spanning hardware, software, and operations. My role evolved with it—from designing individual experiences to helping establish the design language, interaction patterns, and system foundations that connected them.
Designing Without a Clear Starting Point
Research is not always about finding a definitive answer before designing; sometimes it is about progressively reducing uncertainty through design.
Designing for Change Rather Than a Fixed State
The goal was no longer to design the perfect state, but to design a system that could continue to evolve.
Design Work Flow Can Be Quite Flexible
A good design approach is not defined by how closely it follows an existing process framework, but by how clearly it adapts to reality situations.
Knowing When to Standardize
Design language was summarized after development, and the design system is an outcome of validation, not an assumption at the beginning.