Public Case Study
New York Times R&D · Eclipse
Keeping journalists reporting while professional video moves in the background
As UX/UI Designer, I designed the mobile workflows for selecting, annotating, and transferring large video files from the field. Proxy-first transfer, visible upload states, and recovery paths made a demanding process usable enough to test under reporting pressure.
- Situation
- Video journalists often had to stop filming and leave the scene to find Wi-Fi and a laptop before editors could receive professional footage.
- My role
- UX/UI Designer responsible for end-to-end interaction flows, interface design, prototyping, and design handoff to the mobile developer.
- Contribution
- Focus Area
- Complex operational UX
- Period
- May 2021–January 2022
- Verified change
- Field testing informed the proxy-first transfer, parallel background upload, visible status, annotation, and recovery paths in the workflow.
Early evidence
Move useful footage first—and make every transfer state legible
This recreated workflow connects the core interaction to an approved prototype screen. It shows how journalists could select priority clips, add context, and continue filming while uploads ran, so the newsroom could receive useful proxy footage before larger source files.
Decision atlas
Three decisions made a difficult transfer workflow usable in the field
The design had to move useful footage sooner, make transfer activity clear under unreliable conditions, and keep a remote team aligned while requirements changed.
Consequential decision
Send editorially useful footage before the largest source file
The problem
Professional camera files were too large for dependable mobile transfer. Early field work showed that moving full-resolution source files could be slow and unreliable under reporting conditions.
Evidence and reasoning
Professional cameras could generate compressed proxy files alongside full-resolution footage. The smaller files retained enough quality for rapid editorial review while reducing the amount of data that had to move first.
Design response
I designed a proxy-first flow for importing footage, selecting and reviewing clips, and sending the material the newsroom needed first. The wider team chose Android and a dedicated secondary phone to support wired ingest and sustained transfer.
Proof
The documented workflow used proxy clips for early editorial access while retaining source files for later high-resolution use.
Consequential decision
Treat reliability as a sequence of visible, recoverable states
The problem
Background transfer allowed reporting to continue, but it could also hide activity. Field testing showed the need for clearer information about progress, interruptions, and what would happen next.
Evidence and reasoning
Field use exposed more than a speed problem: journalists needed confidence that several uploads were progressing, clarity when one failed, and a safe way to continue after an interruption.
Design response
I designed parallel, background upload flows with progress, estimated time, completion, error, and resumed-transfer states. Annotation and batch captioning kept editorial context with the clips rather than splitting it across calls and messages.
Proof
The programme iterated on parallel uploads, resuming partially completed transfers, and clearer status feedback. Those were wider programme changes informed by field testing, not implementation work attributable to Sadi alone.
Consequential decision
Turn a changing remote brief into one implementable workflow
The problem
The team worked fully remotely between the US East Coast and Helsinki, with limited access to test users and requirements that changed through roughly four or five design iterations.
Evidence and reasoning
Text descriptions left too much room for competing interpretations. Concrete prototype alternatives made the full workflow, edge cases, and technical implications reviewable by stakeholders and the developer at the same time.
Design response
I maintained one high-fidelity Figma prototype as the shared source of truth. After reviewing changing requests through concrete flows, I proposed a constructive requirements freeze and refocused the journey on its essential transfer states.
Proof
The prototype connected weekly reviews, interaction decisions, and developer handoff in one artifact. It established the design boundary; it does not claim that I implemented the Android app.
Results
What changed
Field testing gave the wider programme evidence to refine proxy-first transfer and the workflow’s reliability states. It tested the direction I designed, while engineering, field operations, testing, newsroom use, and programme outcomes remained the work of the wider NYT R&D and newsroom teams.
Evidence boundary
What this does not establish
This Case Study shows a field-tested design direction, not confirmed production deployment, programme impact attributable to Sadi alone, or ownership of the Android implementation. The app screen is an approved prototype artifact; recreated diagrams are explanatory, and NYT field photography is not reproduced.
Collaboration and constraints
Detailed interaction design inside a live R&D programme
My responsibility
I designed the end-to-end mobile flows and UI, explored alternatives, maintained the high-fidelity prototype, facilitated design reviews, controlled the interaction scope, and handed the agreed states to the developer.
Wider team
I worked with one mobile developer, NYT R&D stakeholders, and journalist/test users. Engineering, field operations, testing, newsroom use, and programme outcomes belonged to the wider team.
Material constraints
The Android-only MVP had to handle professional camera formats, large files, variable 4G/5G connections, background activity, heat and battery limits, interruptions, limited tester access, and an eight-hour time-zone difference.
Start a conversation
What has become fragmented, difficult to use, or hard to decide?
Tell me briefly about the situation. I’ll reply with an initial perspective and a sensible next step.