Evolve Gym
Gym Management Web Application

Users

The application was designed with various types of users in mind: manager-level, IT support, front desk employees, and gym members.

Manager-level users, such as owners, managers, and assistant managers are concerned with high-level business operations, analytics, and supervising daily operations. Members are clients who pay for access to the gym amenities. Members should be able to check-in with minimal interaction, easily make payments, and be informed with any issues with their account. IT support users are responsible for application maintenance and software updates. They may be concerned with technologies used, technological debt, and overall developer experience.

Employee-level users, such as front-desk representatives, are the primary user and interact with the application on a daily basis. Their tasks include checking in members, signing up new members, making sales, and assisting members with account issues. Less frequent tasks include closing member accounts and registering members for classes. Since front-desk representatives will be using the software most frequently, our focus is optimizing these particular users and their actions.

Requirements

Modeling personnel requirements is crucial to ensuring the application aligns with the expected personal capabilities so that it can be adequately operated at production. Additionally, it helps define and design application constraints and affordances around human limitations to ensure safety and limit risk in crucial tasks and operation.

Adding technology can reduce manpower cost and requirements throughout the product lifecycle. However, there are trade-offs to consider, as more technology can increase additional layers of complexity to integrate into the users mental model to understand and maintain the system.

For example, using Stripe solves the issue of secure payments and subscription management, but may require additional activity to problem-solve client account problems with Stripe payments. To solve this, a seamless integration could minimize the gap in mental models so the end user never has to interface with Stripe directly, otherwise additional training and/or more personnel experience could be required.

Dashboard Design

RESEARCH DEEP DIVE

Dashboard Design Notes

Show More

GQM Approach

Useful dashboard design can be summarized into two two aspects: selecting the “right” data and choosing the “right” visualization technique. Using the GQM model, I first defined which data to collect, together with the reasons why I collect it. Once the collected data is linked to the reason why we need it, it is easier to correctly interpret the data and reuse it for future projects, since we are able to put it into the correct context (Janes et al, 2013).

For example, if our goal for the dashboard is to check in gym members, some questions and metrics are:

• How do we verify the member identity? A combination of member fields, such as name, birthday, phone number, ID number, and picture.
• How do we verify the member access privileges? Member subscription status, start date, end date, and payment issues.

After defining the goals, questions and metrics, I used them to design the dashboard by placing relevant information within the right context.

User Flows

Employee Authentication

As a secure web application, all content is locked behind a secure web portal where only employees have access to the application. The requirements are:

• Limit access to only employees. So login and registration via social OAuth providers should not be supported.
• User registration is not supported, and an account must be manually created by the administrator.
• Username and password login must be supported. However, I do not want to store username and passwords in my own database at the risk of exposing user information.
• Ability to scale, enable MFA, or password-less authentication.

To implement authentication, I looked at NextAuth, Passport.js, Auth0, and iron-session. I decided to go with Auth0, however, there are a few quirks with Auth0 that may impact the user experience.

For example, to login, users are redirected to an Auth0-provided authentication portal that is hosted at a randomized Auth0 domain. In production, you can purchase a plan with Auth0 and set this portal URL to a custom domain.

Home

The home page is designed to welcome and orient the user. To orient the user, I provided three main actions for the application, as well as a quick navigation panel to present links to commonly used modules.

1. Primary Navigation. Standard website navigation.
2. Profile and quick actions. Extracts commonly used actions for visibility and quick access.
3. Action Cards. Primary actions and application features.
4. Quick Navigation List. Links to commonly used pages.
5. Notepad. Leave notes for yourself or other employees.
6. Contact Information. Useful references in case of emergency.

The home page includes a note-taking module to help users orient themselves by leaving notes for themselves or other employees. Contact information is included as a useful reference to situate themselves in their surroundings and can be used in case of emergency. I also considered refactoring this information into a footer to make it more available throughout all pages. Together, these modules are small steps towards a more personalized experience.

To logout, click on the icon at the header. On hover, a tooltip will appear displaying the associated action. On click, the user is redirected back to the login portal.

Membership Registration

To use the gym amenities, the members must be either: registered into the system, or, registered and have an active subscription. The first case are for situations in which we may want to provide guest access, but want to register them into the database and collect signed waivers. The second use case is the standard case where the member is a paying client and has an active subscription.

