Calvin Bowen

Assistants

Friendly helpers enabling intelligent conversation.

Whereby2025

Assistant inside a Whereby session
Assistant inside a Whereby session
Assistant inside a Whereby session
Dashboard configuration view

Whereby provides the simplest way to do video calls. It's like Zoom, but you just click an invite and it opens the session in your favourite browser. The embeddable product enables companies, specifically in telehealth, to build video calls directly into their own environment or app so it feels like connected of their service rather than a separate tool.

Assistants lets these customers connect their own custom tools into these video calls. They join a session as a silent participant, stay out of the way, and surface value at the moment it's needed.

I led design across the experience: how builders configure an assistant, how they show up in-session, and how teams control and trust them.

MVP Development

In order to establish an MVP, I built an early prototype exploring ideas like presence, control and functionality.

Feedback from both internal stakeholders and a set of customers helped draw a clear line between MVP and non-MVP.

MVP scope

Trust-First Design

A key design decision was to put trust first. Instead of working invisibly in the background, Assistants show up in the room. They have a name, avatar, and clear purpose so participants understand exactly who's present and why.

This emphasis on transparency made the room header important. It became the anchor communicating participation, both human and machine.

Room header

Consent & Transparency

Another key contributor to trust was a consent dialog. AI adoption, specifically in telehealth, can be challenging — and gently reminding clinicians to ensure their visitors are aware and approve the assistant builds confidence for both the telehealth provider and the clinician's workflow.

Consent dialog

Scaling Presence

Trust isn't just about showing assistants. It's about making their presence predictable over time.

I explored what happens when assistants become popular, when customers have several, and when the room header needs to translate more meaning than it used to. I designed a pattern that stays quiet when it can be and explicit when it needs to be.

Scaling presence

Configuration & Setup

Assistants start in the customer's dashboard. This is where builders give an assistant its name, purpose, and avatar — the key components of our trust model.

I intentionally split configuration into three steps: Profile, Connection, Settings. This keeps setup approachable and gives room for scale, as customers get more confident and their needs become clearer.

Configuration

Beta & Iteration

A Closed Beta did exactly what we needed it to do. Our biggest customers built and enabled assistants in real sessions, and a strong feedback loop gave us the signal we were looking for.

Some of that feedback was immediate — it challenged the core experience and we could confidently act on it during the beta cycle. Other themes are still taking shape. Use cases are evolving, and we need more reps before turning early signals into product decisions. Assistants is still in Closed Beta, and we're continuing to refine it with customers as the space becomes clearer.

Dashboard
---
title: Assistants
client: Whereby
year: 2025
role: Lead Designer — configuration, in-session presentation, trust mechanisms
recognition: Closed Beta
---

# Assistants

> Friendly helpers enabling intelligent conversation.

Whereby provides the simplest way to do video calls. It's like Zoom, but you just click an invite and it opens the session in your favourite browser. The embeddable product enables companies, specifically in telehealth, to build video calls directly into their own environment or app so it feels like connected of their service rather than a separate tool.

Assistants lets these customers connect their own custom tools into these video calls. They join a session as a silent participant, stay out of the way, and surface value at the moment it's needed.

I led design across the experience: how builders configure an assistant, how they show up in-session, and how teams control and trust them.

<Chapter title="MVP Development">

In order to establish an MVP, I built an early prototype exploring ideas like presence, control and functionality.

Feedback from both internal stakeholders and a set of customers helped draw a clear line between MVP and non-MVP.

<Figure src="/work/assistants/assistants_scope.webp" alt="MVP scope" />

</Chapter>

<Chapter title="Trust-First Design">

A key design decision was to put trust first. Instead of working invisibly in the background, Assistants show up in the room. They have a name, avatar, and clear purpose so participants understand exactly who's present and why.

This emphasis on transparency made the room header important. It became the anchor communicating participation, both human and machine.

<Figure src="/work/assistants/assistants_header_2x.webp" alt="Room header" />

</Chapter>

<Chapter title="Consent & Transparency">

Another key contributor to trust was a consent dialog. AI adoption, specifically in telehealth, can be challenging — and gently reminding clinicians to ensure their visitors are aware and approve the assistant builds confidence for both the telehealth provider and the clinician's workflow.

<Figure src="/work/assistants/assistants_consent_2x.webp" alt="Consent dialog" />

</Chapter>

<Chapter title="Scaling Presence">

Trust isn't just about showing assistants. It's about making their presence predictable over time.

I explored what happens when assistants become popular, when customers have several, and when the room header needs to translate more meaning than it used to. I designed a pattern that stays quiet when it can be and explicit when it needs to be.

<Figure src="/work/assistants/assistants_scaling_2x.webp" alt="Scaling presence" />

</Chapter>

<Chapter title="Configuration & Setup">

Assistants start in the customer's dashboard. This is where builders give an assistant its name, purpose, and avatar — the key components of our trust model.

I intentionally split configuration into three steps: Profile, Connection, Settings. This keeps setup approachable and gives room for scale, as customers get more confident and their needs become clearer.

<Figure src="/work/assistants/assistants_configure_2x.webp" alt="Configuration" />

</Chapter>

<Chapter title="Beta & Iteration">

A Closed Beta did exactly what we needed it to do. Our biggest customers built and enabled assistants in real sessions, and a strong feedback loop gave us the signal we were looking for.

Some of that feedback was immediate — it challenged the core experience and we could confidently act on it during the beta cycle. Other themes are still taking shape. Use cases are evolving, and we need more reps before turning early signals into product decisions. Assistants is still in Closed Beta, and we're continuing to refine it with customers as the space becomes clearer.

<Figure src="/work/assistants/assistants_dashboard_2x.webp" alt="Dashboard" />

</Chapter>

---

**Next:** [Session Ratings](/work/session-ratings)

[← Back to all work](/)