CS/03 — EDTECH · RESPONSIVE PRODUCT DESIGN · DESIGN OPERATIONSSANITIZED. LOGIC INTACT.

Turning a launch handoff into a scalable product system

DOMAIN — STUDENT INTERVENTION SERVICESROLE — SENIOR PRODUCT DESIGNER, JOINED PRE-LAUNCHSCOPE — DESIGN AUDIT · COMPARATIVE DESIGN · RESPONSIVE UI · DESIGN SYSTEM · DEVELOPMENT COLLABORATION

THE CHALLENGE

I was brought in to finalize previously approved designs for launch. A review of the product exposed structural problems in the calendar, data presentation, responsiveness, and the system’s ability to scale.

WHAT I CHANGED

I created preliminary alternatives, presented them beside the approved work, and made a comparative case for restructuring rather than preserving parity.

WHAT BECAME POSSIBLE

The client extended the design engagement by two months and delayed launch so the revised work could enter the development sprint. The resulting responsive UI and design system continued to support new features after my contract ended.

THE BRIEF I WAS GIVEN

The assignment sounded contained: finalize the approved designs for the platform launch and support handoff.

The product coordinated student intervention services across eligibility, district priorities, guardian consent, staffing, availability, and scheduling. During review, I found several areas where the approved experience would struggle under real use: the calendar needed clearer visual structure, data-heavy screens needed more scalable patterns, and the interface had not been fully adapted for responsive behavior.

Finalizing those screens as-is would have protected the date and transferred the problems directly into development. Efficient, in the narrowest possible sense.

THE INTERVENTION — SHOW, COMPARE, REFRAME

I did not begin by asking the client to reopen the entire design. I created a focused set of preliminary screens addressing the highest-risk areas and presented them beside the approved versions.

The comparison made the tradeoff concrete. Stakeholders could see the difference between preserving parity and designing for the product they were actually preparing to launch. I framed the revisions as new product objectives: scalable data patterns, clearer scheduling interactions, responsive behavior, and a reusable UI system.

I expected interest followed by a polite refusal to move the timeline. Instead, the client chose to postpone launch and extend the design contract by two months so the revised experience could be incorporated into the active development sprint.

That decision is the center of the case study. The design work did not merely improve a handoff. It changed what the client was willing to ship.

WHAT THE ADDITIONAL TWO MONTHS BOUGHT

A calendar designed for operations

Scheduling needed to communicate availability, conflicts, status, and change without turning the calendar into decorative graph paper. I introduced a more visually legible structure and patterns that could support the density of daily operational use.

Data patterns that could scale

Student, staffing, eligibility, and schedule views needed to remain usable at high volume. I redesigned tables, filters, bulk actions, forms, and status treatments so the product could grow without quietly exporting the hard parts back to spreadsheets.

Responsive behavior, not responsive shrinkage

The existing designs had not been fully resolved across screen sizes. I adapted the experience for responsive layouts by reconsidering hierarchy, stacking, controls, and information priority rather than simply compressing desktop screens.

A system development could continue using

The revisions became a design system that supported the launch work and subsequent additions to the scope. New features developed after my engagement retained the patterns established during the redesign.

DESIGNING ACROSS DISTRIBUTED DEVELOPMENT TEAMS

The delivery environment included development teams in Eastern Europe and Asia working continuously across time zones. Because the files were in constant use, the design could not depend on me being awake to explain it.

I annotated handoff files in detail, prototyped interactions when static screens were insufficient, and led biweekly design sessions with developers. We reviewed how each experience should be built, identified technical constraints, and revised designs as implementation exposed new questions.

The goal was not a ceremonial handoff. It was a working relationship between design intent and technical reality.

SELECTED REDESIGNS

Group and scheduling workspace — service requirements, student membership, qualified staff, and scheduling — FIG 01 — Group and scheduling workspace: a connected view of service requirements, student membership, qualified staff, and scheduling, redesigned as part of the scalable launch system.

High-volume student list with eligibility, priority, filtering, and bulk actions — FIG 02 — High-volume student data: eligibility, priority, filtering, and bulk action for approximately 1,200 student records, without summoning the spreadsheet goblin.

Student detail with guardian approval states — FIG 03 — Guardian approval: consent presented as visible operational state with clear consequences for the scheduling workflow.

Teacher availability with editable time blocks — FIG 04 — Teacher availability: prep time, breaks, and unavailability translated into a more legible calendar pattern for real scheduling constraints.

Weekly schedule with submission and approval states — FIG 05 — Schedule status: submitted, approved, and in-progress states made review and change visible across the operational workflow.

THE OUTCOME

The client extended the engagement by two months and moved the launch timeline so the redesign could be built. The additional work produced a more scalable, streamlined, and responsive UI, supported by patterns that continued to structure new features after the design contract ended.

The value lasted beyond the files. The development guidance and artifacts remained in use and were still being referenced after the engagement. I had entered to finalize a launch. I left behind a system the product could continue growing into.

KEY TAKEAWAY

Sometimes the responsible design decision is to protect the launch date. Sometimes it is to show, concretely, why the product should not launch that way.

Screens are sanitized recreations. Client data, naming, and internal terminology have been removed.

← INDEX
NEXT: CS/04 →