Behind the Decisions

Behind the decisions provides context and explains why the design choices mattered. They will appear as you scroll.

Part I - The Product I Inherited

Preserve Momentum, Introduce Clarity

Joining an established product required a different mindset than starting from scratch.

I deliberately resisted the temptation to redesign things. The product already had momentum, recognizable visual patterns, and active users. Starting over would have created unnecessary disruption for both engineering and users.

Instead, I evaluated every part of the experience through three questions:

  • Does this already work?

  • Can it scale as the product evolves?

  • Will changing it meaningfully improve the user experience?

This approach allowed the team to preserve momentum while improving the product incrementally rather than resetting it entirely.

Part II - Decision & Research Framework

How to Evaluate Innovation

Design thinking became a framework for decision-making. AI products evolve quickly. Without a process for evaluating ideas, every request begins to feel equally important.

By introducing regular feature reviews, research touchpoints, and prioritization methods, the team gained a clearer understanding of where to invest effort and when to challenge assumptions.

One of my responsibilities became helping the team recognize when innovation added value and when it introduced complexity.

Part II - Decision & Research Framework

Understanding Users Before Features

People often struggle to explain what they want from AI. They can explain what frustrates them.

Discovery focused less on collecting feature requests and more on understanding behavior.

What slowed users down? What required documentation? What created hesitation? What prevented trust?

Those answers informed nearly every design decision that followed.

Part III - Designing an AI Language

Flexibility Goes a Long Way

Most design systems are built around established behaviors. AI products don't have that luxury.

Interaction patterns continue to evolve. New capabilities emerge every few months. The challenge wasn't documenting components, but

creating a design language flexible enough to evolve without asking users to relearn the product every time it changed.

Part III - Designing an AI Language

Understanding Users Before Features

People don't distrust AI because it's wrong, but because they don't understand it.

Transparency became a design principle. Not an enhancement. Every explanation, badge, citation, and label reduced uncertainty and increased confidence.

Part III - Designing an AI Language

People Remember How Product Fail

Error states aren't exceptions. They're part of the product experience. Sidekick will be the first AI product people work with. Keeping that in mind lead me to ensure our error handling was simple and intuitive.

Ensuring I designed things outside of the happy path and considering edge cases was crucial. Thoughtful design is good design. Good design is measured when things don't go to plan.

Part IV - Feature Focus

Assessing Capability

Not every feature deserves to live in the core product. Some capabilities strengthen existing workflows. Others create entirely new ones.

The challenge was determining where they belonged, how they fit together, and whether users could understand them without training.

Introducing innovation is easy, but integrating it into people's existing behaviors is harder.

Part V - Outcomes

Innovation Earns Attention. Clarity Earns Adoption.

AI products evolve quickly. Design patterns evolve slowly. The challenge isn't building the next feature.

It's building a product capable of evolving without asking users to relearn it every few months.

Guest Pay

Guest Pay

Guest Pay

Making the path to payment obvious.

Making the path to payment obvious.

Making the path to payment obvious.

Project Snapshot

Role

Role

Lead UX Designer

Time Frame

Time Frame

January–March 2025

Scope

Scope

Brand

Product

Design Systems

Impact

Impact

18% increase in

online payments

Overview

A new guest payment experience designed from the ground up to help members pay their medical bills anytime, anywhere, without creating an account or navigating through an insurance portal. This 0 → 1 project introduced a direct, standalone path for locating a bill, entering payment details, and confirming the transaction. As a standalone external platform, Guest Pay was designed across desktop, tablet, and mobile to support a seamless checkout experience on the go.

A new guest payment experience designed from the ground up to help members pay their medical bills anytime, anywhere, without creating an account or navigating through an insurance portal. This 0 → 1 project introduced a direct, standalone path for locating a bill, entering payment details, and confirming the transaction. As a standalone external platform, Guest Pay was designed across desktop, tablet, and mobile to support a seamless checkout experience on the go.

The Problem

Paying a bill shouldn't require an account. Before Guest Pay, members had to navigate their insurance portal, find their bill, and work through a bloated experience just to make a payment. For members without credentials, the path was even harder. They could get lost. They could forget their login. Or they could abandon the payment altogether. The opportunity was straightforward:

