Bitnoise_ build solid products

Delivering high-impact educational tools for German teachers and students

We created an intuitive self-assessment system for students, enabling them to track their tasks and mood, while providing teachers with a clear view of student progress through integrated evaluations.

About the client

Splint is an online tool designed for educational support planning, enabling teachers and specialists to effectively create, manage, and monitor individual development plans for students. The platform offers features such as collecting key information in student profiles, using diagnostic tools and observation sheets, as well as collaborating with other teachers and specialists to share observations and jointly develop support strategies. The goal of Splint is to support inclusive education by simplifying and streamlining educational planning processes.

The challenge

We recently delivered a project for one of our German clients - Inklusion Digital. Our task was to design and build applications in the form of ready-made products for two groups of users: German teachers and students. As part of the solutions delivered, both groups had a common assumption: to develop annual goals for students and verify their progress through the feedback process and self-reflection.

This is a really interesting example of a project that required us to be involved in every phase, from discovery to delivery and production release and launch. In this case study, we will show you how our comprehensive involvement in all project phases led to the successful creation of a product that gained recognition not only from our client, but also from the end user.

Scope of work

Discovery

We identified user needs, market demands, and product risks by mapping customer journeys and creating user personas. This phase defined the product scope and key functionalities, ensuring a strong foundation for the project.

UX & UI Design

Based on discovery insights, we designed user-friendly interfaces tailored to teachers and students. Prototypes were tested and validated to ensure an engaging and intuitive experience across all devices.

Development

We built and integrated core features using a flexible Scrumban framework, focusing on scalability and quality assurance. The phase ended with a seamless MVP delivery and a successful production release.

Discovery phase

In startups, the discovery and design phase is often overlooked but is crucial. This stage helps understand user problems, market needs, and technological possibilities. Our team, which consisted of the Product Owner and the client, gathered and analyzed information to define the product's scope, vision, value, and risks. How did we do that?

Customer Journey

By mapping the process of setting annual goals for students in German schools, we discovered that the current method was outdated and caused students to feel unmotivated. This insight was key to designing the core features of our product.

User Personas

We went to great lengths to deepen our understanding of our potential users, focusing on teachers and students in Germany. We learned about their characteristics, such as school types and age groups, and identified their pain points.

Business Model Canvas + User Stories

After completing work on the customer journey and user personas, we collaborated closely with the client to draft the MVPs' scope.

In very short summary, we knew that:

Teachers needed a tool that:

Is easy to use for various age groups

Can reliably document processes

Allows collaboration with other teachers

Secures students' sensitive data

Can be used on both private and school devices

Students needed a tool that:

Is fun and engaging (age-appropriate design)

Motivates them through gamification

Ensures their data safety

Is easy to use (mobile-first and simple login)

Works on both private and school devices

Those needs were converted into user stories with a Moscow prioritization. We ended up with two scopes of products: one for teachers and a second for students. Suddenly, we realized that we were creating products that truly meet user needs. The Discovery Phase lasted about two weeks, and we moved on to the design phase, which took about a month.

Design

The design was really smooth, primarily because of the great output from the discovery phase and the client’s involvement in the reviewing process. Teachers could expect a module as an add-on to the existing platform, and students would experience a separate app (independent of this platform). Teachers could, among other things, set annual goals together with students, leave feedback on progress, view results on an interactive chart, set a reward system, and monitor students’ emotions. On the other hand, students carried out the self-assessment process, were recipients of rewards, collected points and shared their emotions. We have validated the design three times and, most of all - tested prototypes with teachers and students. We have received an enormous amount of input that has confirmed that we are ready for the development process.

Goals & Grading system

When designing the “Goals & Grading” system, we had to account for the diversity of grading methods used across Germany, which can vary significantly between entire regions and even individual schools. The key challenge was to create a flexible solution that allowed teachers to define their own grading criteria and annual goals while ensuring clarity and motivation for students. As a result, we developed a module enabling custom configurations, visualizing results through interactive charts, and integrating reward mechanisms and progress monitoring.

Self-assesment process

The main feature of the student app is self-assessment, where students evaluate both their task completion and overall mood. This data is then compared with the teacher’s evaluations in the teacher’s app, creating a comprehensive view of student progress and fostering better communication between students and teachers.

UI - Colors & Typography

Unlike the teacher module, the student application needed to cater to a significantly younger audience. We adapted the design, colors, and typography to ensure the interface was both visually appealing and engaging for children. Bright, playful colors combined with larger, rounded fonts created a friendly and approachable look. The design focused on simplicity and fun, making the app intuitive and enjoyable for younger users while maintaining functionality and usability.

Custom Illustration Style

