Concept

The idea for Practice HQ came about long before a solution did. I spent over a decade teaching music at the elementary, middle, and high school levels. Every music teacher I have ever met, whether classroom or private instructor, will tell you one of the most difficult things to motivate and track is student practice. In 2024, I had come to a place in my web development experience where I felt up to tackling the problem head on, and the results have been outstanding.

I went through three iterations of this product in the initial phases:

One of the central ideas I wanted to address in the design was student authentication. During my time teaching elementary students I was responsible for managing their one-to-one devices. We opted for a QR code badge they wore on a lanyard for logins through a third-party application. I liked this user flow as it allowed the product to be used by music students of any age, regardless of their ability to remember usernames and passwords.

The primary goal of this web app was to track student practice time, albeit on an honor system, by having them use a time-clock system of checking in and out of practice sessions. The end of each practice session is accompanied by a journal prompt as reflective journaling has been proven to enhance the benefits of practice time.

Design

The primary design concepts for Practice HQ were dark gradient backgrounds, bold floating page titles, and rounded cards using glass-morphism for floating overlaid organizational structure.

I knew from my previous iterations that I wanted a dashboard as the go-to page for using the app, and that dashboard should be different for teachers logging in and students scanning to log in. I wanted the dashboards to provide quick access to primary actions users would take, and I wanted them to be able to complete those actions without navigating away.

To accomplish this, a responsive multi-column layout was used for the teacher dashboard, main tools are accessible from drop downs and context menus, and forms and information prompting are done through modals to prevent extra navigation. The student dashboard is much simpler in design and provides quick access to their own personal stats, goals, resources, and a clear call to action for starting a practice session.

Another design principle that I kept in mind while working on this project was that the information and data about practice time could be motivating to a student and helpful for teachers if it was easily understandable. Rather than presenting the data in number format, I chose to use custom charts where possible.

Solutions

Following the theme of not requiring much navigation to use the app, I wanted students to be able to stay on the same website while practicing. This meant they would need tools they typically would visit other sites or open other apps to use. I built a custom metronome and chromatic tuner as stand-alone tools that are publicly accessible on the website so students can use these as they practice without navigating away.

As I mentioned above, the QR code login flow was an essential part of this app design, so the authentication flow had to be different for students and teachers. I was using API route handlers in Next.js for this project, so I created unique hashed codes for each student when the teacher created their profiles. This code and their time of profile creation combined into a query string I could attach to the API endpoint that would validate the existence of this set of code and timestamp and log the student in, redirecting them to their student dashboard if successful.

I was able to pilot this product with a small elementary band I taught and one issue quickly rose to the top of the bug priority list. When students accidentally clicked stop session, or when they forgot to click stop session, their practice time would end up looking very strange. I didn’t want students to have access to manually adjust their practice logs (the honor system only goes so far), so I wrote code to check the total time before the student submitted the log.

If the time elapsed was outside the normal parameters (between 90 seconds and 90 minutes) the student would be required to submit this log for approval. The approval notifications show up on the teacher dashboard and, once approved, are added to the student’s history.

Another problem I ran into once I invited other teachers to try out the app is that the process for creating a resource or goal for a student was simple, but when you are repeating that process for many students using the same resource or goal, the task feels much harder and is inefficient. However, the database structure I designed attached the resources and goals directly to the student accounts, so reusing them would be difficult to do.

To solve this, I restructured my database to create goal templates and resource records that were attached to a teacher through a library. When creating a new goal or resource, the item is automatically added to the teacher’s library. This way, when they go to a new student they can choose a previously used resource and the link is assigned to the student for viewing. Even more efficiently, the teacher can assign resources or goals to entire groups of students at the same time and manage older library items on the library page.

Reflection

Practice HQ has been the most practical and widely usable project I have taken on to date, and I believe it has real potential to solve problems for music teachers struggling to motivate and track student practice. The design process ended up in a good place after a few iterations, but more initial research and planning in the inception of this project could have prevented many of the headaches I ran into while developing it.

This project has reached the production phase, but there are still a few steps I would like to take to move it forward. I would like to add a parent permission step to the student creation process for minors so that parents both grant permission for their student to use the product and create their own account for monitoring practice time of their student. I would also like to eventually move to a subscription model and integrate a payment service like Stripe to generate revenue from the work I have put into building this SaaS.

My immediate goal, however, is to begin marketing this to private lessons teachers so I can obtain more real user feedback on the design, viability, and bugs that still need to be worked out.