Zanma LMS Project

Designing a Learning Management System (LMS) for medium size organizations


In February of 2019, I started working on an ambitious project of creating a Learning Managing System (LMS) with a new value proposition that can compete against other monsters in the market. Because of the extension of the project, I decided to divide this document into three parts: An introduction explaining the context of the problem; in second place, the design process, that most than talking about how we build every screen, it talks about how we conceptualized the most relevant features and the process behind that (some of that concepts will be detailed in other documents) and finally the outcomes obtained about what I learned working on this project.

Table of content


  1. Overview
  2. Problem statement
  3. Users and audience
  4. Roles and responsibilities
  5. Scopes and constraints

Design Process

Core Features:

Other features:

  • Certificates
  • Dashboard
  • Onboarding
  • 1st Iteration

Outcomes and Lessons



Ksquare is an IT company with 5 years of experience, based in Dallas, Tx. Working with clients such as Seven Eleven, Verizon, Sabre, and Boy Scouts of America, we have been able to help them to enhance their digital transformation. Actually this project was born by a necessity of our client BSA to build a new Learning Management System to substitute their current one, which, in their own words, was too big, expensive and hard to administrate for their real requirements.

Problem Statement

The main goal of this system is to offer a new alternative in the LMS market, wherein one hand there is a bunch of systems developed for big organizations that are very complex, with many features and very customizable, but very expensive. And on the other hand, some new cheaper products but without possibilities of scalability, customization, architecture, and experience design to support the requirements of a medium-sized company that is looking to increase its team and possibilities to the future.

Users Audience

We have two different types of users. On the admin side, we have the people who is going to manage the system, in the case of our requirement, it will be used by the Learning Managing BSA team. On the student side, there are the people who will take the courses, for this purpose will be all the BSA community members. 

Roles and Responsibilities

Ksquare assigned a special team for this project. It was integrated by a product manager, five front-end developers, three back-end developers, one dev-ops, one UX Designer and UI designer. We all worked with the Scrum framework. I played the role of UX designer, trying to understand the scope and goal of the project, making quick research to understand the users, make usability testings to locate the pain points of the current system, interview the current users to understand their needs, designing low fidelity wireframes, flow maps and documentation for the de developers teams.

Scopes and Constraints

The first release will be designed attending the BSA requirements, using it as the first point of reference to validate concepts and ideas. But then extend this project to be sold to universities and colleges in the first stage, and finally sold the system to enterprise organizations. The first constraint was the time because it was considered to be finished in less than 12 months, 10 months for the first MVP release and 3 months for the first release to production. 

The design team was small so our first challenge was to design and iterate as fast as possible.

Design Process | Research

Defining the problem

After some meetings with the stakeholders and the BSA product owner, we defined that the objective of this project it’s to replace the existing LMS system, which was built under the Oracle (Taleo) infrastructure, improving functionality and integration. The main problems identified were:

  • Old fashioned look and feel experience
  • The Oracle system was very robust but difficult to manage
  • Expensive licenses

The main goal is to create a new LMS with a new experience fulfilling the last design tendencies, considering the users to improve the usability of it.

Knowing the Users

On the admin side, we observed that the users are people over 50 years without much experience and skills in technology but who know the BSA environment very well because they have worked there for more than 20 years. They counter the lack of tech abilities with enthusiasm to learn how to use the platform.

On the student side, we identified the users as people around 40 years, they have been BSA members for many years (10-15 years) and they use the LMS because they need to take courses to enhance their scout’s skills. They have other activities and expend some hours per week in the LMS. They have medium experience in technology.


We made the research on our main competitors to see what an LMS is offering in 2020 and how we can make a difference with a new value proposition:

Product Strategy

Features Definition

We started writing Jobs to be Done to define the main features of the system, the formula to write the JTBDs was the following:

Admin Side Features

  1. Onboarding
  2. Dashboard
  3. Reports
  4. Users and groups
  5. Courses
  6. Learning Plans
  7. Certificates
  8. Settings and Profile

