weinna's projects

PRODUCT THINKING

FULL PLATFORM

WEB APP

IN-DEPTH

Facilitating absence management for music teachers & administrators

through Sistema Tacet, an absence reporting platform.

Timeline

12 Months

May 2024 - April 2025

12 Months

May 2024 - April 2025

12 Months

May 2024 - April 2025

Role

Product Designer

Team

2 Product Managers

2 Product Designers

8 Software Developers

2 Product Managers

2 Product Designers

8 Software Developers

Responsibilities

Absence Events

Admin Dashboard

Design System

Absence Events

Admin Dashboard

Design System

This is a Blueprint project! UW Blueprint is a team of passionate students at UWaterloo who partner with non-profits to build tech for social good. For this project, we (Blueprint) partnered with Sistema Toronto, and we allocated a team of 13 students to build out this project.

Introducing Sistema Tacet—

an absence management platform for music teachers, used in conjunction with an administrator dashboard.

WHAT’S SISTEMA?

A non-profit empowering music-driven kids.

Sistema Toronto, a non-profit organization established in Toronto, Canada, is dedicated to providing accessible and high-quality music education to children and youth from underserved communities.

THE PROBLEM

Finding substitutes is a tedious process.

Sistema faces a challenge in efficiently tracking teacher absences and finding substitutes. Before, the org relied on a manual process involving Google Forms for logging teacher absences, and admins having to manually add these absences to the calendar.

THE SOLUTION

An absence management platform for music teachers.

So we created Sistema Tacet, a platform where teachers can declare their own absences, as well as substitute for their peers. With easy calendar navigation and filters resembling the oh-so-familiar Google Calendar, teachers and admins now have a way to efficiently handle any absence that comes their way.

Sistema Tacet Walkthrough for Teachers

SEE FINAL DESIGN

Phase 1: Define

THE CHALLENGE AT A GLANCE

Managing absences at Sistema was manual and inefficient.

Teachers relied on emailing admins to report absences.
Admins then had to track changes in Google Calendar, find subs, and keep everything updated — across 5+ locations.
This worked for one absence. But at scale? Chaos.

Teachers relied on emailing admins to report absences.
Admins then had to track changes in Google Calendar, find subs, and keep everything updated — across 5+ locations.
This worked for one absence. But at scale? Chaos.

Two user groups, different needs

Teachers need to:

log absences
attach lesson plans
claim available classes
get reminders + change alerts

Admins need to:

edit any absence
monitor absences across locations
manage users / roles
manage subjects & locations
export to Google Calendar

OUR SCOPE

Where were our heads at?

Some things we wanted to prioritize throughout this project:

Familiarity —

built around Google Calendar

Self-sufficiency —

minimal support post-handoff

Customization —

tailored to Sistema’s workflows

“Why couldn’t you just make a Google Calendar extension...?”

Sistema wanted full customizability and self-sufficiency. After some analysis, it was much easier to create our system from scratch than to try and adapt to Google Calendar’s existing infrastructure. We wanted Sistema to have an entire customized platform for themselves —that’s one of the privileges of being volunteers working with non-profits.

Phase 2: Design

PLATFORM DESIGN

Structuring for simplicity —and flexibility.

We designed two distinct experiences: one for teachers, one for admins.
Both use the same calendar foundation, but with different levels of control.

We designed two distinct experiences: one for teachers, one for admins.
Both use the same calendar foundation, but with different levels of control.

For teachers

A single calendar where teachers can:

Log and edit their own absences
Attach lesson plans
View and claim absences posted by others

Simple, streamlined, and focused on the teacher.

For admins

Admins are teachers too—but need more control.
We gave them access to:

Manage all absences (any user, any class)
Attach plans on behalf of others
View metrics, manage users, edit class structures
Modify subjects, locations, and email subs

Multiple touchpoints, full visibility, long-term self-sufficiency.

Why this matters

We built off what teachers were already familiar with (Google Calendar), but added just enough structure for admins to oversee the whole system—without introducing unnecessary friction.

Starting with our primary user: The Teacher.

HOW DID WE START?

Repurposing what worked

We began with what Sistema already knew— Google Calendar.

Rather than reinvent, we mapped how their current process worked and adjusted it for their needs.

We began with what Sistema already knew— Google Calendar.

Rather than reinvent, we mapped how their current process worked and adjusted it for their needs.

My Google Calendar

Sistema’s Google Calendar (admin)

Some examples...

Fun fact: we didn’t end up moving forward with the first one (only show applicable days) since we wanted our platform to support Sistema even in the case where they started to hold classes on other days of the week (i.e. we chose self-sufficiency over customizability in this case). Sometimes we needed to prioritize things even among the goals we set ourselves, based on what was more realistic.

The point here is that we used features from Google Calendar to guide our thinking, then we made decisions from there.

Key questions guided our thinking:

What does Google Calendar offer that we don’t need?
What can we adapt to better support absence tracking?

This framework shaped every customization decision, grounding each one in a clear rationale.

(of course, we also took a peek at a bunch of other references to see what was a standard across calendar apps (see below), but mainly focused on Google Calendar when repurposing features for Sistema.)

Apple calendar

Notion calendar

Misc calendar concepts on Dribbble

SKETCHES AND WIREFRAMES

Mapping the vision

We sketched out early structures and interface flows together as a team -- both PMs and designers.

To make sure we weren’t too quick to jump straight into the GCal layout, we used our wireframes to do a quick sanity check through usability tests.

USABILITY TESTING

