Episode #31: Casey Bell on Listening-Led UX Design

Casey Bell's path into UX began while she was working as a technology specialist and small-business IT administrator at a nonprofit. After her organization moved its physical phone server to RingCentral, she contacted the company's UX leader with observations from the customer side. Casey assembled a presentation covering user pain points and ways the experience could communicate more clearly. That initiative led to conversations with the design team and an offer for a global role.

In this episode, Casey and Dwayne Samuels discuss why UX design is a bridge for ordinary users, how research disrupts a designer's assumptions, and why collaboration can be both the most difficult and rewarding part of the job.

What you'll learn

• How firsthand customer pain can become credible design evidence

• Why product managers should frame the problem and data before a feature begins

• How moderated and unmoderated tests serve different research needs

• Why visual preference is not the same as successful task completion

• How quiet observation can give a designer a stronger contribution in group decisions

Turn operational experience into design insight

Working in IT taught Casey that different groups interpret the same technology in very different ways. Supporting people with varied problems required both technical solutions and communication. She carries that humility into UX, where the designer has to connect people, technical constraints, and creative expression.

At RingCentral, Casey's role included end-to-end design, competitive exploration, and direct conversations with customers about pain points. She also helped onboard new-hire classes and participated in a research ambassador initiative that featured instruction on research methods. The combination is important: design execution improves when designers keep learning how to observe and ask questions.

Her entry into RingCentral also shows how to make feedback useful. She did not merely tell the company that the migrated phone experience was frustrating. She organized the pain points, connected them to communication opportunities, and presented the material to people who could evaluate it. A customer's situated knowledge became a structured design contribution.

Collaborate around evidence and constraints

Casey describes product managers as initiating a feature by explaining why a problem exists, or why they believe it exists, and using data to support that view. Design then works with product to find an answer that fits frontend and backend limitations while addressing the available evidence. The designer may need to push back when the proposed direction disconnects from the user.

Prioritization also happens across disciplines. Teams compare the effort required with the customer need. Inputs can come from an online customer forum, technical support contacts, and proposals for new features. UX and product managers work together to estimate the value an idea could provide to the organization.

Research helps the team test those assumptions. Casey's group used a user-testing platform and also sourced participants through a third party, including people who used RingCentral's platform or comparable unified communication tools. Moderated studies offered more depth, while unmoderated studies could move faster. The right format depended on how quickly the team needed an answer, how thorough the evidence had to be, and the current measure of success.

Measure whether people can succeed

User tests continually exposed blind spots. A control that seemed obvious to the design team could send participants searching in unexpected places. Casey does not frame that as a failure by the user. If people cannot understand the interface, the design has failed to communicate clearly.

That distinction also applies to visual preference. Users may like colors or describe a design as attractive, yet still be unable to complete their goal. Another version may receive less enthusiastic aesthetic feedback while helping people finish and remember the task. The appropriate choice depends on what success means in that situation, not on whether the design wins a popularity contest.

Cross-functional work makes these decisions harder. Software constraints, legal requirements, user preferences, and promised delivery dates can all pull in different directions. An engineer, product manager, leader, and designer may each be measured differently. Casey sees her responsibility as slowing the process enough to preserve clarity and empathy while helping stakeholders reach an outcome that addresses the larger set of needs.

Her leadership style is grounded in listening. Casey once criticized herself for not being the loudest or most assertive person in the room. She now sees value in sitting back, observing, and understanding the surrounding community. When she speaks, she can represent needs she has taken time to notice. Softness is not an absence of influence in her account. It is a way to make that influence more informed.

Listen to Episode #31 for Casey's full discussion of research, collaboration, and empathetic UX design.