Case study
SCA is the infrastructure Cube runs on. The work spanned both sides of the same technology: the consumer product where users collect their documents, and the operator platform where developers configure integrations and operations teams monitor agents at scale.
Outcomes
Context
SCA is the infrastructure Cube runs on — but its users are developers and operations teams, not consumers. They share the same platform but think differently, work at different speeds, and fail differently when the interface doesn't support their job. A developer misconfiguring a field definition causes a downstream integration error. An operator missing a divergent sync status under time pressure means an account stays broken. Both need clarity, but clarity for one audience is noise for the other
The operator challenge:
How do you keep two completely different jobs clear on the same platform?
Key decisions
Decision 1
Navigation
Three-section navigation — separating jobs at the top level
The BO dashboard doesn't present a unified tool — it presents three distinct starting points: agent management, support and troubleshooting, and permission configuration. Not tabs, not a sidebar with everything visible at once. Three paths, because the people using them are in completely different headspaces. Someone editing how an agent collects documents should never accidentally land in a sync failure triage view. The dashboard sits below: a glanceable summary — agents, accounts, sync health, API availability — so you know the state of your system before choosing where to go.
Decision 2
Status
Two distinct status signals per sync — because they can diverge
Every sync shows two statuses side by side: did the sync process work, and did the delivery report land. They look related, but they can tell completely different stories — a sync can succeed while its delivery fails. Collapsing them into one signal hides exactly the information an operator needs most. The same logic applies to 'nothing new to download' — at scale, most sync cycles return nothing new. That's not a problem. Treating it as one floods the interface with false noise. The drill-down places the reschedule button right next to the sync history, because the person reading a failure usually needs to act on it immediately.
Decision 3
Discovery
Signal before drill-down — what the grid shows without clicking
With 500+ agents, the grid has to do more than list them. On hover, each card shows account count and success rate — enough to know whether something needs attention before committing to a detail view. The filters narrow by type, availability, status, and category. The goal was simple: let the operator's eye find the problem, not make them open fifty detail pages to locate it.
Decision 4
Environment
The working environment as a design surface
Operators spend long sessions in this tool. The profile page gives them control over language, theme, and density — not as nice-to-haves, but as working conditions. These settings live separately from product configuration on purpose. Your preferred contrast and language shouldn't compete for space with agent permissions or sync settings.
Implementation
Design
Brand & positioning
- —SCA logo and visual identity — within the Securibox family, related but not interchangeable with consumer-facing Cube.
- —Brand application: guidelines and patterns across BackOffice, Webview, and the public landing.
- —CloudAgents is introduced before anyone sees the BackOffice — the public page leads with the integration model (API, SDK, Webview) and positions documentation as primary navigation, not a footer afterthought. For a developer audience, the docs are the product's first impression; for operations, the benefit structure and security posture build trust before the demo ask.
- —Page structure: the flow moves from what SCA does (automated document collection), to how it integrates (API, SDK, Webview paths with code examples), to why it's safe (SSL, CSRF, AES-256 encryption, rotating keys) — each layer answering the next objection.
- —Two audiences, one page: developers scanning for integration flexibility and operations teams looking for reliability signals both need to find their answer without reading the other's.
Product experience
- —BackOffice information architecture: three top-level paths kept apart (agents, support, permissions), with a dashboard that gives aggregate health — agent count, sync states, API availability — before drill-down.
- —Agent management: card grid with filtering and hover-preview so operators get signal before committing to a detail view; agent detail with sync activity chart and breakdown metrics.
- —Troubleshooting & support: tabbed support list with per-account history, inline reschedule and sync launch — the investigation workflow sits where debugging happens.
- —Embeddable Webview: a configuration surface where clients shape how the Webview looks (logo, colours, theme, fonts, consent text) with a live preview and generated embeddable link — while security behaviour stays platform-owned.
- —Operator environment: profile with role-based identity, language and theme preferences; dark and light themes for density and legibility across long sessions.
Code
What was built
- —Stack: React with Vite for both BackOffice and Webview; data fetched from HTTP APIs, state updates on navigation and refresh.
- —Dashboard: metric cards for agents, users, accounts, and sync status counts; API health panel with response time and availability.
- —CloudAgents: card grid with filter bar, search, and hover expansion; agent detail page with date-range chart and sync breakdown by state. Agent configuration: modal for editing field definitions per agent — type, label, validation, required/optional;
- —Support: list view with tabs (All, By agent, Progress, Status); account drill-down with full sync history, both delivery and process status per row, and inline sync trigger.
- —Statistics: area chart with aggregate baseline and per-agent overlay selection.
- —Configuration: API client and certificate management, webview customization: agent favourites, logo upload and other branding options; live preview pane with generated embed link.
- —Permissions & Accounts: user and team management, with profile and preferences selectors.
Trade-offs & Learnings
The BackOffice was designed to support the configuration and management of agents. Each section is internally coherent, while the relationships between them remain intentionally implicit.
Some connections are naturally discoverable. *CloudAgents* and *Statistiques*, for example, are tightly linked — the agent detail links directly to 'Open in Statistiques', and users can move between isolated and aggregate views without losing context. *Support* operates at the account level, and the transition between support and account management is straightforward enough that it doesn't require explicit linking.
The Webview configuration surface evolved from field-level control to a full brand customisation tool. The live preview pane was a late addition — originally, clients configured and deployed blind. Adding the preview reduced integration cycles significantly, because clients could validate their branding before generating the embeddable link.
This structure reflects the product's original build. Today, it could evolve to better align with its updated usage — shifting the BackOffice toward a support-first workflow as the primary entry point, with agent configuration and permissions becoming secondary paths.
Two audiences, one platform — each job clear at every level of zoom.
From grid overview to account-level sync history, the path never breaks.