Paying a bill shouldn't require an account. Before Guest Pay, members had to navigate their insurance portal, find their bill, and work through a bloated experience just to make a payment. For members without credentials, the path was even harder. They could get lost. They could forget their login. Or they could abandon the payment altogether. The opportunity was straightforward:

Provide members a direct path to what they came to accomplish.

Provide members a direct path to what they came to accomplish.

Members were often frustrated with the process of paying their bills online as they needed to navigate to a homepage, locate the login button, be rerouted to a portal login and remember their healthcare credentials.

"I usually pay my medical bills over the phone because paying online is too much of a hassle."

Starting with Intent

Since members were trying to pay a medical bill and not manage their healthcare, I focused the experience around the user's immediate goal of find the right bill, make a payment, and get confirmation it went through. Rather than recreating the complexity of the existing member portal, I designed Guest Pay as it own experience as a sort of check out flow. (Side panel verbiage should say something like: Users encounter checkout flows all the time in the digital world like checking out after adding items in their shopping cart. Guest Pay would be no different and user would immediately understand the interaction pattern)

Since members were trying to pay a medical bill and not manage their healthcare, I focused the experience around the user's immediate goal of find the right bill, make a payment, and get confirmation it went through. Rather than recreating the complexity of the existing member portal, I designed Guest Pay as it own experience as a sort of check out flow. (Side panel verbiage should say something like: Users encounter checkout flows all the time in the digital world like checking out after adding items in their shopping cart. Guest Pay would be no different and user would immediately understand the interaction pattern)

Find bills

Select payment details

Enter payment info

Verify & pay

Confirm

This simple flow became the foundation for the experience.

Finding the Right Bill

The first challenge was identification. Without requiring a login, users needed a secure way to locate the bill they wanted to pay. We solved this on the landing page by asking for a unique identifier, such as an invoice number, bill account number, or member ID. This was information readily available on their invoice or insurance card.

The first challenge was identification. Without requiring a login, users needed a secure way to locate the bill they wanted to pay. We solved this on the landing page by asking for a unique identifier, such as an invoice number, bill account number, or member ID. This was information readily available on their invoice or insurance card.

The goal was to make this first step feel less like authentication and more like simply entering information they already had at hand.

The goal was to make this first step feel less like authentication and more like simply entering information they already had at hand.

Designing for the Transaction

Once a bill was found, the experience needed to keep users moving. I introduced a stepper to establish where users were in the payment process and structured the forms around the information they actually needed to provide.

Once a bill was found, the experience needed to keep users moving. I introduced a stepper to establish where users were in the payment process and structured the forms around the information they actually needed to provide.

Select account(s)*

Dental Premium

Bill Account Number

005987654321D000

Invoice Number

220916333611(C)

Due Date

06/01/2025

Amount Due

$288.00

Vision Basic

Bill Account Number

005987654321D000

Invoice Number

220916444422(C)

Due Date

06/01/2025

Amount Due

$150.00

Health Standard

Bill Account Number

005456789012D000

Invoice Number

220916555533(C)

Due Date

06/01/2025

Amount Due

$410.00

Users were presented initial payment decisions the as simple, selectable tiles rather than forcing users to parse dense form content.

Users were presented initial payment decisions the as simple, selectable tiles rather than forcing users to parse dense form content.

Payer information and payment information were separated into clear sections, creating a stronger hierarchy and reducing the amount of information users had to process at once.

Payer information and payment information were separated into clear sections, creating a stronger hierarchy and reducing the amount of information users had to process at once.

Side panel content: Purposeful Design: Every screen served a distinct step in the payment process. Whether it was finding a bill, choosing how to pay, entering payment information or verifying and submitting I made the design granular so user could navigate through the flow efficiently and never feel overwhelmed with details.

Side panel content: Purposeful Design: Every screen served a distinct step in the payment process. Whether it was finding a bill, choosing how to pay, entering payment information or verifying and submitting I made the design granular so user could navigate through the flow efficiently and never feel overwhelmed with details.

Making Complexity Invisible

