The Context

Calcium offers B2B and B2C solutions to keep people healthy using a pathways framework. In this framework, a provider, employer or administrator can assign a pathway to an end-user, who then accesses it on the mobile or web app to view information, answer questions, sync medical devices or upload other content. Providers, employers or administrators could then see individual responses and activity as well as aggregated data on an admin portal.

Currently, the most common use is for employers to use pathways to monitor their employees’ vaccination status and daily COVID-19 risk, but Calcium is hoping to expand to a provider use case in which clinicians could remotely monitor a patient’s data (like blood pressure or blood glucose), provide education on conditions, or prepare them for procedures.

The Challenge

In late fall 2021, it was decided that a new administrator portal needed to be built as soon as possible to accommodate increasing customer demands and technical limitations.

As the Senior Product Designer, I was asked to design a new portal that not only would accommodate the current COVID-monitoring use case and future potential provider-focused use cases, but also have improved functionality to meet customer needs.

Initial Requirements

From the beginning, we knew admins needed to be able to:

• create and manage large numbers of nested groups, group administrators and pathway members

• manage pathway invitations

• quickly view the results of the pathways at the organizational level

• restrict group admin permissions by group level and function

Compounding Factors

There were also a number of compounding factors impacting the project:

• Existing business logic around managing groups, admins, pathways and pathway members and the relationships between them was preventing the functionality that admins needed.

• The management of groups, admins, pathways, pathway members and permissions would vary by organization type, size and structure, creating a huge amount of unknown use cases.

• Calcium specifically wanted to build the product for future provider use-cases, but we had no data on their needs or goals.

• We did not have a pattern library or consistent fonts, colors or components across or within products, which was slowing us down from both a design and development perspective. We also were going through a brand redesign, and were unsure if we could change any colors or fonts.

• Development was starting in 10 weeks, creating an extremely limited time to deliver a large product.

The big question

How might we empower large organizations to easily manage complex data and monitor their employee’s COVID risk and vaccination status while also accommodating potential future unknown clinician use cases?

Next Steps

I developed a plan for uncovering and validating as much information as I could within a short time span so I could complete high-fidelity designs as soon as possible.

Phase 1: Fleshing out the problem and defining MVP (~ 4 weeks)

• UX operations

  • I immediately started discussions across multiple teams to find a pattern library that worked with our existing code bases and then created basic patterns in Figma that aligned with our current brand. I selected a font and colors from our existing brand to implement across products.

• Problem elaboration and user research

  • Because group structures were the most complicated and riskiest part of the new portal, I held a workshop with a number of colleagues to review potential organizational structures and situations we may need to accommodate and make sure we didn’t miss anything.

  • I met with Customer Support to learn about the issues that customers were facing with the current portal. I also conducted research with five existing customers, who revealed some specific use cases that I needed to take into consideration when designing.

  • I conducted contextual inquiry research with 10 clinicians to start to fill in our knowledge gaps. We gained valuable information about providers’ goals, but the biggest takeaway was confirming the hypothesis that we need to provide as much flexibility as possible so that providers can view the information they need for their particular use-case.

• MVP identification

  • I reviewed the existing product with several colleagues to determine what features needed to remain in the new version and also where there was development work that had already been completed that we wanted to retain in order to speed up the time to MVP.

  • I led the definition of what would be included in the MVP by creating an excel sheet and working with my colleagues to clearly state which features would be in MVP and which would be able to wait. We refined the document over several weeks.

• By the end of Phase 1, I had a clearer view of the product requirements and design needs - especially the need to make the product as flexible as possible for potential future use-cases.

Phase 2: Laying the groundwork for designs (~ 3 weeks)

• Secondary research

  • I conducted desktop research on complex products that enabled users to manage people and their data, especially CRMs and LMSs. I also found a lot of great articles on designing complex data tables.

  • I researched and documented the different types of organizational structures of specific hospitals and other types of provider networks to ensure that initial designs would work in different situations.

  • I learned as much as possible about different types of permissions so I was prepared to discuss it with the architecture team.

