XIAN Action Camera

Context

XIAN is a new action camera companion app being developed in parallel with the camera hardware in Thinkware's R&D pipeline. I joined as the sole UI/UX designer, working closely with the BA team in an environment where requirements were still loose, hardware was still evolving, and the firmware contract was being negotiated through an outsourced partner whose own delivery cadence kept shifting.

This is my second IoT project at Thinkware, after Dash Cam LINK. Where Dash Cam LINK was about restructuring a legacy product, XIAN is about defining one before it exists.

Problem

At the early stage there was no clearly defined product direction. The feature set was being influenced by multiple references — particularly GoPro and Insta360 — without a clear understanding of who the target user was or what the core value of XIAN should be. Over time the product began to position toward non-professional users for casual content creation, but that direction wasn't yet consistently reflected in product decisions.

The challenge wasn't designing features. It was bringing structure to an undefined and constantly shifting system, while five compounding frictions made every decision feel like building on shifting ground: unclear product direction, feature expansion without focus, lack of UX foundation, evolving system constraints, and limited data and alignment.

Insight

I started from the user moment rather than the feature list. Non-professional users don't engage with action cameras as a system of features. They use them in short, spontaneous moments where a good shot matters more than configuration. The most important moment isn't during recording — it happens right after, when users realise they've captured something worth keeping.

That single sentence let us deprioritise a long list of speculative features and centre the design on three core flows.

System thinking

I analysed XIAN as a multi-layered system rather than an app. Four components, each with their own constraints:

• The user, expecting fast and simple interaction.
• The app, the interface and intermediary between user and hardware.
• The camera hardware, with evolving firmware delivered by an outsourced partner.
• The storage layers — SD card, app storage, phone gallery.

The data flow runs across all of them: footage on the SD card → transferred to the app on connection → exported to the phone gallery for sharing. Every step introduces latency, dependency, and potential failure. The constraints I had to design around were connection instability, slow and unreliable data transfer, and lack of system feedback that left users uncertain whether downloads had actually completed.

Three core flows became the experience anchor — connecting to the camera, capturing content, retrieving and saving media. Editing and community features were explicitly deprioritised as secondary so they wouldn't interrupt the core flows.

Decisions

Step 01

Selection mode

User picks media in the gallery and taps Download. Nine items selected here become the queue passed to the next step.

Step 02

Downloading sheet

A full-screen sheet surfaces the queue. The user can swipe to remove an item or drag to reorder priority while the first download runs.

Step 03

Gallery + collapsed bar

Collapse drops the sheet to a bottom bar so the gallery (and the rest of the app) is usable through every transfer. Tapping the bar expands the sheet again.

Step 01

Live view

Step 02

Change mode

Step 03

Settings

Step 04

Recording

Execution

I conducted competitive research on Insta360 and GoPro to understand how the leaders position for prosumer versus professional users, alongside user research to ground the non-professional direction. From there I built the missing UX foundation — interaction design across camera connection, control, and media flows; a design system built for scale and cross-platform parity (Kotlin on Android, UIKit on iOS), prioritising structural stability and maintainability over visual polish; UX documentation and end-to-end flow definitions; and contributions to product direction by simplifying scope and clarifying concepts such as the in-app editor.

Design System

XIAN's design system is built for scale and flexibility — portable across both Kotlin on Android and UIKit on iOS. Type sits on each platform's native system font so dynamic font scaling can ship later without retrofitting the foundation. Buttons, chips, data-entry fields, dialogs and lists are defined first; everything else is built off these primitives so the system stays small, predictable, and stable as the product evolves.

And 20+ More Components

Portable across Kotlin Android · UIKit iOS

Engineering targets are Android (Kotlin) and iOS (SwiftUI), with firmware delivered by an outsourced partner working through the PM. I also wrote SRS documents for several XIAN features — a BA-adjacent responsibility well beyond a typical designer scope.

Outcome