Jenny Ho




Making property data approachable at Archipelago



Improving access to social services at Healthify



Personal projects

Healthify



Cleaning up admin tools
Research, product design, UX writing, process improvement



The challenge: In the background, the product support team uses admin tools them to set up new customers. We needed new complex permissions to allow organizations to collaborate while keeping patient data secure. However, these pages had accumulated too much tech debt.

The solution: We needed to make some changes to the admin settings easier to use, including reorganized layouts, descriptions for all settings, and read-only versions.

My role: I conducted user interviews, spruced up the information architecture, did UX writing, and designed UI templates. I also ran review sessions and usability tests to validate designs.

Impact: We could safely roll out new features and permissions without risking exposing patient data. Plus, admin tools became less intimidating to use. The Product Support Team became more familiar with permissions, and we delivered some low-effort, high impact bug fixes to reduce errors.  



What were the problems?

When I interviewed the product support team, their biggest concern was making a mistake with high-stakes consequences. They also complained that onboarding was a manual process that took time to learn. Even with training, no one knew what all the permissions did.

Example of view mode.
Inexplicanly, some editable permissions were in view mode.
Example of edit mode.
There were also UI-specific problems that should be table-stakes. Permissions were all on one long page, without a logical order. Settings have edit and view mode, but there were some editable permissions in view mode.



How do we make admin tools less stressful?

Ideally, the product support team should feel comfortable using admin tools. To get there, we needed to make these improvements:
  • Manual tasks can be sped up with improved UI.
  • Each permission needs a description.
  • Similar permissions should be grouped together. 
  • View mode should not be editable.

The first thing I designed were a set of 3 templates for all permission layers.
  • A user would start on an index page with search, edit, and add functionalities. 
  • A user can see the current settings in view mode
  • A user would access edit mode to update settings.

Index pages have tables to help users find the right settings.
By default, settings are in view mode to prevent misclicks.
Edit mode is an interactive version of view mode.


Onboarding new customers can & should be better.

There are 4 layers of permissions. Networks are made of linked companies, which are made up of teams, which are made up of individual users

Ideally, the process is top-down, starting with networks and ending with users. In practice, product support starts with the company and jump around layers.

To support the ideal process, I grouped permissions on the nework, company, and team levels into tabs (from basic to intermediate to advanced). I also grouped permissions with similar UIs (input fields, toggles, or tables) together and ordered them either logically or alphabetically.

First, creating a network can be done in 3 steps.

1. Create the network.

2. Add companies to the network.
3. Edit partnership settings.
Same for creating a company.

1. Edit general settings.
2. Add teams to the company.
3. Add social services that the company manages.
Creating a team is simpler, with 2 steps.

1. Edit general settings.
2. Add users to the team.

Finally, users can upload a spreadsheet of users to a team. They don’t need a user page for this step.



Every permission needs a description. 

I learned what every permission did, so that I could write a brief description for each one. Not only would this make training easier, anyone editing would know the consequences of their actions upfront.

Company integration settings.
Team integration settings.



I stressed-tested the new designs.


I ran usability tests with Healthify employees who had different levels of familiarity with admin tools. Some used the pages frequently, and some have never seen them before.

They onboarded a fake customer in with a clickable prototype while I observed. Seeing where testers got frustrated or confusted led to subtle changes like new interactions and revised UX writing.

This banner was revised so people knew what it did.
This new column helps users better differentiate companies.
This new interaction prevents jumping between layers.


We can’t get everything done. Now what?

The long-term design included UI templates with an extensive set of permissions that covered the product support team’s needs.

Realistically, the number of organizations to onboard wasn’t as much as we’d expected. Plus, there were more pressing product priorities at the time. I worked with the lead engineer, product manager, and delivery manager to reduce scope.

What got cut
  • New UI designs for the index and edit pages. 
  • Sidebar menu. It made navigation faster, but it wasn’t critical.

What we can do
  • New UI designs for view mode.
  • Descriptions for all permissions as static text. 
  • Rearranging permissions into intuitive categories.

The banner is new, and everything below it is legacy UI.
View mode is entirely revamped.

Edit mode uses legacy UI, but with reorganized permissions and helper text.