Designing a multi-role service platform from the ground up
An embargo-safe account of the systems, workflow, and delivery decisions behind more than 250 production screens and flows.
- Role
- UX Design Lead
- Duration
- July 2023–present
- Team
- Product & engineering
- Scope
- 250+ screens & flows
Challenge
MelodyArc is a service-based B2B company that brings data, rules, AI, and people into operational workflows. Its official documentation describes Portal as a web workspace where teams manage conversations, review progress, intervene in workflows, and administer their organization.
The design challenge was to turn that broad service model into a coherent product: many roles, tasks, states, permissions, and operational decisions needed to feel like one understandable workspace rather than a collection of disconnected tools.
Evidence
The most useful public evidence is the scale and structure of the shipped work. I designed the Portal from the ground up across more than 250 production screens and flows, while building reusable patterns that could support continued product growth.
Documented surface area
MelodyArc’s official documentation names three Portal personas—Associate, Designer, and Expert—and describes the following areas. They are listed here to communicate product breadth, not private implementation detail.
Active work, progress, context, and actions within a shared operational frame.
Documented spaces for knowledge access and expert contribution.
Visibility into work that needs review, awareness, or intervention.
Documented users, roles, operators, views, and organization settings.
Decisions
- Keep work and context together. Operational tasks need their conversation, current state, supporting context, and available actions close at hand.
- Design for roles and permissions. A multi-role product cannot rely on one universal view; hierarchy and available actions must stay legible as responsibility changes.
- Systemize repeated states. Loading, empty, active, blocked, error, review, and completion behavior were treated as reusable product infrastructure.
- Make progression traceable. Status, ownership, and the relationship between actions and outcomes need to remain understandable across a long-running workflow.
Operating model
Model the work
Map roles, task progression, decision points, permissions, and required context.
Build the system
Turn recurring hierarchy, component behavior, responsive patterns, and states into a shared foundation.
Ship with engineering
Resolve behavior through implementation and evolve the system as new operational needs appear.
Outcome
The work established a production product across 250+ screens and flows, supported by reusable components, interaction states, responsive layouts, and a shared visual and behavioral language.
This account intentionally makes no claims about confidential customer outcomes or unpublished business metrics.
Reflection
At this scale, design quality depends less on perfect individual screens and more on the coherence between them. The strongest decisions were the ones that helped new workflows inherit familiar structure while still making their specific operational responsibilities clear.