Designing a clearer way to create and manage learning programs

Overview

Designing a clearer way to create and manage learning programs

Guroo Learning already had functionality for creating and managing programs, but the experience had accumulated complexity over time. Different program types, configuration options and years of product evolution meant the feature needed to be understood as a system rather than treated as a form redesign. This project was a substantial improvement to the existing experience, informed by customer feedback Guroo had received over several years. I catalogued existing fields, mapped them across program types, reviewed the broader feature and flows, and designed a clearer proposal for Program Creation, Program Details and Program Lifecycle. This was the last project I worked on during my Guroo Learning contract. My involvement ended after the research and analysis, system mapping, flows and interface designs were completed.

The Problem

A mature creation experience had accumulated complexity

Program creation had evolved to support different learning models, settings and delivery requirements. The experience therefore contained many fields and rules, some shared across program types and others conditional or specific to a particular configuration. Customer feedback collected over several years also identified areas where the existing experience could be clearer. The challenge was not simply to redesign a wizard. It was to understand how the fields, program types, dependencies and downstream product areas worked together before deciding how the experience should be reorganised.

Discovery

Before redesigning the experience, I mapped what already existed

A major part of the work was understanding the existing system before proposing a new one. I catalogued program fields and mapped them against the different program types to identify what was shared, conditional, duplicated or specific to particular configurations. I also mapped the broader creation and management flow, including existing screens and dependencies that could be affected by the revamp.

What the mapping made visible

AI in the process

Using AI to accelerate analysis, not replace it

AI helped me move faster through some of the more complex analysis in this project. For the field audit, I used AI to create an initial inventory of the existing program experience. I then reviewed and revised the output myself, checking it against the current product to make sure the fields were accurately captured and mapped across program types. I also used AI while developing the Program Lifecycle. I started with a rough model of how programs could move through different stages, then used AI as a thinking partner to challenge the structure, explore scenarios and refine the concept. In both cases, AI helped accelerate exploration and analysis while I remained responsible for validating the system, evaluating the suggestions and making the final product decisions.

Structuring Program Creation

Organising complexity into clearer conceptual areas

The redesign organised program creation around five broader areas: Program details, Settings, Experience, Content and People. These areas provided a clearer conceptual structure for authors without implying that every program type would use exactly the same labels or number of screens. The detailed flow could expose more specific steps and fields where the selected program type or context required them. The goal was not to eliminate the underlying complexity, but to organise it into a clearer experience.

Creation Experience

Making a detailed setup process feel clearer

The proposed creation experience used a shared structure while allowing more granular steps and configuration to appear where required. It began by establishing the program context, then guided authors through the information and settings relevant to that program type. The screenshots show selected parts of the proposed experience. They are evidence of the detailed design work rather than a claim that every program followed one identical sequence.

Program Lifecycle

Supporting programs beyond initial creation

Program creation was not the end of the problem. Programs continue through an operational lifecycle, so the redesign introduced a clearer way to understand their current state and what needed attention before progressing. The supplied lifecycle model shows stages including Setup, Building, Review, Onboarding, Active, Complete, Closed and Archived. Users could manually progress programs through relevant stages, while the exact lifecycle could vary according to program type and context. The lifecycle concept was incorporated into the Program Details and administration thinking so status could become part of ongoing program management rather than a decorative progress indicator.

What the lifecycle was intended to communicate

Designing Beyond the Wizard

A change to one feature affected many others

Changing program creation affected more than the wizard. I reviewed and reworked the Program Details and Settings thinking and identified other pages and states that would need to change because of the broader revamp. Mapping these connections helped make the system impact visible and supported a more coherent direction for future implementation.

Key Decisions

Structuring the system before simplifying the interface

The decisions behind the redesign focused on how to make a mature feature clearer without ignoring the complexity underneath it.

Outcome

A clearer foundation for future implementation

The project resulted in a redesigned proposal for how programs could be created, configured and managed. It brought together mapped existing behaviour, field and program-type analysis, revised creation flows, redesigned creation screens, Program Details thinking, a Program Lifecycle concept and identification of affected product areas. The work created a more coherent foundation for continuing the redesign. My contract ended before implementation, so I did not work on development, launch, production validation or measured outcomes.

Reflection

What looks like a form problem can be a systems problem

This project reinforced the value of understanding an existing system before redesigning it. Mapping fields, program types, dependencies and lifecycle states made it possible to organise the author experience more clearly without ignoring the complexity underneath. The most important design work happened before the interface was simplified: understanding what already existed, what varied by context and what else would be affected by the change. Simplification doesn't begin by removing things from a screen. It begins by understanding the system behind them.