SORA UI ReadinessDesign handoff checklist
Export Markdown
SORA App · UI handoff · 2026.08.26

Design inputs for implementation

A focused checklist of the design inputs still needed before reusable Android and iOS UI components can receive final sign-off. The first implementation pass is Android XML + ViewBinding.

Current assessment

Theme and component scaffolding can start

Colors, Light/Dark modes, spacing, radii, and most component visuals are defined. Final sign-off still depends on fonts, production assets, complete component states, and a small set of conflicting component dimensions.

Platforms: Android + iOS First pass: Android XML + ViewBinding Languages: English + Chinese Orientation: Portrait only
ReadyTheme, tokens, and component scaffolding
ConflictsComponent dimensions in Figma and the Style Guide
MissingFonts, assets, states, and layout rules
01 · Implementation inputs

What design still needs to provide

The first implementation pass can start. The remaining items affect component sign-off, not the initial foundation.

Area
Status
Available now
Still needed
Colors & theme
Ready
Semantic colors and Light/Dark mappings
Confirm whether Welcome always remains dark
Typography
Partial
Hierarchy and 14 documented text styles
Font files, weights, licenses, Chinese fallback, and control text roles
Spacing & shape
Ready
Spacing, radii, and base control-size scales
Resolve the component dimensions listed under Spec conflicts
Components
Partial
Most visual variants and initial View structure
Pressed, disabled, loading, error, selected, and long-copy behavior
Assets
Needs input
Product colorway values and placement references
Source vectors, product imagery, tint, crop, naming, and dark-mode rules
Effects
Needs input
Raw shadows visible in a few frames and images
Identify which effects belong in the shipped UI
Layout & accessibility
Partial
390-point portrait reference layout
Responsive widths, larger text, touch targets, and platform accessibility behavior
How the sources are used

Figma is the visual and geometry reference. The Style Guide defines tokens, typography, and motion. The dynamic mock demonstrates flow and state changes only; it is not used for exact specification comparisons. System UI, permissions, navigation gestures, and safe areas follow each platform.

02 · Spec conflicts

Specs that do not match

This section compares exact values in Figma and the Style Guide. The dynamic mock is treated as a flow reference, not a specification source.

01

Collapsing Header

Current sources

Figma 320→280; Style Guide 350→280.

Needs a decision

Expanded and collapsed height for each header state.

02

Feature Tile

Current sources

Figma 171×103; Style Guide 166×104.

Needs a decision

Fixed size or flexible two-column layout.

03

OTP Code Cell

Current sources

Figma 50×62; Style Guide 50×60.

Needs a decision

Final outer height.

04

Segmented Control

Current sources

Figma 236×40.5; Style Guide 236×40.

Needs a decision

Whether 0.5 is intentional or a stroke/pixel-grid artifact.

Related Figma nodes

Header 403:153443, Feature Tile 403:151827, OTP Code Cell 403:151326, and Segmented Control 403:151450.

03 · Outside scope

Outside this review

These areas matter for the full app, but they do not need to be resolved with the theme and reusable components.

Navigation, sign-in and account behavior, APIs, BLE, permissions, persistence, offline behavior, and error recovery belong to a separate full-app review. The dynamic mock is useful for the main flow and state sequence, but formal behavior and data contracts are still required for feature integration.

Current statusThis review covers the design inputs needed before UI implementation. No Android theme, style, or component code has been changed.