While designing the UI, we developed a unique illustration style tailored specifically to the application’s needs. To enhance consistency and expand the visual assets efficiently, we used AI tools to generate various adaptations based on our original style. This approach ensured that every element aligned perfectly with the app’s aesthetic while maintaining a cohesive and polished look throughout.

Delivery phase

Agile work organization

We engaged four specialists for the delivery phase - Product Owner, backend, frontend developer and tester.

When we started, we knew that:

we want to build an MVP in the form of an application for students and an additional module attached to the main product for teachers,

we have very clear expectations, a well-prepared design,

we are aiming for a production release in March 2024 (at that time, we had the end of December 2023),

we have to ensure the scalability of the product and remember the assumptions of the Discovery phase

We started the development itself by:

setting up the infrastructure, building the architecture of the new student application,

integrating this application with the existing platform for teachers

working on the first endpoints of the login process (probably a classic of every startup - you start dev from the login area).

This soft start allowed a smooth, gradual addition of a Frontend programmer and QA. Typically, backend work was two weeks ahead of frontend work on each project stage. Our QA specialist, on the other hand, divided his time between working on our MVP and the second team, which worked regularly on the educational platform for teachers. This is how it went for the following weeks of work.

Getting things done

Due to the specifics of working for the client (including the lack of Scrum Master/Agile coach roles, the need to synchronize work and releases with the second development team working in parallel) and a completely predictable project (because there was a design, an available client) - I decided to try a delivery framework with an exciting name: Scrumban. How did it look for us?

Abandoning cyclical sprints in favor of flexible releases

Working in regular sprints was out of the question - among other things, due to the size of the team, we knew that it would simply be management "overkill". For us, the moment of meeting with the client for a review and the decision to release was a fairly flexible statement based on "okay - interactive, working things are starting to appear - we feel that we should collect feedback on this part". However, once we had a demo, it was really effective, interactive and valuable.

Backlog and roadmap as the primary source of information

As standard, as in most agile frameworks - we worked with a backlog and roadmap in Jira. At the beginning of development, we built the roadmap of both solutions (the application for students and the new module for teachers). We corrected it continuously, considering change requests or delays/accelerations. The backlog lived daily - supplemented with tasks, stories, and bugs - and was released by the product owner to the Kanban board of tasks at the right time.

Limiting team meetings to daily stand-ups and refinement sessions

Our team was not very large (but agile!), so we decided to limit the daily to three times a week. Due to the abandonment of cyclical sprints in favor of flexible releases, we also eliminated planning meetings. We focused on refinements with the client in written form (on Discord) and in the form of cyclical meetings (bi-weekly). Thanks to this, we kept both the backlog and the roadmap up-to-date and prioritized, and production pauses did not happen to us.

Product quality assurance

Our development team ensured the product's quality throughout the project's entire life cycle. As part of the project implementation, we focused on 3 key aspects of ensuring the quality of the product, namely:

Manual and unit tests

The limited product scope led us to forgo test automation. Programmers handled unit tests, while the QA engineer conducted manual testing. Each task was tested individually against design and technical requirements, followed by integration tests for completed task groups within an epic.

Involvement of alpha and beta testers

We engaged external testers to simulate the roles of students, conducting these tests during the development phase to ensure the product met user expectations. Ultimately, we involved the end-users themselves - to gather direct feedback and refine the product for successful sales and adoption.

Pre- and post-release testing in production

Since our module was connected to the client's platform at the end of the project, we had to ensure minimal impact on the production environment. So, we conducted additional testing in the production environment to minimise the risk of releasing bugs.  We really felt that we did a great job securing the quality of our product. The production release went very smoothly, and we haven’t had any bugs after all.

Summary and conclusions

To sum up, the discovery, delivery and testing phases in this project were exceptionally dynamic, but our approach based on flexibility and adapting to the client's real needs brought the expected results. The most important thing is that we delivered the project in 4 months (we closed the development work in April, as we added extra features and needed to wait for the marketing and sales team for their input) and managed to release both solutions in production in May (client's business expectations). Focusing on a small, essential team: Ui&Ux designer, two programmers, one tester and the Product Owner minimized the costs for the client and helped us maintain agility. Giving up cyclical sprints in favor of flexible releases allowed us to better adjust the work pace to the project's real needs and the second parallel team. Thanks to this, we could respond more effectively to feedback and introduce changes smoothly and without downtime. Limiting meetings to a minimum allowed us to maintain high team productivity without unnecessary pauses in work. Soft start allowed savings in the project and conclusions from the discovery phase - to reduce the rework time by 50%. What made us happiest and convinced us that our approach to things makes sense is that 80% of teachers and students consider the product very good and intuitive (shown by our survey and tests!).

Technologies

Random screens

Let’s get talking

Tell us about your needs

Tell us about your needs and we'll get back to you shortly