The underlying billing system was complex, but the experience didn't need to be. I worked closely with development throughout the project, using regular design reviews, annotations, and clarification to make sure the final experience stayed aligned with the intended user journey.

The underlying billing system was complex, but the experience didn't need to be. I worked closely with development throughout the project, using regular design reviews, annotations, and clarification to make sure the final experience stayed aligned with the intended user journey.

Rather than exposing the complexity of the system, the interface translated it into a straightforward sequence of decisions.

Rather than exposing the complexity of the system, the interface translated it into a straightforward sequence of decisions.

Citation Tiles

Allowing users to verify generated content and review original sources.

Going Beyond the Happy Path

One of the biggest gaps was a lack of edge case design. The previous designs focused heavily on successful experiences. As a result, developers filled in the blanks when sessions expired, errors occurred, or workflows broke down which sometimes created bad UX. I partnered closely with engineering to define these gaps.

Error Handling

Providing users with clear explanations and actionable next steps for resolving errors was previously unavailable. I redesigned error messaging to ensure guidance was easy to understand and helped users confidently move forward.

Session Expiration

Rather than freezing the interface after inactivity, I created a modal that communicated what happened and provided a clear path back into the experience.

Scalable Components

As the platform expanded, users needed more capabilities. I redesigned components to support added functionality while maintaining clarity, consistency, and scalability, allowing future actions to be introduced without unnecessary complexity or disruption.

Empty States

AI features are not always immediately obvious to users. I created intentional empty states to guide users on what content belongs in an area and how they can interact with the platform. This helped improve feature discoverability for experiences like Prompt Library.

Building With Engineering

Collaboration became one of Sidekick's greatest strengths as I worked across different team and different roles like PMs, engineers, data scientists, governance, and many more. Collaboration took many different shapes.

Weekly Scrums

Agile-based meeting to review ongoing sprints, track progress of work, refine work as needed, and work through roadblocks.

Weekly Scrums

Agile-based meeting to review ongoing sprints, track progress of work, refine work as needed, and work through roadblocks.

Weekly Feature Reviews

Evaluation session of the feature tickets we received that week and determined if they were worth adding to our backlog.

Weekly Feature Reviews

Evaluation session of the feature tickets we received that week and determined if they were worth adding to our backlog.

PI Planning

Align on a shared business vision, outline a delivery roadmap, and identify dependencies. Future work based off of backlog.

PI Planning

Align on a shared business vision, outline a delivery roadmap, and identify dependencies. Future work based off of backlog.

Show-and-Tells

I would walk through initial design discovery, design decisions, and prototyped solutions to PMs, SMEs, POs, and engineers.

Show-and-Tells

I would walk through initial design discovery, design decisions, and prototyped solutions to PMs, SMEs, POs, and engineers.

Office Hours

UI Devs could reach out if they had questions about the design or if iteration was needed to account for technical constraints.

Office Hours

UI Devs could reach out if they had questions about the design or if iteration was needed to account for technical constraints.

Design Audits

Served as an opportunity to review UI developer work prior to being committed to test environments.

Design Audits

Served as an opportunity to review UI developer work prior to being committed to test environments.

Before opening Figma, I often whiteboarded solutions with engineers and PMs to surface constraints early which reduced rework and allowed technical considerations to inform design decisions. This approach made design more a more collaborative effort.

Measuring Good Design

11%

Increase in platform usage

18%

Increase in activated users

53%

Retention reached

8,156

Monthly active users

50+

Components created/refined

Design Heuristics in Action

Heuristic

Example

Visibility of System StatusTemperature badges

Temperature badges

Recognition over Recall

Team Prompt and Workbook Status badges

Error Prevention

Human-centered messaging

Match to Real World

Settings explanations

These heuristics were developed by NN/G (Nielsen Norman Group) and are principles for interaction design.

Final Thoughts

Ultimately, the outcome I'm most proud of isn't a metric. It's that many of the experiences we designed required little explanation, minimal training, and almost no documentation. Users didn't have to memorize workflows. They didn't have to experiment endlessly. They could simply accomplish their work. Because the best AI experiences don't showcase intelligence. They remove unnecessary thinking.