Ryan Scott
Product Designer
Case Redesign
Rebuilding the core case management system every department and every customer touches — from a fragmented PHP legacy screen into a role-aware, mobile-first React experience.
CommandLink
Quick read
3 min
Full story
8+ min
14 Months -> Aug 2025 - Sep 2026
DURATION
Product Designer
ROLE
8 Engineers, Engineering Lead, 1 PM
TEAM
Launching this month
STATUS
00 – PROJECT OVERVIEW
The one screen every department depends on, differently
The case modal is how CommandLink runs its business. Sales, service delivery, engineering, billing, customer success, and development all live inside it every day, and customers see a version of it too. Case Redesign rebuilds it as a mobile-first, role-aware experience, replacing a decade of hardcoded exceptions layered on one one-size-fits-all layout.
It ships this week, about 13 months after kickoff, and doubles as the vehicle for migrating the case system from legacy PHP to React.
02 – PROBLEMS + GOALS
One layout, a decade of exceptions
The old modal grew by accretion: every department's edge case became a hardcoded field, and every field stayed visible to everyone. Training a new hire took months just to teach them what to ignore.
Project Goal
Make it easy to track updates and document information · Show category/department-based information instead of everything at once · Build a mobile-friendly experience · Standardize fields to support future initiatives like SLA and calendar scheduling
03 – OPPORTUNITY
Not one redesign — many views of the same case
Designing "the new case modal" as one improved layout would have fixed the clutter but missed the problem: a billing manager, a network engineer, and a front-end developer are doing three unrelated jobs on one screen.
The opportunity was to treat the modal as a role-aware system: the same case, with a layout that adapts to who's looking and what they came to do.
04 – PROCESS + KEY DECISIONS
The moments that shaped it
Interviewing across the entire org chart, not just the loudest departments
I combined surveys, structured interviews, and competitive analysis across ten departments, from the C-suite to individual network engineers and billing specialists. Some of the most useful findings came from teams nobody expected to weigh in.
Letting conflicting feedback define the real requirement
Our lead PM called the modal "80% there already." Front-end engineers called it cluttered, with most fields having "absolutely no value" to them. Neither was wrong. They were doing two different jobs, which pushed the design toward role-based views.
Designing for the errors people don't report
A developer was accidentally rejecting tickets because the "completed" and "rejected" dropdown order wasn't consistent across case types. Nobody had filed it as a bug, so consistent field order became a requirement.
Scoping a 4-phase rollout instead of a single big-bang launch
I started with a read-only mobile view to validate how the densest fields work on a small screen, then customer-facing interaction, then internal field parity. A fourth phase (CSAT, sentiment, case health) was deliberately scoped out.
07 – FINAL DESIGN
A case modal that knows who's looking at it
Case Redesign ships in phases: a read-only mobile view, then full customer-facing interaction, then internal field parity across three scrollable panels, with CSAT and case health scoped out for later. Per-customer tabs, fields, and checklists move into settings instead of hardcoded exceptions.
Each phase shipped as a real, usable slice — not a partial preview of the final state.
08 – OUTCOMES + IMPACT
Landing the week this case study was written
Case Redesign ships this week. I don't have adoption or efficiency numbers yet, but the research already validated the core bet: departments with different needs see purpose-built views of the same case.
NEW HIRE TRAINING TIME
Expected to drop once new hires aren't taught to ignore 80% of the screen.
CROSS_DEPARTMENT SUPPORT LOAD
Expected to drop as each role sees only what actually applies to them.
CASE DATA COMPLETENESS
Expected to improve with required-field enforcement, replacing missing information.
DROPDOWN-DRIVEN ERRORS
Expected to drop once field order is consistent across every case type.
NOTE
This case study will be updated with measured outcomes now that Case Redesign is live and has data.
09 – TAKEAWAYS
What I'm taking forward
A single interface can be right for everyone and wrong for everyone at once.
The bugs worth designing around are often the ones nobody reports.
Redesigning the UI and migrating the foundation at once means holding two kinds of uncertainty.
Case Redesign
Rebuilding the core case management system every department and every customer touches — from a fragmented PHP legacy screen into a role-aware, mobile-first React experience.
CommandLink
Quick read
3 min
Full story
8+ min
14 Months -> Aug 2025 - Sep 2026
DURATION
Product Designer
ROLE
8 Engineers, Engineering Lead, 1 PM
TEAM
Launching this month
STATUS
00 – PROJECT OVERVIEW
The one screen every department depends
on, differently
The case modal is how CommandLink runs its business. Sales, service delivery, engineering, billing, customer success, and development all live inside it every day, and customers see a version of it too. Case Redesign rebuilds it as a mobile-first, role-aware experience, replacing a decade of hardcoded exceptions layered on one one-size-fits-all layout.
It ships this week, about 13 months after kickoff, and doubles as the vehicle for migrating the case system from legacy PHP to React.
02 – PROBLEMS + GOALS
One layout, a decade of exceptions
The old modal grew by accretion: every department's edge case became a hardcoded field, and every field stayed visible to everyone. Training a new hire took months just to teach them what to ignore.
Project Goal
Make it easy to track updates and document information · Show category/department-based information instead of everything at once · Build a mobile-friendly experience · Standardize fields to support future initiatives like SLA and calendar scheduling
03 – OPPORTUNITY
Not one redesign — many views of the same case
Designing "the new case modal" as one improved layout would have fixed the clutter but missed the problem: a billing manager, a network engineer, and a front-end developer are doing three unrelated jobs on one screen.
The opportunity was to treat the modal as a role-aware system: the same case, with a layout that adapts to who's looking and what they came to do.
04 – PROCESS + KEY DECISIONS
The moments that shaped it
Interviewing across the entire org chart, not just the loudest departments
I combined surveys, structured interviews, and competitive analysis across ten departments, from the C-suite to individual network engineers and billing specialists. Some of the most useful findings came from teams nobody expected to weigh in.
Letting conflicting feedback define the real requirement
Our lead PM called the modal "80% there already." Front-end engineers called it cluttered, with most fields having "absolutely no value" to them. Neither was wrong. They were doing two different jobs, which pushed the design toward role-based views.
Designing for the errors people don't report
A developer was accidentally rejecting tickets because the "completed" and "rejected" dropdown order wasn't consistent across case types. Nobody had filed it as a bug, so consistent field order became a requirement.
Scoping a 4-phase rollout instead of a single big-bang launch
I started with a read-only mobile view to validate how the densest fields work on a small screen, then customer-facing interaction, then internal field parity. A fourth phase (CSAT, sentiment, case health) was deliberately scoped out.
07 – FINAL DESIGN
A case modal that knows who's looking at it
Case Redesign ships as a phased rollout, each phase a real, usable slice rather than a partial preview.
Each phase shipped as a real, usable slice — not a partial preview of the final state.
08 – OUTCOMES + IMPACT
Landing the week this case study was written
Case Redesign ships this week. I don't have adoption or efficiency numbers yet, but the research already validated the core bet: departments with different needs see purpose-built views of the same case.
DROPDOWN-DRIVEN ERRORS
Expected to drop once field order is consistent across every case type.
CASE DATA COMPLETENESS
Expected to improve with required-field enforcement, replacing missing information.
NOTE
This case study will be updated with measured outcomes now that Case Redesign is live and has data.
NEW HIRE TRAINING TIME
Expected to drop once new hires aren't taught to ignore 80% of the screen.
CROSS_DEPARTMENT SUPPORT LOAD
Expected to drop as each role sees only what actually applies to them.