• New structure definition

  • I defined new business rules for our existing elements of groups, group admins, pathways, pathway members and permissions that would enable organizations to have both the control and flexibility.

  • Based on those business rules, I defined an initial information architecture for the navigation with five tabs to easily allow the user to manage all of the information they need, while retaining some of the existing development work.

  • Because we did not have time for additional research, I internally reviewed the rules, permission structure and architecture with colleagues to determine feasibility and walk through how these changes would work with current customers and potential provider scenarios.

• Initial designs

  • Once the new business rules and information architecture were approved, I started sketching out designs for the largest, most complex and most important parts of the product - the “Manage” tab, where admins could manage all of the groups and group administrators and the “Invite” tab, where admins can invite members to pathways.

  • I reviewed the designs internally, got feedback from colleagues, and iterated as quickly as possible.

• At the end of Phase 2, I felt that I had enough information and requirements to start on high-fidelity designs.

Phase 3: Lots and lots of design work (~ 4 weeks)

• I began high fidelity designs on the “Manage” tab, which would allow admins to create a nested group structure and be able to manage group administrators and pathway members within that structure. I also created components in the pattern library in Figma as I went along.

• During this phase, I met even more frequently with Product and Development to get feedback, iterate on designs, and work together to make sure we didn’t miss anything or create any logic loops.

The Solution

This project was huge and describing the full solution would take a very long time. Here are some highlights!

• I removed existing business rules that linked certain pieces of data unnecessarily and allowed all of the data to be managed independently to allow members to be in multiple groups and easily move between them.

• I created a nested group tree structure to visually show group hierarchy and quickly add, delete, or select a new group. Clicking on a group takes you to the group’s page, where you can manage the group itself and manage its administrators.

• I developed a roles and permissions structure that would allow admins to only have access to the groups to which they were assigned, but also have different levels of access:

  • access to all data across the organization

  • access to edit all data in assigned groups

  • access to only view data in assigned groups

  • limited access within assigned groups, which would allow the admin to see generic contact, group and pathway information but not medical information like vaccination status.

• I included customizable tables with resizable columns plus search, filter and sort capabilities to manage potentially large amounts of information.

• To accommodate large data sets, I included the ability for admins to bulk upload data, perform bulk actions, or operate on a piece of data independently. When bulk uploading data, the errors would be in a downloadable .csv file.

• Based on clinician feedback, I changed the member details screen to be a slide out, rather than a side-by-side view. This lets admins easily see the large amounts of data in the table and in the member details area.

• I defined patterns for buttons, modals, notifications, alerts and standardized the microcopy for each. I created a number of patterns in our new Figma library for future use, including navigation, tabs, buttons, labels, icons, and more.

• I left space in the menu for features we would need post-MVP, such as more extensive settings and permissions.

Outcomes

• After the Manage and Invite tabs were complete, I created designs for the Dashboard, Members, and Pathways tabs and continued to tweak designs as new customer requests came in. I continued to attend meetings to provide support to the development team, fill in any design gaps, create designs for urgent feature requests, work with product on prioritization, and address any issues that come up.

• As of the time I left Calcium in May 2022, we received positive feedback from our leadership team and Customer Support team and were set to launch in the near future! Customers who had a sneak peak with our Customer Support team were also very excited. I wish that I had gotten to test it!

Challenges

• The timeline did not allow room for extensive research or exploration.

  • The biggest challenge was simply not having enough time to do the amount of research or extensive design work this project could have benefitted from. I did not have much time to dig into the current use case with more customers, conduct usability testing, explore many different potential solutions or play around with UI. I had to commit to solutions quickly using the information I had and move on so I could complete the project on time. In retrospect, I think I made good decisions based on what I knew, but I still desperately wish I could have tested it with several kinds of users.

• I had to define a pattern library while actively designing a large part of a product.

  • This project was especially challenging to complete because I was building UX infrastructure while also designing for a complicated product and also working on other projects and supporting development teams at the same time. It was definitely not an ideal situation and I struggled with not having a pattern library or style guide - even things colors and icons - more thoroughly defined before starting to design. It was extra difficult because I was trying to accommodate some of the existing colors and styles, but also leave room for the brand refresh that was happening at the same time. I ultimately realized that I needed to be strategic about the time I spent on the pattern library because there were many use cases that had not been defined and it was likely to change. I pushed forward with the most basic elements I could define and tweaked them as time went on.