Redesigning screen share so the call never disappears
I led UX on a feature that closed a genuinely risky gap in Attend Anywhere's video consultation platform. The moment a provider shared their screen, the patient could disappear from view entirely. This is how I dug into it, checked what everyone else was doing, and got a fix shipped across four releases without breaking anything else along the way.
The problem
Screen sharing itself wasn't the issue. What broke down was what happened after it: the shared content, or the workflow around it, could remove the call from view entirely. This happened when:
An application when into a true full screen mode,
A PowerPoint slideshow was being presented,
A provider navigated away from the video call, like a patient record, clinical notes, a scheduling tool.
In those moments the video of the patient was hidden from view. The provider lost real time awareness of the patient, with no way to see a raised hand, an incoming chat message, someone waiting to join, or a participant dropping off. On a single monitor, which most clinical settings run on, there was no workaround beyond manually splitting the screen. This wasn't a small usability gap. It introduced real clinical, communication, and safety risk during a live consultation.
Understanding the landscape
Before proposing a fix, I needed to know how the problem actually showed up in practice, and how other platforms handled it. I audited Attend Anywhere's own screen share behaviour, then benchmarked it against Whereby and Microsoft Teams, testing both the app and browser versions of Teams separately, across every sharing scenario: a window, an entire screen, a PowerPoint in slideshow mode, a fullscreen video.
A few things stood out. Sharing a normal window or tab on Attend Anywhere kept the video thumbnail track visible, that part worked fine. But the moment a PowerPoint went into slideshow mode, the provider lost everything: no visibility of people waiting, no chat, no raised hands, no participants at all. Teams had the identical failure in both its app and browser, under the same slideshow condition. Whereby, on the other hand, had already solved it with a floating picture-in-picture window that stayed visible above whatever was being shared, and could be moved or closed without interrupting the call.
That gave me a validated direction rather than a guess. Picture-in-picture wasn't something I was proposing from a blank page, it was a pattern already proven to work, and I could adapt it with a clear picture of exactly where it would help.
What PIP solves, and what it doesn't
I didn't want to assume picture in picture would fix everything just because it fixed the obvious case, so I tested it against both call types the platform actually supports. In a Regular Consultation, a straightforward one to one between a provider and a patient, it works cleanly. The clinician can present and still see the patient the whole time, and the patient can see their provider hasn't gone anywhere.
In a Group Consultation, one provider managing several people on a call at once, is a different story. PIP helps, it brings back awareness of who's speaking and lets a raised hand or a new message surface again, but it's never going to replace proper group moderation. You can't scroll a full participant list inside a tiny floating window.
A constraint that shaped the design
Picture in picture isn't something an app controls. It's the browser and the operating system that decide what's possible, and they don't agree with each other. Chrome and Edge are genuinely flexible, custom controls, multiple video layouts inside the window, real product design patterns. Safari is a different world entirely, locked down, OS controlled, fine for watching a video passively but not built for anything interactive.
Deciding what shows in a four tile window: provider versus patient
With only two to four tiles of space to work with, I had to consider the logic for what actually earns a place on screen, and it couldn't be the same logic for everyone. A provider managing a consultation needs something very different from what a patient needs to see, so this ended up being two separate pieces of work rather than one, delivered at different points in the plan.
The provider version came first, and it's the more complex of the two, since a provider might be managing several other providers, a screen share, and multiple patients at once. I split it into two layers.
Layer one covers hard signals, the things that matter most clinically: someone pinned by the provider, a raised hand, an active screen share, whoever's currently speaking.
Layer two only kicks in once layer one is settled, and covers softer signals, whether a caller has their camera on, and where any extra providers should sit.
The patient version came later, as its own iteration, once the provider logic had already been proven. A patient isn't managing a call, they're just trying to see their provider, so the priority order is much simpler and anchors on the primary provider staying in view, even if that provider's camera is off. It doesn't reshuffle for the same reasons a provider's view would, a patient doesn't need to see a screen share pop into priority the way a provider does.
Video tiles should not jump to a different person every second in either version. Once a tile has been assigned, it stays there for at least three or four seconds, and only changes when a new signal shows up, so the window isn't flickering every time someone glances at their webcam. I went through the messier edge cases for both too.
What happens if two patients are on the call and one turns their camera off.
What happens if the lead provider drops out and rejoins, they get their original spot back.
How the layout copes on mobile where there's only room for two tiles instead of four.
Each of those got an actual rule, not left as a grey area for someone else to guess at later.
A phased rollout, planned with Engineering and QA from day one
Attend Anywhere runs across a huge range of NHS trusts, devices, browsers, and operating systems, and it has to work for providers and patients alike. This was never going to ship in one go. I broke it into four deliveries, each one deliberately narrow so the team can learn something before widening scope on the next.
Initial delivery is provider only, desktop only. Just the core mechanic, video tiles inside PIP, screen share triggering it automatically, nothing else yet. Scoped across both Regular and Group Consultations from the start, so the tile logic gets tested against the harder case straight away rather than being retrofitted later.
Delivery two brings in call management. Chat and people notifications will show up inside the PIP window itself, so a provider deep in a shared screen can still see a caller waiting or a new message land without switching away. This one is scoped for Windows and Android only, a MacOS and iOS limitation flagged upfront.
Delivery three is mobile, and it's where things get genuinely harder. Mobile PIP answers to the operating system, not the browser, which drags in app backgrounding, the device locking, orientation changes, touch behaviour, none of which desktop has to deal with. Maximum PIP tiles are cut down to two on mobile just to keep it usable at that size.
Delivery four extends the feature to the patient. Everything up to this point has been built for providers. Patients need different priorities entirely, they care about seeing their provider, not managing a queue, so there are no people notifications for them at all, no reason for a patient to know who else is waiting.
Where this stands
The design and the phased delivery plan have been validated with stakeholders and customers, direction and approach are signed off. Implementation is still ahead. What's here is the full research trail, the competitor validation, the priority logic, and the release plan that will guide the build once it's picked up by engineering.