Case study
Guroo Learning — Program Creation
Additional information
Key Decisions
A closer look at the decisions that shaped the proposed program creation and management experience, from mapping the existing system to making lifecycle part of the wider product model.
Key Decisions
1Information ArchitectureStructure creation around clearer conceptual areas
Decision
Organise the creation experience around Program details, Settings, Experience, Content and People rather than exposing the underlying system complexity directly.
Context
The existing experience had accumulated fields and settings across different program types and contexts.
Why
A clearer conceptual structure could help authors understand what they were configuring while still allowing detailed steps and conditional fields where required.
Trade-off
The conceptual areas do not remove the need for more granular steps or conditional rules in the detailed flow.
Outcome
The proposed design created a clearer foundation for guiding authors through program creation without pretending every program type was identical.
2System AnalysisMap existing fields and program types first
Decision
Catalogue existing fields, settings and behaviours across program types before redesigning the interface.
Context
The visible interface represented only part of the complexity. Fields were shared, conditional, duplicated or specific to particular configurations.
Why
Understanding the existing rules was necessary to avoid removing important functionality or creating inconsistencies between program models.
Trade-off
The mapping work required substantial analysis before the new interface could be structured.
Outcome
The proposed redesign was grounded in a clearer model of the existing system and its differences between program types.
3Learning ExperienceMake Experience a distinct part of program creation
Decision
Give Experience a clear place for configuring features that support the learner and facilitator learning experience.
Context
Features such as Discussion Boards, Onboarding and Grading affected the learning experience but were distinct from the learning content itself.
Why
Separating Experience from Content helped clarify what authors were configuring and why those decisions mattered.
Trade-off
The distinction adds another conceptual area that needs to be explained within the wider creation structure.
Outcome
The proposed experience gave learning-support features a clearer place without treating Experience as the location for defining learning content.
4Lifecycle ManagementIntroduce an explicit Program Lifecycle
Decision
Treat lifecycle as part of program management rather than treating creation as the end of the program journey.
Context
Programs continue through operational stages after initial setup, and users need to understand their current state and relevant attention areas.
Why
An explicit lifecycle could connect configuration, preparation and delivery in a way that was easier to understand.
Trade-off
The lifecycle introduces another product concept and needs to accommodate differences between program types and contexts.
Outcome
The proposed model gave program state and progression a clearer place in Program Details and administration thinking.
5Systems ThinkingConsider downstream system impact
Decision
Map the product areas affected by program creation instead of redesigning the wizard in isolation.
Context
Changes to program creation had implications for Settings, Learning Experience, Onboarding, Administration and lifecycle management.
Why
Making those dependencies visible supported a more coherent direction and reduced the risk of solving one screen while creating inconsistencies elsewhere.
Trade-off
The scope became broader than the creation wizard and required thinking across related pages and states.
Outcome
The proposal documented a wider system foundation for future implementation rather than a standalone set of creation screens.