Daniel Cho | Designer

work

about

Sponsorship Portal Rebuild

Timeline

February 2023 - January 2024

Stakeholders

Jefferson Senior Vice President

Sponsorship Council within Office of the CEO

Overall Impact

Strategize allocation of Jefferson’s sponsorship funds with an automated portal that saves $2.5M per fiscal year

Overview

In an effort to fund charitable organizations and efforts that benefit the larger Philadelphia community, Jefferson has a Sponsorship Portal in which applicants can apply for funding for various events and programs. However, the current Sponsorship Portal needed to be rebuilt on a more reliable, updated system and also required enhancements that reflect the needs of the expanded Enterprise Sponsorship Committee.

As the Lead Product Designer on this project, I collaborated with developers and product managers to drive the redesign the effort of the current Sponsorship Portal. I also took on the role of leading QA Testing throughout the process.

Some of my musings and reflections will go here!

Evaluating the Current Portal

There were three user types who interact with the Sponsorship Portal: Requestors, Committee Members, and Admins.

Every Admin was also a Committee Member, but not every Committee Member was an Admin. The order of permissions for the portal from least to most went Requestors, Committee Members, and then Admins.

The current Sponsorship Portal was very outdated - not only in terms of aesthetics, but also its functionality. It would crash frequently and be an unreliable tool to track Sponsorship applications.

This was the first page of the Requestor Application. Some improvements I wanted to focus on included improving the usability of forms and including more color throughout the pages.

For the home page of the portal accessed by Committee and Admin members, I was interested to see if the page could include more features to better organize all the submissions.

After talking to our stakeholders and brainstorming on the different flows for the three user types, my high priority areas of focus were:

Update and standardize the branding / UI elements across all pages
Designing features to assist all three user types in their goals of using the Sponsorship Portal
- How could I make the application process easier for Requestors?
- How could I make voting more seamless for Committee Members?
- How could the tracking of multiple applications be more intuitive for Admins?

Wireframes to Mockups

The development team recommended that to facilitate the migration of the portal to a more functional platform, the portal should be split into two sites: the external Requestor site and the internal Admin and Committee site. In considering the design of the different pages, I thought first about the functionality and the features before including colors and other UI design elements.

Requestor Home Page

My goal for requestors was to give them the ability to track their applications. The Post-Event Files allowed them to share marketing assets with Jefferson for their sponsored events.

Jefferson dark blue was the primary color, but I made sure to include other colors as well (red for the accent, green as a status indicator, etc).

Requestor Application

Including a progress tracker, standardizing form fields, and indicating which fields were mandatory were all ways to improve the usability of the application form requestors filled out.

I kept the visual design of the form very minimal so requestors could focus on the information they were entering.

Committee/Admin Home Page

To help stakeholders manage the influx of applications, I designed a table with different properties to make scanning information intuitive.

Some changes from the wireframe to the design included a Search button, pagination at the bottom, and some additional columns.

Refining the Designs

Error Messaging

One valuable lesson I learned while handing off my designs to developers was the importance of considering edge cases; beyond the “happy” path, what were all the possible case scenarios when a user interacts with a page?

With this project, that pertained specifically to error messaging and led me to think about how it could diminish user frustration and instead allow them to accomplish the task at hand.

For the Audience page, it was important that Requestors understood that for each prompt the different percentages had to add up to 100%. I made sure to indicate a notice at the top of the page while also highlighting the fields that needed to be fixed.

Filter Feature

Something I’m personally proud of designing from the ground up was the filtering functionality. With the goal of improving the workflow of both Committee and Admin users, I wanted to make sure that it accounted for all the properties available on the table while being simple and intuitive to use.

If a user is trying to filter for applications with the “Approved” status, I had that display in an interactive pill above the table for the user to see.

In a conversation with stakeholders, I determined what were the most “common” financial ranges for Requested Amounts to determine the different filter options. I also put a Min and a Max value to give the user more freedom to decide their own financial range.

QA Testing

In addition to leading the redesign effort, I was also responsible for the QA Testing process. After a developer would merge requests onto the live sites, the product manager would write out the user stories / test cases, and then I would go and conduct QA on the pages while logging all required changes and edits.

I decided to create comprehensive documents that showed the issues and proposed solutions to ensure clear communication with the developers.

I wanted to make sure that the info of what all the issues were and how to fix them were all captured on a document.

While there were some functionality issues, the majority of the issues I highlighted were around fonts, padding, and colors.

Reflections

Both the Requestor and the Admin/Committee site are live, and helping to facilitate the Sponsorship process by saving $2.5M of leakage per fiscal year. It was both a daunting and fulfilling experience to take lead on designing a project on this scale. Some lessons I learned were around:

Handoff to Development: Sprints within Agile are mostly to gauge technical effort, so I have a better understanding of how to fit my designs to this framework and what kind of supplementary information is necessary with my mockups (edge cases, button states, etc.)
Different user types: To create intuitive experiences that would appeal to all users, I found that it was important that I constantly think about the needs and requirements of the three user categories throughout the entire process.

wanna talk? you can reach me via

let's talk via