ReKalibrate

Mobile app and desktop admin panel

Background

Before it became ReKalibrate, KettleSpace started as a coworking business in New York City. They rented out dinner-only restaurants and bars during the day and turned them into fully functioning coworking spaces.

As a remote employee at Zapier, I loved working from the KettleSpace locations all over Manhattan. When I saw that they were launching a new SaaS product for managing remote work, I jumped at the opportunity to get involved.

Client

After successfully testing a white label Scan & Reserve app for NYU to help students/faculty book spaces throughout campus during the pandemic, KettleSpace wanted to integrate space reservations into their existing B2C and new B2B product to expand their relationship with NYU and eventually get acquired.

Context

I was brought on to design the user-facing reservation flow (mobile) and redesign the existing admin panel (desktop) over the course of 8 weeks in 2021.

My role

Scope

I worked directly with the CTO, 3 software engineers, and the Head of Product as the sole UX Designer. I collaborated on ideation, user task flows, and information architecture with the CTO/Head of Product. I led usability testing, visual/UI design for all wireframes, and the final high-fidelity prototype. Operating in an agile environment and meeting for standup every day, I designed one small piece at a time, handed it off to the engineers, and iterated on feedback each step of the way.

Team

  1. NYU wanted to start testing the first version of the new mobile reservations flow in a month.

  2. We did not have the technical bandwidth to put all filters on the same screen.

  3. The app had to pass a rigorous accessibility review conducted by NYU's team.

  4. The app had to be able to accommodate both B2C and B2B use cases.

Constraints

App Research

Since we weren't going to put all the filters on one page, I clicked through a bunch of existing multi-step mobile scheduling flows and put them into Miro to draw inspiration. After analyzing several patterns, I broke down the main questions going into the design:

  1. What information do we need to gather up front vs. leave flexible?

  2. How will the answers affect the results?

  3. In what order do we ask these questions?

  4. How will the results be displayed?

  5. What choices will users make when they see the results?

Competitive Analysis

I designed a user flow that would take users step by step through a wizard to narrow down their options.

This would solve both the engineering constraint as well as a UX problem with the existing app that forced users to select filters without knowing how each one affected results.

User Flow

App Design

We determined the order of questions as a team, then I got to work building out the lo-fidelity wireframes.

Lo-fidelity

Knowing accessibility was top of mind for NYU, tested all of KettleSpace's brand colors for WCAG contrast and kept these rules handy throughout the process. NYU also hosted a workshop with an accessibility expert to teach us about how to design for Screen Reader, VoiceOver, and Voice Control, which I really enjoyed.

Accessibility

Given our quick timeline, I wanted to put a mid-fidelity prototype in front of some users to get feedback before going high-fidelity. I conducted usability testing with 2 Kettle members and 3 internal community managers who interact with members on a daily basis. I also got more generalized feedback from the CEO who was conducting demos with potential clients and gathering feature requests.

I did some comparative testing on different ways of displaying results:

Usability Testing

Coming out of interviews, I narrowed down a few Jobs To Be Done:

Jobs To Be Done

I determined that the wizard experience might work well for a Meeting Maker but not for a Quick Huddler or Creature of Habit. Without the ability to filter, I had to get creative with how to create a faster booking experience.

One of my usability testers suggested looking at ZipCar's app for reservation inspiration, which is where I discovered the answer to my problem: shortcuts!

I proposed that we give them the opportunity to shortcut the wizard depending on what information they had upfront:

This idea was well-received, particularly by the CEO who had heard similar feedback in demos. My next step was building out the flows for each shortcut. Here is the final prototype!

High Fidelity Prototype

Admin Panel Research

Once we deployed the mobile side, we got to work redesigning the desktop admin panel (called KettleOS), which was used to manage locations/spaces and how users would access them from the frontend reservations app.

Background

  1. Testers found the admin confusing to navigate/learn due to the varying colors, shapes, and hierarchies. For example, editing was challenging because there were too many "Edit" buttons that pointed to separate modals, and the scope of the edits was unclear.

  2. The prototype needed to be moved from Sketch/Invision into Figma.

Problems

Having never designed an admin panel before, I spent the first couple days reading about how to approach this project and looking at existing products. Here are some of the resources I used to build my foundation of knowledge going into this project:

- Interaction Design For Trees by Hagan Rivers
- Easy Figma Auto Layout Tables Tutorial by Sera Tajima
- Designing An Admin Panel by Christian Behler
- How To Create A Decent Admin Panel by Ivanna
- Apple's Human Interface Guidelines and Google's Material Design Guidelines.

Secondary Research

Information Architecture

First, I got acquainted with the overall data structure and hierarchy of objects, which I diagrammed in Miro:

Sitemap

Then, I diagrammed the original sitemap and proposed a new architecture that would move the most important objects to the top level and standardize the edit structure to only include "add" at the top level and "edit" at the individual level.

This way, the paths to view/edit a Location, Work Group, and User would all look the same.

I compared different patterns for navigation and settled on this Finder pattern since we had a small, finite number of layers (unlike the Miller Columns) and needed to display non-tabular data (unlike the Collapsible Table):

Tree Navigation

The original design contained several different patterns to display different kinds of information. I analyzed all the data types and narrowed it down to 2 types: key/value pairs and tabular data. I then used simpler patterns for each data type to maintain consistency throughout the new design.

Data Visualization

Before & After

Before:

  1. All fields forced into small modal

  2. Schedule and permitted locations consolidated and collapsed, complex and difficult to view

After:

  1. Full screen available

  2. Schedule and permitted locations separated and able to see at a glance

Before:

  1. All data displayed on one page in different patterns

  2. Multiple "Manage" buttons

  3. Many color combinations (white on green, white on red) not WCAG compliant

After:

  1. Tabbed out sections and used the same pattern to display data

  2. Global "Edit" button

  3. All color combinations AA+

Before:

  1. Prominent "Deactivate" button

  2. Floor information collapsed

After:

  1. Has its own screen to leverage space and minimize potential for clicking out and losing all changes

  2. Tabbed out sections that can use the full screen

Before:

  1. Pulls out in a small modal

  2. Different modals for different sections (details, schedule, floors)

After:

  1. Moved "Deactivate Button" behind Edit screen

  2. Floor information displayed in a table

Results

After I completed my redesign, KettleSpace accomplished their goal of being acquired by WorkChew, a DC-based workspace company. The admin product was renamed ReKalibrate. You can see my design live on their website:

Acquisition

Challenges

Since KettleSpace membership was relatively inactive due to the pandemic, it was challenging to find testers. I improvised and leveraged coworkers who interacted with members regularly for much of testing. To minimize bias, I only chose coworkers with no involvement in the development of the app. I also spent time interviewing them in addition to usability testing to make the most of our time. This ended up being crucial for informing the final design.

Recruiting

I learned a lot about how Component Libraries work and how designs interact with them. In this case, the engineers were pulling components from a React-based framework called Grommet. I got a few pings asking me what different components in my Figma design were called, so they could locate them. I realize now that adding annotations with the corresponding names would've saved a lot of time.

Engineering Handoffs

Prior to this project, I didn't have a ton of experience with Auto-Layout but after this project, I can hardly imagine working on any project without it! I definitely learn best by doing, so I'm super grateful to come out of this project with this new skill.

Auto-layout