There are three large components of what I worked on: the research, the design system, and the actual designs of the system admin.
Research
The product manager set up interviews with several different levels of Bowlero managers. Here, another designer and I conducted user interviews and presented a prototype to gauge interest. The feedback we received was overwhelmingly positive from these managers, providing valuable insights into the project's potential success
Design System
I worked alongside two other designers in contributing to the design system. As it was being used across projects, i was involved in the contributions and approvals for the updates to components and documentation to the Design System.
However, there were specific use cases that I alone defined for my specific project and submitted for approval. Additionally, I defined primary and neutral color palettes that were attributed to my project alone. As a team, we decided to use different primary colors (and therefore neutral colors) & logos to differentiate between our products. In order to implement this, we used Figma’s theming feature. This design system was the foundation of my work.
Admin Console
I utilized the components from the design system to design the admin console. Close collaboration with the product manager and developers helped refine designs based on requirements, which included each feature beginning tailored to specific user permissions.
My delivery timeline was separated into each feature: Communications, Rewards, and Employee Screens.
Communications
This was the biggest ask from Bowlero. They wanted a quick way to communicate with all employees. The requirements for the communications screens included:
• Center managers needed to be able to send ut communications to their own center
• Regional & District managers needed to be able to send communications to the regions and/or districts under them
• Managers needed to be able to schedule communications to be posted at a later date
• Managers can choose a duration of time that the communication applies. If there's no end date, it will be archived after 30 days
• Managers must choose which category their communication pertains to
Employee Screens
Another large component of this admin console is the Employee Screens. As this is a permissions-based admin console, I needed to ensure that each of the Employee screens had a view for each permission. The volume of these screens are a bit too robust for this case study. If you’d like to see more, please contact me.
The data displayed for an individual employee is based off of the data collected from the Mobile App side of this project, as well as integrations from the HR software, JD Edwards to display employment information.
For these screens, the requirements were to show the following:
• Employee Information
- Phone number
- Email address
- Employment status (active/inactive)
- Start date / End date (if applicable)
- Bowlero ID number
- Main center where they are employed
- Manager
• Activity history
• Coin history
Rewards
The Rewards aspect is important to this project, as this is where the employees get value from the Mobile App. Without the Rewards Store, this is just a productivity tracking application. But Goldfish is more than that. Employees are able to earn coins by completing activities, then can use those coins to purchase whatever they want from the Rewards Store.
For the admin console side of the project, the requirements for Rewards were:
• A table display of all rewards
• The table needed to list the following information
- Product name
- Status (active / inactive)
- Thumbnail Image
- Coin value
- ASIN (Amazon Standard Identification Number
- Product category
- Variants (colors, sizes, etc)
• System Admin ability to "Add New Reward"
• Ability to sort table items
• Ability to filter table items
As we approached the launch date, the requirements were shaved down. After some research, it was obvious that “Product Variants” was an unnecessary field for the MVP launch. This is because, on Amazon, variants of products typically vary in cost. Instead, I listed these rewards as separate items.
Additionally, the tables were auto-sorted to show “active” status reward items above any “archived” items. Because it’s expected there will be many reward items in the future, the sorting functionality was not useful. Instead, users are able to leverage the filters to search through the rewards.