In practice, gyms will collect and store financial information on their databases to handle automatic transactions. For security reasons, instead of handling payments myself, I created a Stripe integration as our payment service provider. When a user signs up for a membership plan through Stripe, a webhook is used to create a member profile on our own database. Because we have two databases, one of the issues we’ll come across frequently is how to keep our database in sync with our database with Stripe.

To sign up a member, I follow the recommended check-out flow by Stripe to create a simple checkout experience without the engineering overhead required for a customized checkout integration. First, the employee must select a plan which redirects to Stripe’s secure web portal and checkout session, where the employee must gather information from the client to sign up for a subscription. Stripe can be customized to offer trial subscriptions for the first use case as well as handle signing and collecting liability waivers.

With a successful signup, Stripe will redirect back to our application and display a success page. This summary page displays three things. Your subscription status, what to do next, and an invoice summary. The “what’s next” is displayed before the invoice summary to remind the employee to finish setting up the profile, which takes precedent over the invoice summary which should also be emailed to the client.

On failure, Stripe will redirect back to our application and display a failure page, indicating the status and why it failed, and a button to redirect back to the sign-up page to try again.

When the user clicks on the button to finish setting up the member profile, it redirects to the members profile, where employees can make the necessary edits to their profile.

Member Profile

1. Member Information. Selectable tabs containing member information. Structure is consistent with member information structure on the check-in page to maintain a similar mental model.
2. Action Dropdown Menu. Contains actions to perform on the member.
3. Status Notification. Notifies users of subscription issues and/or appointments.
4. Member Overview. Extracted member information so users do not have to switch between tabs to reference these fields.

At the member profile page, employees can finish member registration by adding more information, such as their profile picture. Pictures are used to ensure the user checking in matches up with subscription. To edit the member image, hover over the user image to open the webcam module and take a photo. Member pictures are not publicly shared and are stored with AWS S3.

After, we can assign the newly subscribed member a physical ID card and input the associated card ID into our database. To finish, we can check in the member from their profile page using the action dropdown menu.

Member Check In

Because checking in members is the most common use case of this application, most application screen time will be spent on this page.

When a member checks in, they either present their card, or give identifying information so employees can verify their identification. At this point, the employee must check if the member is allowed access, check their subscription is active, check and inform members of any account issues such as outstanding balances, late fees, etc, and resolve them if possible, check for scheduled appointments and provide the member with the next steps.

Depending on the hour and day of the week, it is common for multiple members to queue up to check in. To support this, here is how the UI is designed to facilitate a quick check-in process.

1. Access Indicator. Indicates whether member should be allowed access.
2. Status Notification. Notifies users of subscription issues and/or appointments.
3. Check In Analytics. Daily check ins and recent check in timeline for brief overview of daily operations.
4. Member Search. Input member ID or manually search for a member to check in.
5. Action Dropdown Menu. Contains actions to perform on the member.
6. Check In History. Table of recently checked in members for fast access to user profiles.
7. Member Details. Selectable tabs containing member information.

The check-in module is designed to be used with a card scanner. When a card is scanned, the search bar should be automatically focused to receive input from the scanner and subsequently submitted. Without a scanner, employees can use the search bar to search and check in members. This is useful for situations where members forget or lose their card. The search module behavior is described below using a finite-state-machine.

For the case where there is an issue with a member’s account and there are people behind waiting to check in, it’s possible to quickly check in all the members first, then go back to the problem account using the check-in history located on the left side panel.

Design System

Screens

Two screens were used, one with a standard grid and another with a left panel and grid. Both are 8pt grids with 32px gutters and margins up to a breakpoint, at which margins grow to keep a fixed width. Both screens have a min-width of 1280px, as smaller screen resolutions are not a supported use case.

Typography

IBM Plex Sans was selected as the primary font because of its mechanical, geometric, yet human characteristics. It’s a beautiful typeface with excellent legibility that is well-suited for web applications and the spirit of the design that I’m aiming for.

Typographic scale and use follows IBM design language standards and guidelines.

Colors

Radix Colors is an open-source color system with a 12 step scale for each color. It’s easy to use, has defined use cases for each step, and, if used correctly, passes WCAG contrast ratio.

Evolve Logo

Δ - Delta
1. (mathematics, sciences) change in a variable.
2. (chemistry) ΔH the heat evolved (either released or absorbed).
3. (physics) ΔP a change in pressure.