
Spectrum defragmentation
Transforming Backend-Driven Spectrum Planning into a Real-Time Visual System
Project snapshot
Re-architected Fujitsu’s internal VPD spectrum workflow from a backend-dependent, error-prone process into a real-time visual editing experience
Role
Impact
Timeline
Team
Scope
Complexity
Senior Product Designer
70% retry reduction, 40% Time reduction
3 weeks
Product Lead, Principal Engineer
Discovery → Strategy → Interaction Design → Validation → Delivery
Brownfield enterprise network system

The Context
Fujitsu’s VPD tool is used by network engineers to design optical fibre networks.

In brownfield deployments, spectrum allocation requires extreme precision — changes affect live infrastructure.
The system allowed visibility in the UI.
But editing required backend terminal scripting.
That dependency created structural friction in a workflow that demanded speed and clarity.

The Core Problem

Engineers were forced to exit the interface to modify spectrum allocations.
This broke workflow continuity and introduced avoidable failure points.
The Core Misalignment
Engineers reason spatially about frequency blocks.

The system forced them into numerical scripting.
Impact:
-
~15 minutes per change
-
3–4 attempts per successful modification
-
Frequent syntax errors
-
Manual cross-node validation
This wasn’t a missing feature problem,
It was a broken interaction model.
My Responsibility
I led the end-to-end UX redesign of the spectrum workflow.

Specifically, I:
-
Conducted workflow diagnostics with 3 network engineers
-
Analyzed log data (200+ frequency change attempts)
-
Defined measurable success metrics with product (Retry reduction, Time-on-task target)
-
Facilitated concept alignment workshops
-
Led concept evaluation and made the final recommendation to stakeholders
-
Prioritized MVP scope in collaboration with engineering
-
Drove alignment between UX vision and backend feasibility
-
Feature implemented and rolled out to internal planning teams
This was not a UI enhancement,

It was a workflow transformation initiative.
Diagnosing the Failure
Through interviews and task observation, four critical insights emerged:
1. Cognitive translation
Engineers mentally converted spatial thinking into syntax.
​
3. Post-Commit Validation
Errors surfaced only after execution.
​
2. Context Switching
UI → Backend → UI fragmented flow and increased retries.
4. Retry Pattern as Signal
3–4 attempts indicated structural misalignment, not user incompetence.
Validation Process
-
Conducted 3 usability sessions per concept (9 total evaluations)
-
Measured task completion time (TOT) and error frequency
-
Observed hesitation patterns during drag interactions
-
Iterated ghost state feedback based on early confusion
Exploring Solution Models
Before converging, I evaluated three approaches through usability testing and feasibility review.
A. Form-Based Spectrum Editor
A structured input model allowing manual frequency entry.
Rejected because:
-
Reinforced numerical workflow
-
Increased data entry burden
-
Preserved error vectors
-
Felt like a UI wrapper over backend scripting
It solved surface friction, not structural friction.

B. Auto-Optimization Wizard
A guided flow where the system proposed optimized placements.
Rejected because:
-
Reduced perceived control for expert users
-
Increased technical complexity
-
Introduced trust risks in brownfield deployments
-
Added steps instead of removing them
Engineers preferred authority over automation.

C. Inline Visual Editing
A direct manipulation model allowing spectrum blocks to be dragged and resized within a visual chart.
Selected because:
-
Matched engineers’ spatial reasoning
-
Removed the cognitive translation layer
-
Reduced steps from 6 → 3
-
Enabled real-time validation
-
Required minimal backend restructuring
This aligned interaction with domain logic.

Quick comparison
Concept | Strength | Why Rejected |
|---|---|---|
Concept A | Familiar | Preserved syntax friction |
Concept B | Optimized | Reduced expert control |
Concept C | Spatial alignment | Chosen |
The goal wasn’t to add editing.
It was to redesign the interaction model.
The Solution
Inline Spectrum Defragmentation Mode

We introduced a contextual editing mode within the existing wavelength visualization.
Engineers can:
-
Drag and resize frequency blocks
-
See real-time conflict detection
-
Preview node-level before-after impact
-
Save or revert without backend scripting

Interaction Design Deep Dive



Workflow Transformation
Before
6 Steps | Backend dependency | 15 min TOT | 3–4 retries

After
3 Steps | Inline edit | 6 min TOT | Single attempt

Impact
Rolled out to 3 internal engineering teams supporting brownfield deployments across India & Japan
Quantitative
70% reduction in retries
From 3–4 attempts per change → single-attempt execution
40% faster completion
15 minutes → 6–8 minutes per spectrum change
Zero dependency
Routine planning no longer required terminal / backend scripting.
Qualitative
Increased engineer confidence
Real-time validation removed uncertainty during brownfield planning
Faster design lead approvals
Impact visibility enabled quicker verification across nodes
Reduced cognitive load
Less context switching, fewer manual cross-checks
Challenges & Tradeoffs
​Stakeholder Resistance
-
Automation was initially proposed for spectrum placement, Engineers pushed back, citing loss of control in brownfield environments.
-
I shifted the approach to assisted interaction — preserving expert authority while reducing error.
Performance vs Real-Time Feedback
-
Live validation across nodes risked backend overload
-
Scoped validation to impacted nodes only
-
Optimized calls to maintain responsiveness
​Tradeoff: Prioritized speed over full-system simulation.
​
Flexibility vs Safety
-
Inline editing increased risk of accidental changes
-
Introduced dedicated “Defragmentation Mode”
-
Required explicit commit + revert option
​Tradeoff: Added intentional friction to preserve system trust.
Control vs Automation
-
Explored auto-optimization concepts
-
Engineers preferred authority over automation
-
Brownfield planning required predictability
​​
Tradeoff: Chose direct manipulation over wizard-based automation.
Innovation vs Legacy Architecture
-
Backend built around procedural scripting
-
Full refactor out of scope (3-week timeline)
Tradeoff: Transformed interaction layer without destabilizing core systems.
Reflection & Next Steps
What This Project Reinforced
-
Friction often signals cognitive misalignment — not user incompetence
-
Experts prefer visibility over invisible automation
-
Real-time feedback builds confidence faster than post-execution validation
-
Structural redesign creates more value than UI polish
What I’d Do Next
-
Explore keyboard precision editing for advanced users
-
Enable batch spectrum adjustments across nodes
-
Explore assistive optimization with full override control
Strategic Insight