Was the Google Calendar layout the right call?

Using our interactive lo-fi prototype, we conducted some quick tests with 5 users (3 of our devs, 2 misc students), just to ensure the GCal features actually work well for our intended purpose. Tasks included:

Declaring and filling an absence
Using filters
Navigating modal states

80% successfully completed the tasks. Overall, our users enjoyed the familiarity of Google Calendar ✅

Some affinity mapping helped us extract some good feedback, which led to improvements in button placements, upload flows, and copy.

DESIGN CHOICE: CALENDAR TYPE

Choosing a layout that balanced clarity, scalability, and backend simplicity.

Since our platform was centred around a calendar view, we explored multiple different layout options:

Fixed with left/right arrows

✅ Familiar to GCal users

✅ Easy to fit entire month in one view

❌ Fixed calendar date sizes → limited number of events displayed per day

Infinite vertical scroll

✅ Dynamically fits all absences, scalable

❌ Hard to jump far into the future

❌ Heavier backend load

Vertical scroll per month + arrows [Chosen]

✅ Dynamically fits all absences

✅ Easier to load in the backend

❌ Hard to jump far into the future

We ultimately chose vertical scroll per month + arrows. It provided just enough flexibility to view long-term patterns while keeping the UI light and navigable for both teachers and admins.

Why no daily/weekly views like Google Calendar does?

Sistema requested we omit time-specific views altogether.

Classes happen at the same time each day
Only one class per room per day → So we didn’t need time blocks or granular views. A monthly absence overview was more than sufficient.

This was another decision guided by our goal of customizability.

CHALLENGE

Defining Absence Modal States

Absence events function similarly to Google Calendar events, appearing as widgets within a calendar.

Clicking on one opens a modal containing key information—but the content varies depending on:

who the absence belongs to
who’s viewing it
whether it’s been filled

One big challenge I came across was defining which states needed to be defined, and how to design the differences between states.

As part of our goals, we wanted to customize the experience specifically for Sistema, which meant personalizing the experience for every relevant state.

What are all the different cases?

Each absence can be:

Filled (by who?) or Unfilled

Belonging to the User or another user

Perspective of the User or another user

This creates multiple permutations, each needing its own layout logic.

Filled/Unfilled

Belonging to

Perspective of

Unfilled

User

Unfilled

User

Other

Unfilled

Other

User

Filled by Other

User

Filled by Filler

User

Other

Filled by Other

User

Other

Filled by Filler

Other

User

Filled by Other

Other

User

Filled by Filler

Other

Filled by Other

Other

^ full list omitted for brevity.

For each permutation, we needed to consider:

Visibility: Who should this be visible to?

This helped us eliminate some permutations where it was redundant to show certain users.

Editability: Who can modify the data, and how should the design reflect that?

This way of thinking led us to introduce consistent labels like “Filled by [user]” and visibility tags like “Only visible to [filler] and [declarer]”.

One notable decision was to label [Unfilled, Belonging to User, Perspective of User] as “Unfilled” while labelling [Unfilled, Belonging to Other, Perspective of User] as “Open to fill”—This was to customize the experience for different perspectives.

The rationale is that users want their own absences to be filled, hence why an “unfilled” state is unfavourable. But as someone browsing to fill someone else’s absence, an unfilled absence acts as an open invitation.

This way of thinking led us to introduce consistent labels like “Filled by [user]” and visibility tags like “Only visible to [filler] and [declarer]”.

Handling optional states and special cases

We also accounted for optional fields and special cases that could subtly influence UI layout.

Each of these look different depending on the perspective, which ended up creating new states as well.

In the end, we defined 14 distinct modal states for our final designs. The orange notes indicate the notable changes based on the impacting factors.

Curious why this is categorized using “My Declared & Filled Absences” and “Explore Fillable Absences”?

Read the next section to find out why!

USER FEEDBACK → DESIGN DECISION

Accommodating our calendar for user intentions

In user testing, we noticed a recurring problem: teachers were confused by the many different widget states in the calendar. The variety of scenarios—claimed vs unclaimed, user vs others, filled vs unfilled—was overwhelming and difficult to interpret at a glance.

(For reference, by widgets I’m referring to these; the mini versions of the modals in the prev section. Check out all of our widget states we had from an earlier iteration—it’s a lot, right? Wait till you see all of them combined in the same calendar later.)

So we stepped back to reframe the design around user intent.

Instead of showing everything at once, we asked:

What are the two main reasons a teacher uses the calendar?

We found that they usually came with one of two goals:

Explore fillable absences—

“Can I help another teacher today?”

Monitor my own absences—

“Has someone filled in for me yet?”

Solution: Two Distinct Views

To reduce cognitive load, we split the calendar into two dedicated tabs:

Explore Fillable Absences:

For browsing and picking up others’ shifts.

My Declared & Filled Absences

For keeping track of your own events.

This separation aligned with real user tasks and allowed each view to be simpler, clearer, and more focused. And as a result, we updated the widget styles to make it easier to intuitively understand the states, with the additional context from the tabs.

❌ Old calendar view (overwhelming!)

✅ New calendar views, separated by tabs & updated widgets

Why did we choose to separate into tabs instead of just adding extra filters on the left?

Filters can be left on by accident, or multiple filters can be applied at once—leading users to think something’s missing or broken. By contrast, tabs force a singular, focused mode and guide users more intuitively through the base structure of the platform.

Final Designs - Teacher View

STRUCTURE

Easily navigate the calendar