Designing Workbench for Tech Support

Overview

What this project was about

The technical support vertical generated over 60% of Juniper Networks' revenue — yet engineers were spending more than 3 hours on average to resolve a single case. The organisation wanted to introduce automation and streamline workflows to reduce that number significantly. I led the research and design work to understand how support engineers actually worked, and what a better workbench would look like for them.

The Challenge

Understanding the problem space and identifying where the current experience was failing users.

Starting With the Business Reality

The support vertical was Juniper's most revenue-critical function, but engineers were working in a fragmented toolset that forced them to context-switch constantly. Cases, notes, attachments, communication threads, and file viewers all lived in separate systems. The mandate was clear: reduce case turnaround time. The path to get there required understanding exactly where that time was going.

Research & Discovery

Initial desk research covered wikis, support documentation, HR hiring documents, and networking industry forums — building context before going into the field. The primary research involved in-person workplace observations with support engineers and formal interviews conducted by the research team.

Case life-cycle diagram — mapping the entire support workflow from intake to resolution to identify where time was being lost

Business goals vs user goals matrix — Business vs. user goals matrix — aligning what Juniper needed with what engineers actually needed to do their jobs well

User Persona

To keep the team anchored on real users rather than assumptions, we created Amit Saxena — a detailed persona grounded in research observations — and used him as the lens for every design decision.

Design Approach: Storyboarding to IA to Wireframes

We used storyboarding to visualise real-life scenarios — helping the broader team see how the workbench would change the day of an engineer like Amit. Information Architecture activities explored different navigation structures before committing to a direction.

Information architecture diagram — Information architecture — defining navigation structures and content groupings based on how engineers think about their work

Screen flow wireframes — mapping the complete user journey through the workbench before moving to high fidelity

High-Fidelity Design Solutions

The workbench was designed around four core experiences that addressed the biggest time sinks engineers faced daily.

Dashboard mockup — Dashboard — user-centric task prioritisation built around Amit's actual workflow, not the system's data model

Case details screen — Case details — content reorganised around the engineer's mental model with appropriate information grouping

Simplified communication panel — Simplified communication — notes and attachments unified into a single stream, eliminating tool-switching

Advanced search interface — Advanced search — filterable by specific data types, built after extensive research into what engineers actually search for during active cases

Advanced file viewer with error detection — Advanced file viewer — automatically detects errors in logs, configs, and syslogs, surfacing known solutions inline

Results

Outcomes & Impact

3+hrs

Average case resolution time targeted

The workbench was designed to directly reduce the 3+ hour average resolution time through automation, unified tooling, and smarter information surfacing.

Critical Success Factors defined

User satisfaction, communication error reduction, case turnaround time, and accessibility — measurable outcomes grounding the design.

3/3

Usability tasks completed

All three test tasks completed within planned timeframes across moderated in-person and remote sessions.

Reflection

What I learned

Every project carries lessons beyond the deliverable. This section captures what I'd carry forward — patterns that worked, assumptions that didn't hold, and decisions I'd approach differently next time.

Replace this with your own reflection on the project. What surprised you? What would you do differently? What principles did this reinforce?