Sunlight Financial is a fintech company that provides loans to homeowners buying rooftop solar panels.

A profile is created for every borrower in the Sunlight Operations hub, a customer relationship management (CRM) tool powered by Salesforce.

This case study focuses on a cross-departmental effort I led to overhaul the CRM.

Identifying problemsCongestion, clicks and clutter

Before prioritizing the project, our product manager and I spent weeks meeting with Ops and Support coworkers. We learned their workflows, observed how they used the CRM and asked how they would improve it.

There were four pain points that repeatedly surfaced in these sessions.

Collective hours spent waiting

Loading each page took around 15 (!) seconds and popular actions were similarly sluggish.

Mess that needs cleaning

The UI was littered with hundreds of fields that were either obsolete, duplicates or misplaced.

Constant clicking

Actions which should only need a single click required many more, clogging up workflows.

Where's that thing I need?

Nothing was logically or intuitively placed, leading to confusion for both veterans and new hires.

Meet the teamGetting the gang together

We rounded up dozens of talented teammates across disciplines and departments to help us overhaul the CRM. A handful of them are highlighted here with their contributions detailed.


Lead designer


Design supervisor


Junior designer


Lead engineer


Product manager


Operations liaison


Support liaison


Compliance officer

Conducting researchInterviewing primary sources

When researching a project I usually have to consider hundreds of thousands of users. But this time it was just hundreds. And best of all, I could speak with any of them to gain their perspective.

I was able to glimpse competitor CRMs and received analysis from our Business Development team, but the user interviews were by far the most useful research I conducted. Below are important insights they shared.

We don't want scaling to add stress

The design solution needed to consider scaling so we wouldn't have to overhaul it again a year later.

We don't want to use workarounds

Users were tired of load times forcing them to employ unorthodox strategies like staggering workflows.

We want to speed up processes

Onboarding took forever. Reviewing records took forever. Helping customers took forever. And it goes on.

We want clarity and order

Content was dumped onto pages without putting thought into what went where. This would change that.

Kicking off with wireframesTearing down and re-assembling

For context, this was the old UI and an accompanying wireframe.

Old UI

Original interface

Wireframe illustration

Wireframe of the original interface

Wireframes were necessary as we essentially built new pages and flows from scratch. There were around 25 pages that could appear depending on the borrower, but thankfully only five overall templates to wireframe.

Below is an example of the most-used template. My first wireframe draft attempted to improve on the old version's unorganized navigation, tedious editing flow, poor use of space and scroll-heavy layout.

Old wireframe

Wireframe for the shop's hero

First draft

Wireframe for the shop's product gallery

The new version was better, but feedback and repeated iteration is what made this wireframe ā€“ and all the other templates ā€“ great over time.

Walking through user flows also changed our opinions on design strategies.

Some of the changes that came from these sessions can be seen in the final wireframe below: organizing field groups into smaller sections, adding Box actions, centering the pipeline and displaying the feed inline.

Final wireframe

I want to call out how helpful it was to bounce ideas off the other members of our design team in our meetings. Whenever I was stuck in the process we would problem-solve in Figma together and things would finally click.

ComponentsOut of the box vs. custom elements

Once the wireframes and flows were established, I had to consider how to build them. Some competitors just used out of the box elements and styling, but we wanted our platform to feel on-brand and customized.

Customized, however, sometimes mean longer load times. And it definitely leads to longer development times.

Weighing this, the design team and I met with our engineers to discuss what was feasible. In the end we went with a hybrid approach.

To build the mockups I pulled up our design system and Salesforce's Lightning design system, then aimed to cohesively blend them together to bring the wireframes to life.

Examples for some of the pages' designs are below.

SummaryThe hub for quick-reference info

The customer's most essential information was housed here.

CommunicationsLogging every correspondence

Any time an operations rep spoke with a customer, they logged it here.

InteractionsDigging into correspondence details

Customer calls and emails oftentimes led to internal team conversations. Clicking into a support case pulled up the rep's full write-up, their tags and any further comments, empowering the team to knock out cases together.

Stipulation reviewLeveraging AI to eliminate manual cross-referencing and ease burdens

Previously, our reps looked back and forth between two monitors to check for discrepancies between documents. Now, thanks to optical character recognition (OCR), docs were automatically scanned for them and they could painlessly and efficiently resolve stipulations with toggles.

Production-ready prototypingLessons from user tests

Since we were introducing new components and flows to the UI, our team agreed that I should take a high-fidelity route for user testing.

Coding a realistic prototype isn't just a boon to testing, it also leads to smooth dev handoffs as our engineers see how the page should look and how interactions feel. Plus, a lot of its CSS usually makes it to production.

As users gave the prototype a spin, they shared their feedback with us.

Minimize the transitions

With speed and efficiency so prioritized, users bumped against even the shortest of transitions.

Optimize for 1920px+ monitors

Seeing the UI on massive monitors changed how I viewed the layout and some of its max widths.

More rich text capabilities

The prototype just had a plain text box for the feed, and users mentioned wanting to bold text, tag others, etc.

Unlearning bad habits

Some users told us their bad habits from the current UI were impacting how they interacted with the new one.

Visualforce & ApexDeveloping our hybrid interface

For development I went into our office to work alongside our engineers, as was the norm for the bigger projects I designed.

As the engineers built the structure and back-end I worked on the stylesheet. There was a bit of a learning curve for us with Apex and Visualforce but no major roadblocks.

Our resultsTakeaways

We rolled out the redesign to beta testers so they could stress test it with real scenarios. Overall, it was a very positive reception. After smoothing out the final wrinkles we rolled it out companywide over the next three months.

40% reduced load times

The initial loading and interactions were streamlined, improving efficiency and relieving headaches.

Removed 250+ fields

We worked with the Ops and Support teams to identify and remove 38% of all fields for a cleaner UI.

100% adoption rate

We offered the option to keep the old layout, but within three months every user adopted the new version.

Quicker flows, fewer clicks

Flows such as feed commenting, editing fields and clearing stips now required fewer clicks.

Centralized infrastructure

Every element, from fields to sections, are thoughtfully arranged with the user's workflows in mind.

Easier onboarding

The onboarding process became smoother and quicker as new hires easily picked up the CRM.