Students Side Features

  1. Onboarding
  2. Courses
  3. Learning Plans
  4. My Learning
  5. Notifications
  6. Settings and Profile

Features prioritization

We had different discussions with the development teams and the PO and PM to analyze the impact of each feature and the effort needed to build them. We use a Lighting Decision Jam taking both points as a reference to define the priority of every feature:

Information Architecture


Features conceptualization, wireframing and prototyping

Courses, Learning Plans and Programs

The biggest challenge in designing this new LMS. One of the value propositions was the possibility of creating a learning structure as complex as needed by the user. As easy as having one course, or as hard as a learning plan with multiple levels and courses. For that, we used an “atomic” perspective.

In the catalog, we defined three levels of hierarchy: courses, learning plans, and programs.

Courses are the most basic entity in this structure, they have some attributes and configurations, but the most important, include the content, SCORM, and AICC files which are the standards in the LMS environment. By the moment it is just possible to import content but in the future, it will be able to create the content in the same LMS.

Learning plans are containers to group many courses with topics in common. They can also bunch other Learning Plans, bringing the possibility of nest content as required, offering the flexibility that we wanted to create learning structures.

But there was a problem, how to display that structure on the student side? We thought up the concept of Programs, which is a unique container at the top of all Leaning Plans groups. It keeps the order and gives a start and an end to the learning path.

Now the big challenge was how to design an interface capable of creating complex learning structures without complicating the interactions and decreasing the usability. For that, first, we defined the process to create the learning plans as described in the following flow maps:

Now that the process was defined by the stakeholders, we discussed it with the technical team. Something that honestly helped a lot by them part was the usage of Neo4j, this a flexible and reliable database builder that allows us to store and manage the information through different levels, identifying the hierarchy, attributes, performance of each one:

At this point, we started drawing some sketches for the interface solution:



Users and Groups

The second big important feature that is available by Zanma is the dynamic groups. Something that we observed is that not all people want to learn the same, it may depend on many factors like the age, the gender, the location, or in an organization, the position of the grade of expertise. To solve it, we created “dynamic groups”. In this context, we considered the attributes of all users, for example, the date when he/she was added to the system and then depending on the attributes set, the user will be automatically added to a group. The main advantages are that the attributes can be personalized, that is, you can use the default attributes or create new ones adjusted to your organization, and the second advantage is that you can assign content to every group. It means that once a user is assigned to a group, a specific course or learning plan will be also assigned to that user. 

Let’s see the process of how we ideated it.

In the first part, we made a list of the default attributes:

This is flow of how to add or import users:

So, the user has some default attributes, but every company can create new ones, as needed:

Once that we have uploaded some users with the required attributes, they can be added to a dynamic group.

The process is to select the attribute by which we want users to be added to the group, select an operator to relate the attribute with a value. In the next example, a group is formed by women who live in Dallas and have an age between 18 and 25 years.

Content can be added to the group and some courses or learning plans will be automatically assigned to the users who are part of the group:

Outcomes and Lessons

The biggest challenge working on this project was the scope and the resources. Because of the budget, the time was very short and once we started working, we saw that the project was more complex than we thought in the beginning.

The first sprints were hard, because we struggled a lot, trying to deliver on time with no mistakes, minimizing the risk of re working. I realized that it is the most wrong thing. I verified the premise of the UX experts, you definitely are going to make mistakes, just try to do it faster.

Our workflow was basically, have some conversations with users and stakeholders, build high fidelity mockups and present the idea in a prototype. We honestly underestimate the complexity of the system and through the road, we discovered some new issues like technical, business and usability constraints. We spent a lot of time in high fidelity mockups and we had to make many changes. In the effort to advance and save efforts, we did the opposite, taking longer to make corrections. 

After a few sprints, we started designing low fidelity mockups using Balsamiq and the big change was to get feedback from all the stakeholders, make changes quickly and deliver faster.  We spent more time talking with the users and learning from them. 

Everything can be summarized in a quote:

Leave a Comment

Your email address will not be published. Required fields are marked *