PART 1

Customer/User Job-to-be-Done or Problem

As a Skillabi User, I want to ensure that the integrity of my curricular information in Skillabi is intact and backed-up giving the option to revert back to in the event of a mistake so that we can experiment and use Skillabi without fear of losing information over time as edits are made.

As a Skillabi User, I want to be able to see changes in my curriculum and skills over time as updates are made for new catalog years in order to get a picture of how my alignment and skills have changed with the use of Skillabi and other curriculum review methods. 

If a critical error were to occur the only backup to customer data would be through rolling back the entire database which is not an ideal solution in that event. Due to the manual process of skill-tagging, many man-hours could potentially be lost if data were to be deleted. This would impact both Lightcast and the customer in this eventuality. If this error were not caught right away, it would also be difficult to roll back the database farther than a few hours to a day. 

Value to Customers & Users

By creating different versions of the program set (catalogs) for users to work in, and updating these annually with any changes the institution makes to the programs…

• Customers would have the confidence to dive in and extend Skillabi access to more users with the knowledge that the initial state of curricular content is saved, backed-up, and able to be reverted to. This opens up more avenues to use and get value from Skillabi without the fear of causing data problems down the road.

• Customers would be able to view skill changes across catalog years/versions in order to better understand the impact of their efforts to align offerings with better outcomes for students.

• Customers would have the ability to work in  “risk free” spaces (“sandboxes”) to experiment and make changes in Skillabi while retaining a record of the original dataset. 

• Customers would be able to easily see older versions of content and add new catalogs when the institution releases them, instead of trying to combine old and new content in a single space.

Value to Lightcast

This allows Lightcast to…

• Reduce the risk of losing customer data by protecting the original version and allowing us to easily revert if an error were to occur.

• More easily track changes and efficiently refresh customer content annually.

• Have a data structure that more closely resembles that of our customers in order to potentially better connect with their information and systems (for example, a customer could create a catalog for use across a department).

• Drive more traffic to Skillabi, by encouraging users to work more freely and frequently in Skillabi, without fear of making changes to “official” content

Target User Role/Client/Client Category

This feature is being built for Skillabi admins to have confidence in data integrity and to be able to structure updates to information over time. Also supports all other institutional Skillabi users by giving them more freedom to experiment and make changes without impacting their curriculum data.

Delivery Mechanism

This feature will be delivered in the Skillabi interface. 

Success Criteria & Metrics

Definition of Done:

• Catalogs are created and live in Skillabi as curriculum sets that other curricular units (e.g., departments, groups of programs) fall under.

  • These catalogs can be created, edited, and viewed by users. Each one will act almost like a separate, but connected Skillabi site.

  • There will be “main” and “sandbox” types of catalog

• Ability to revert edited curriculum back to the “main” catalog version, or “push” new and approved changes to and from the “main” version

• Show progress over time in terms of skill gap (market alignment) change between catalog versions

Dependency: database changes, goal to get full postgres transition done by end of Q1 (end of March). Need to wrap this up before beginning to build data versioning.

Success metrics (guesstimates for now)*:

• North Star Input: Average Number of Users per Customer Account

  • Increase by 10% or more

• North Star Input: Percent of Users Logging in Regularly

  • Baseline: 45%, Increase by 5% or more.

• 20% or more institutions/accounts actively utilize this feature to create a safe space to experiment and allow users to make changes to data.

• We see an overall 15% or greater increase in user edits to courses and programs as they can now safely do so.

• Customers report a greater sense of trust in the data available in Skillabi now that it can be tracked and saved over time.

*This will likely have a slower impact than other features due to its function. Would expect to see these changes over approximately 6 months.

Aspects that are out of scope (of this phase)

Saving and making every change visible and revertible akin to Google Docs is out of scope for this phase. In a future epic we may return to the idea of more robust versioning and controls for individual courses and programs.

PART 2

Solution Description

To bring all of these concepts together, this epic will be focused around the creation of and structuring our database to fit the concept of catalogs:

• Catalogs will exist as a sort of set of curriculum. Courses and Programs will all fall under specific catalogs just like they do in the large majority of our customers' institutions.

  • This will help conceptually structure content for our users and will be flexible enough to create additional “catalogs” per department or other denomination. This allows for segregated workspaces for groups of users who do not want the distraction of the entire curriculum.

• When viewing a particular catalog, Skillabi will function as normal. All of the existing features and functions of a Skillabi site will be there, but now those would be falling under a particular catalog.

• There will be a dashboard to view and switch between catalogs

• There will be an “active” catalog set that users are defaulted to upon logging in. This will remove the necessity to interact with this feature if not desired.

• There will be two types of catalog. Main and Sandbox

  • All users can edit and experiment in sandbox catalogs, while only Admins can edit main version catalogs.

  • This allows for all curriculum information to be effectively backed-up

• All content can be copied or overwritten from one catalog to another. This allows users to either revert changes in a sandbox back to the original version, or push changes to the main catalog.

  • Only administrators will be able to push changes to the main version if needed. 

Early UX (wireframes or mockups)

Initial Mock-ups for Catalogs Dashboard

Non-Functional Attributes & Usage Projections

Consider design to clearly communicate data structures.

Expect to see 20% or more of customers actively using this feature in the first 6 months.

Will implement passive utilization of this feature for 100% of customers.

Dependencies

Cannot implement back-end changes until the Skillabi database is finished being switched over from MongoDB to PostgreSQL.

Legal and Ethical Considerations

No legal or ethical concerns.

High-Level Rollout Strategies

• Train CDOT team on how to separate and upload curriculum materials to specific catalogs. 

• Train Education Success on the new feature and explain how to present this to customers.

• Pendo Announcement in Skillabi

Risks

• .This feature does add some level of complexity and may confuse some users.

• The concept of catalogs fits with the bulk of our users and our target audience, but secondary audiences like publishers and other partnerships accounts may not fit nicely with their content.

• This will interact with SkillsMatch. We need to make sure that is addressed during build out.

Open Questions

• How will SkillsMatch point at the correct Catalog?

• How can we prevent too much database bloat as we scale?

Complete with Engineering Teams

Estimated Costs

Direct Financial Costs

Are there direct costs that this feature entails? Dataset acquisition, server purchasing, software licenses, etc.?

Team Effort

Each team involved should give a general t-shirt size estimate of their work involved. As the epic proceeds, they can add a link to the Jira epic/issue associated with their portion of this work.