Project Overview

TrivialLife is an end-to-end gym management platform that unifies memberships, scheduling, payments, and debt collection into one seamless experience. Designed to replace fragmented tools, the platform simplifies complex workflows, reduces operational friction, and enables gym administrators to manage their operations more efficiently.

My Role & Contribution

I worked as both the UI/UX Designer and UI Developer, owning the product from concept to implementation. I led the end-to-end design process, including user research, workflow definition, wireframing, prototyping, and high-fidelity UI design in Figma.

I collaborated closely with Business Analysts, Product Owners, and engineers to translate complex gym operations into intuitive user experiences. I also contributed to front-end development using React, ensuring design consistency and smooth handoff. Through continuous feedback and iteration, I refined the product to meet both user needs and business goals.

Research

• Stakeholder Interviews: I asked about their day, not about software. What took the longest? What did they dread? What did a quiet morning look like versus a bad one? The payer relationship issue and where a parent, employer, or partner pays for someone else's membership and came up repeatedly, and none of the existing tools handled it cleanly.
• Competitive analysis: I looked at one platforms actively used by gyms in the region. Scheduling UIs varied a lot in quality and some were actually good. Payment configuration was consistently poor across all of them: too many steps, no live feedback, no clear way to see what a change would cost before saving it.
• Workflow mapping: I mapped the full lifecycle of a gym membership end to end; from the first visit to contract signing, monthly billing, class attendance, and eventual cancellation or debt escalation. That map exposed where the current tool handoffs were happening and what data got lost in each gap.
• Task timing with real admins: I sat with admins while they did their actual work and timed the key tasks. Registering a new member required opening three separate tools. That one observation made the case for consolidation better than any interview quote could.

Key Insights

• Gym receptionists think about members, not transactions
• Third-party payers were more common than expected
• Scheduling only made sense built around recurrence
• No one could see what a contract would cost until it was too late
• Door access failures were invisible
• Debt escalation needed to feel like a next step, not a separate product

Challenges and Goals

Too many tools, none of them talking to each other

Gym offices in Norway were getting by on a patchwork of tools that weren't built to work together. A member's personal details might live in one system, their payment plan in a spreadsheet, their class bookings in a calendar app, and any payment issues escalated through a completely separate debt platform. Every time an admin needed the full picture on a member, they had to pull it together themselves.

This wasn't just inefficient and it caused real mistakes. Payment data entered in one place didn't automatically update another. Class capacity had no connection to membership status. When a member's card failed at the door, no one knew until the member complained. And when a payment lapsed, there was no natural path from 'overdue' to 'pre-collection' without leaving the main system entirely.

• No single source of truth: Member data, payments, class bookings, and door access each lived somewhere different. Getting the full picture on a member meant four tabs open at once.
• No proper Payment setup Installment plans, third-party payers, add-ons, and ATG groups were configured manually and with nothing to catch errors before they hit the member's account.
• Scheduling disconnected from membership : Class rosters and instructor assignments had no link to who was actually a paying member, so capacity management was guesswork.
• Debt management bolted on: Chasing overdue payments meant logging into a separate platform. Admins avoided it until the problem was bigger than it needed to be.

"Build one platform where gym staff can register members, configure contracts, schedule classes, track payments, and chase debt without switching tools, re-entering data, or losing context mid-task and make it fast enough that the person at the front desk can get through it while a member is standing in front of them."

That translated into a few non-negotiable design goals. Common tasks had to be genuinely fast and not just faster than before, but fast enough that admins stopped dreading them. Every module had to share data, so a change in one place reflected everywhere else automatically. The payment and debt workflows had to feel like one continuous flow, not two separate products. And the whole thing had to flex across different gym setups without requiring custom configuration for every client.

"The person at the front desk isn't a software specialist. They're juggling contracts, angry members, class changes, and payment queries, often at the same time. So speed and clarity mattered more than anything else."

Information Architecture & Wireframing

Organising by how admins think, not how software is usually built

IA - Member registration

Wireframe

Wireframe

I mapped the IA around the mental models that came up in interviews. Gym receptionist organised their work around members, instructors and not around features. So the navigation followed that: member profiles as the central hub, with contracts, payments, and class history all accessible from one place.

The member registration flow was the first thing I wireframed in detail. On the surface it looked like a sign-up form. It wasn't. It was five distinct decisions with downstream consequences: personal details, payment setup, referral tracking, contract signing, and payment confirmation. I sketched it as a stepped wizard early on, before any visual work, just to see if the logic held. A persistent sidebar showing where you were in the flow, and a cost summary pinned at the bottom that updated as you made choices. those two things came out of wireframe testing, not visual design.

Solutions

What I actually built and why

Those decisions were real problems that had specific design responses I can point to.

