Apprix Builder training tool is used simultaneously by dozens of clients, in hundreds of training courses and by thousands of users. It is obvious that different parties have quite different needs and expectations, relating to the development of the Builder tool, which are different from those of others. The aim of this blog post is to disclose and talk a little about the ways how Apprix handles product development in a manner that wishes of everyone involved could be satisfied in the best possible way.

Builder has been set up such that it allows to perform a wide range of eLearning courses, while making all its functions available via a web browser. Therefore, the same software needs to have a really large number of different functions used by different users.

The core principle of developing of the Builder system is that:

  • We are basically ready to implement the system such as to include anything that the customer wishes.
  • Our aim is to realise all the most commonly used items on the wish list such that they could be offered to any other Builder users as well.

The above-mentioned principles are not self-evident, and not all companies providing SaaS (Software as a Service) services are operating in this manner. For instance, it would be much easier to have no client-specific customizations ever made to the software, and instead provide just one and only software version which is the same for all (in fact, it is a quite common practice: or have you ever heard about Microsoft providing someone their requested customisations to word processing, spreadsheets, etc. software contained in Office 365).

Our top-level objectives relating to the customisation options for Builder are, among others:

  • Making Builder easy to use for both those involved in planning training courses as well as for participants in these courses.
    • We remain faithful to the principle of user-friendliness, even though Builder offers many different functions.
  • Our aim is to use such content and exercises in the training courses that serve the learning process in the best possible way.
    • For example, it might be necessary to use slightly different training tasks in different learning situations.
  • In terms of graphical representations, the training courses are made to match the customer’s wishes.
    • Customisation of the graphical representation means that colours and fonts, as well as images used in the training materials are consistent with the client’s own visual branding.

While we are prepared to widely modify our training system in accordance with our customers’ wishes, we get a large number of requests relating to the development of the software, which sometimes even contradict each other. In order for us to be able to control the flow of wishes, our product development is divided into three different stages in terms of responsibilities:

1: By requirement management we mean that we collect all ideas originating from different sources into the same “barrel of wishes” (Feature back log). Development ideas could come from the customer, as well as from ourselves, and they might apply to new requirements relating to the software or, as sometimes happens, to bugs / incoherencies that need modification / repairing. We go through these development ideas, prioritise them and plan their implementation rhythm. The most urgent requests are attributed the highest priority, while in many cases it is feasible to implement several requests relating to the same topic at the same time. The objective and the end result of the requirement management process is to make sure that our developers have a clear understanding of what is going to be addressed next.

2: At Apprix, implementation of individual development ideas is handled by a team of highly qualified software development experts. For each implementation, a suitable team of experts in technical architecture, user experience / user interfaces, graphical representation, pedagogy as well as technical implementation and testing is assembled on a case-by-case basis. The team will make sure that the implemented product satisfies the functional needs, is easy to use and, on the other hand, can be integrated naturally into other functions of the system.

3: When the new functionality has been realised, the publication management will make sure that the function becomes a part of the Builder system in a controlled manner. In this context, it is further ensured that any code made for the Builder is implemented such as to integrate into and become a part of the rest of the code. The code, for example, is checked to make sure that it complies with the commonly defined security practices and that e.g., highly similar needs are not addressed differently in different parts of the software.

Finally, the goals we set, the wishes of our customers and the clear product development process have led us successfully to the point where Builder is, on the one hand, a specific system tailored to the needs of each individual customer, while on the other hand, offering all our customers a possibility to benefit of our continued product development efforts. 

Our objective is to work at any point of time on a number of major development projects, where certain totally new functionalities are being implemented into the software. In addition to major development projects, we are typically working on some dozens of minor individual requests / ideas. Thanks to our skilled and efficient developers as well as the clear product development process, in principle, something new is published in Builder every week: whether minor repairs or larger new functions. And these fruits of our development efforts are there to be enjoyed by our entire clientele.

Welcome aboard to use this eLearning tool that is tailored to your needs and wishes.

–

Author

Antti Rasi

As a member of the Apprix team, the author is involved, inter alia, in the improvement of the product development process, as well as designing of the architecture and new functionalities.