When every interaction is a trust signal, ambiguity is a product failure
Designed the interaction model and visual system for Oracle Content Management's desktop sync app — enterprise infrastructure where the cost of uncertainty isn't frustration, it's broken trust.
5 sync states — all distinguishable at a glance
Conflict resolution: 3 steps or fewer
Zero sync-engine changes required
macOS + Windows — one mental model
Solution in production
Every sync state distinguishable at a glance — across three surfaces, two operating systems, without opening the app to verify.
The problem
Most of the support tickets were a design problem
The Oracle Content Management desktop app synchronizes files between local machines and cloud storage. For enterprise users, this is infrastructure — architecture documents, legal files, financial models.
The app worked. Users couldn't tell when it was working.
Internal data was precise: the majority of support tickets weren't caused by sync failures. They were caused by users unable to tell whether a failure had occurred. Idle and Synced looked functionally identical. Conflict surfaced an error state with no recovery path. The sync engine was fine. The language it used wasn't.
Users couldn't distinguish Idle from Synced — or act in Conflict or Error Recovery.
Clarifying the problem space
The brief was to “improve the sync experience,” but that alone doesn’t define success. The experience isn’t about moving files but it’s about ensuring users feel confident their files are where they expect, without needing to check.
This made sync state communication central, and positioned error recovery as trust-critical: both underemphasized in the original brief.
Research and diagnosis
Analysis of user interviews, support ticket logs, and usability data surfaced three failure categories — each tracing back to the same root cause.
Sync state ambiguity
Idle, Syncing, and Synced were visually indistinguishable — creating constant uncertainty about whether files were actually safe.
Conflict and error recovery
When conflicts occurred, users had no path to resolution: no explanation of what happened, no indication of which version was correct, no clear action.
Support ticket volume
Most support load traced to ambiguity, not failure. Users contacted support because they didn't know if something had gone wrong — not because it had.
What the ticket data actually told me
Ticket spikes corresponded to state transitions, not actual failures. Users opened tickets when they couldn't tell whether Syncing had completed — when they hit Conflict and couldn't interpret it — when Error Recovery showed a message they couldn't act on.
None of those are system failures. Every one is solvable with design, without touching the sync engine.
Before designing anything, I mapped how the three products our users compared us against handled the same states. The goal was to understand the mental models already in place — and design with them, not against them.
| Dropbox | Box | OneDrive | |
|---|---|---|---|
| Sync state indicator | Clear Menu bar icon transitions through distinct states — idle gray, syncing animated, synced green checkmark. State is unambiguous at a glance. | Partial System tray icon changes on activity but uses subtle variations that are easy to miss, especially in low-contrast display modes. | Partial File Explorer overlays (checkmarks, cloud icons) communicate per-file status, but no persistent ambient indicator shows overall sync health. |
| Conflict handling UI | Explicit Conflicting copies are renamed with author and timestamp appended. Both versions surface in the folder; no silent overwrite. | Limited Conflicts create a versioned copy but surfacing is passive — users must notice the renamed file themselves. No in-app conflict prompt or guided resolution. | Weak Conflict behavior varies by client (Windows vs. macOS vs. web). On desktop, overwrite can occur silently; version history is available but requires manual navigation to recover. |
| Error recovery path | Guided Errors surface inline with a plain-language explanation and a specific action (e.g., "Sign in to resume" or "Free up space"). Recovery requires one step. | Moderate Error states appear in the activity panel but messages are technical and action paths are unclear. Users frequently route to support rather than self-resolving. | Fragmented Error messages appear across multiple surfaces — system tray, notification center, and the web app — with inconsistent copy. No unified recovery flow exists. |
Design approach
With the problem diagnosed and the competitive landscape mapped, the design work moved through three deliberate stages — structure before visuals, every time.
Three-Stage Design Process
The cross-platform constraint was harder than I anticipated
The instinct was to find the visual common denominator and design to it. That's wrong for enterprise software where teams use both platforms and share files between them.
The correct frame: platform-native in execution, consistent in mental model. A user switching between Mac and Windows shouldn't relearn what Synced looks like — but each platform communicates it in its own convention. That meant designing each state twice and staying in close collaboration with engineering from week one. Some interaction decisions that take 10 minutes in Figma are non-trivial in native desktop on two operating systems.
The solution
Making every state unambiguous — across three surfaces
The primary constraint: every sync state had to be distinguishable from every other, at a glance, without opening the app. Across icon sizes (menu bar is 20px), across color contexts (light and dark mode, high contrast), across user attention levels (background awareness vs. active monitoring).
I redesigned the interaction model across three surfaces: menu bar icon, file-level status indicators, in-app activity panel. Each serves a different user need at a different attention level — and each required distinct design decisions.
Of all the decisions made in this project, the one that required the most stakeholder work was the recovery design.
The recovery design was the hardest problem
A conflict means two versions of a file exist and the system can't reconcile them. The existing experience surfaced an error state and stopped. No explanation. No indication of which version was correct. Users were expected to figure it out themselves — and most couldn't.
The goal: any user who hits conflict should resolve it in three steps or fewer, with enough context to make a confident decision. That required surfacing both versions, showing meaningful metadata (modification date, who modified it, size delta), and providing a single primary action with a reversible default.
Engineering pushed back on the reversible default — liability for choosing the wrong version. My argument: a bad default with a visible undo is less harmful than no default. No default forces a decision under stress with no safety net.
I held that position. The reversible default shipped.
Scope & outcome
System-level outcome: The product shifted from ambiguous state communication to a self-serve recovery model — reducing the class of support tickets caused by design gaps rather than system failures. Every critical sync state became distinguishable without opening the app.
What shipped:
End-to-end interaction model for core sync experience across macOS and Windows
Explicit recovery flows for conflict and error states — self-serve by design
Redesigned sync state system across menu bar, file-level indicators, and activity panel
Oradocs asset viewer interaction and visual redesign
Contributions to two additional OCM product areas
The activity panel — visible in the screenshot below — is where the state communication work is most legible.
Reflection
The trust frame was right. I'd establish it on day one next time.
"Improve sync experience" is under-specified. The trust brief — users need to be confident their files are safe without checking — has clear success criteria. Write the specific brief first.
The cross-platform call was correct, but I arrived at it late.
My early instinct was to find the visual common denominator. The better instinct — platform-native execution, consistent mental model — came through stakeholder input, not independently. I should have reached it first.
The conflict recovery is still incomplete.
What shipped was better than what existed. The missing piece is proactive conflict prevention — using activity signals to warn users before a conflict occurs. That requires deeper sync engine integration than we had scope for.
What this project clarified:
In enterprise tools, the absence of anxiety is the goal. Users don't want to notice the sync app — they want to trust it and forget it exists. Designing for invisibility is harder than designing for delight.