• Solutions 1

  A registration wizard that made a five-step process feel like one

  The member registration flow had five distinct stages and each one affected the others. Done badly, it would have felt like five separate forms. I structured it as a stepped wizard with a progress indicator on the left so admins always knew how far they were and what was coming. The floating cost summary at the bottom updated live as package choices and add-ons were selected. So by the time you reached the payment step, there were no surprises. That one detail eliminated a whole category of errors we'd seen in testing.

• Solutions 2

  A dashboard that answered 'what do I need to deal with right now?'

  I didn't design the dashboard around metrics. I designed it around urgency. The first thing at the top: door access failures, surfaced as real-time reminders rather than waiting in a log. Below that: today's visit count against the monthly target, because that's what drives staffing decisions. Then the morning and evening class grid. Then today's instructors. Everything visible in the first scroll is something an admin might need to act on within the next hour. The package promotions sit lower and their business priorities, not operational ones.

• Solutions 3

  Class scheduling built around recurrence, not individual sessions

  The old way: create a class, pick a date, save, repeat for the next 24 weeks. The new way: pick the days of the week, set the time, assign the instructor, set the capacity, and the system handles the rest. Day toggles with time pickers made the weekly pattern immediately readable. Instructors were assigned per class rather than globally, which gave admins flexibility to mix instructors across sessions without creating roster management overhead they didn't need.

• Solutions 4

  Twelve months of installments on one screen, and it still made sense

  A full installment table with twelve rows, with due dates, amounts, add-on costs, and a payer name could easily become a wall of numbers. The split-panel layout kept the package list on the left for quick switching and put everything about the selected contract on the right: the installment table, add-ons, gym access tiers, ATG toggle, auto-renewal and all on one scrollable surface. Change the payer, the due date, or an add-on, and the table updated immediately. No save-and-refresh, no recalculating by hand.

• Solutions 5

  A component library that kept 15+ screens looking like one product

  With this many screens, visual drift was a real risk. I built a component library in Figma covering every repeating pattern: form fields, card layouts, step indicators, toggles, badges, status pills, data tables. Every module used the same components. This meant the admin config screens and the member registration wizard felt like parts of the same product rather than features that grew up separately. It also made the React implementation cleaner and components were named and documented to match their code counterparts.

Prototyping

Starting a design system with basic components as a single library for all screens.

Button component with variant states

Step component with variant states

Build a real component library before designing any high-fidelity screen. With this many surfaces and this much data density, I knew that designing screens individually was a recipe for visual drift. Every toggle a slightly different shape. Every form field a slightly different padding.

So I started with brand and basic variables. Boring foundational stuff that nobody sees. Then I built the components on top of those variables, with every state mapped out: default, hover, focus, disabled, error. After that, I moved on to more custom layout components, like section headers with actions, labelled toggles, and list items with actions.

Design high-fidelity, complex screens before writing any code.

Every screen came with its own complexity that components alone couldn’t solve, so I had to think through the design before even starting prototypes. My approach stayed the same: I had to figure out what the admin is trying to do, then design the UI to make that process clear as it happens.

The thread running through all screens isn't visual. It's that every decision was about closing the gap between what the user was doing and what the system was telling them about it.

Testing

How I tested and what I changed afterwards

I ran small A/B tests with separate participant groups from the project team who currently work in gyms, working section by section across complete user flows. To save time, I created two design variations only for the more complex cases. After the sessions, I went back into Figma and fixed what wasn’t working: I introduced a blue notification banner that confirms a payment date change inline rather than hiding it behind a modal; added a “Preview” label to the class card so its draft state was unambiguous; kept the full installment table open by default instead of collapsed; and moved the add-ons panel into a split layout alongside the installments so admins didn’t lose their place while editing.

UI Development

I build production ready UI

My involvement didn't stop at handoff. I implemented the Design System and user interfaces in React with HTML/SCSS, which meant I was the bridge between design intent and production output. Building what I had designed gave me a precise understanding of where design decisions needed to flex to accommodate component constraints and where the code needed to be pushed to match the design vision. The result was a tighter gap between spec and shipped product than is common when design and development are fully separated

developing the UI component library in React

Reflection

What I'd take into the next project

The hard part of this project wasn't the screens. It was getting all the moving parts to play nice together. Change one thing in the registration wizard and you'd see it ripple through payments, contracts, and gym access. That kind of quiet, behind-the-scenes work took a lot longer than getting the visuals right and it's the work I'm proudest of.

The bigger takeaway for me is how much I like working close to code. Doing the Figma design and the React build on the same project gave me a much better sense of what's actually hard to build versus what just looks hard. That changed how I make design decisions now. The gap between what's in the spec and what ends up shipping is the thing that frustrates everyone in this industry, and it shrinks a lot when one person is watching both sides of it.