02 — Designing the foundation for a connected product ecosystem

Working page — rough story first, polished portfolio copy later.

Case study thesis: Core created the shared data and administrative foundation for a new generation of connected products, beginning with Schedule. The design challenge was not only creating Core, but defining the boundary between administrative control and the focused workflows that should live in individual products.

The starting point

Before Core, applications across the portfolio had been built independently. Products used different technologies and had different user experiences, with no shared product foundation connecting them.

When the company decided to build Schedule from the ground up, there was an opportunity to avoid creating another standalone application. The plan was to create Core first as the data and administrative foundation that Schedule could build on.

Artifact hunt

Screenshots of legacy applications showing how different the experiences were
Any early product architecture or planning artifacts
Early Core concepts

01 — Breaking from the legacy model

The goal was to move from independently built applications toward a connected product ecosystem.

flowchart LR
    A["Legacy App A<br>different technology + UX"]
    B["Legacy App B<br>different technology + UX"]
    C["Legacy App C<br>different technology + UX"]

Instead of adding Schedule as another isolated product, Core would establish a shared foundation for data and administration.

flowchart TD
    SIS["Institution / SIS"] --> CORE["CORE<br>data + administration"]
    CORE --> SCHEDULE["SCHEDULE<br>course section scheduling"]

02 — Giving Core a clear job

For users, the distinction became less about which academic object existed in which application and more about what job they were trying to accomplish.

Core

  • Integrations
  • Data import and export
  • Administrative functionality
  • Managing and correcting underlying data
  • Direct edits when administrators need control

Schedule

  • Create and manage course section schedules
  • Work through scheduling tasks in a purpose-built interface
  • Surface scheduling conflicts
  • Resolve conflicts and manage the scheduling experience
Design principle: Separate managing the system from doing the work.

Core needed to handle the complexity required to keep the ecosystem functioning. Schedule could then provide a focused, streamlined experience for the actual scheduling job.

03 — Designing the boundary

This became one of the central product-design challenges.

Core needed enough capability for administrators to manage and correct scheduling data directly, without becoming a second scheduling product.

The challenge was deciding which interactions belonged in the shared administrative layer and which should remain in Schedule, where the UX could be optimized around the scheduling workflow.

Working framing:

Core = control + data integrity

Schedule = workflow + efficiency

The same scheduling data might need to be edited from Core for administrative purposes while also appearing in a much richer, task-focused experience inside Schedule. The UX in Core therefore needed to support necessary administrative actions without becoming so workflow-heavy that it made Schedule obsolete.

Artifact hunt

Example of scheduling data as it appears in Core
The same or related data being used inside Schedule
A design decision where we intentionally kept functionality in Schedule
A design decision where administrators needed direct control in Core

04 — Designing Core and Schedule in parallel

Core began first, but development eventually overlapped with Schedule. That meant the two products could inform each other as the ecosystem took shape.

Rather than designing Core as an abstract database interface, real scheduling needs could expose what the shared foundation needed to support. At the same time, Core established boundaries and shared data structures that shaped what Schedule could become.

flowchart LR
    CORE["CORE<br>shared data + admin"] <--> DECISIONS["Shared product<br>decisions"] <--> SCHEDULE["SCHEDULE<br>task-focused UX"]

Questions to answer as we build this section

What changed in Core because of something we learned while designing Schedule?
What changed in Schedule because of a constraint or decision in Core?
Which shared objects created the hardest boundary decisions?
Were there patterns established here that later became standards for other products?

05 — The user journey

For a registrar or administrator, the relationship can be explained simply:

flowchart TD
    SIS["Institution / SIS"] --> CORE["CORE<br>integrate · import · manage · export"]
    CORE --> SCHEDULE["SCHEDULE<br>create · manage · identify conflicts · resolve"]
    SCHEDULE --> OUT["Working course section schedule"]

Core makes the institution's data work. Schedule lets the user do the scheduling work.

This is the human explanation of the architecture and should probably become one of the clearest visuals in the final case study.

06 — Creating a shared product language

To develop.

This section should show how UX architecture and the emerging design system helped Core and Schedule feel like parts of the same ecosystem rather than two independently designed applications.

Artifact hunt

Shared components or patterns across Core and Schedule
Navigation conventions
Tables / forms / object-management patterns
Early vs. current screens

07 — Shipping the first connected experience

To develop.

Core and Schedule represent the move toward a connected product model: Core provides shared data and administration while Schedule provides the specialized experience for creating and managing course section schedules.

Questions to answer

What exactly shipped in the first Core release?
What exactly shipped in the first Schedule release?
What did the launch enable that wasn't possible before?
What products or capabilities later began building on this foundation?

08 — What came next

Core was designed to support more than a single scheduling application. The architecture created a foundation that could support additional connected products without requiring each application to recreate the same administrative and data-management capabilities.

We should only name later products here once we confirm exactly how they connect to Core.

Portfolio narrative

Case Study 01 — Ecosystem

How design works across the product portfolio.

↓

Case Study 02 — Core

How the shared product foundation works.

↓

Case Study 03 — Proposals

How that systems thinking translates into a specific, complex product experience.02 — Designing the Foundation of a Product Ecosystem

Connected Curriculum · Core - The Foundation