Virtual Office Interaction Experience
An exploration into improving UX within Roam
Preface
Roam (ro.am) is an excellent virtual office platform for distributed teams. I haven't worked at Roam, however I was a weekday user for over a year and a half. Roam is designed very well, and the team had been very receptive to the occasional feedback. Originally I only intended to send the Roam team some simple feedback on the below, but I had some extra time and ended up taking it further with the following design study. I hope this gives some insights into my design process and thinking.
Background
When someone knocks on your virtual Roam office, they're requesting to enter your office for an audio call. The knock sound notification is playing, and you want to be responsive and answer their knock as soon as possible.
You may be available, but you also may need a moment before accepting the knock. In my case, I often needed to switch up my audio. Let's break down the timeline for this example scenario:
It doesn't seem like it should take 10-15 seconds, but when you break it down (and time it yourself) it's surprising how each little step adds up. Knowing that someone is waiting on you, this becomes a high-anxiety moment when it really shouldn't need to be.
You may also be thinking this user (me) just needs a better audio setup, or to wear their AirPods or mic-enabled headphones all day, and you're probably right — but we really shouldn't expect ideal circumstances, nor assume the user will behave a certain way.
There are alternatives to delaying answering, but they aren't ideal for either the initiator or recipient:
- Answering before audio is ready: awkward starts to the conversation as the initiator may hear recipient shuffling audio inputs while recipient isn't yet able to hear them
- Declining and then knocking/calling them back: also not an appropriate or smooth option
When receiving a knock (a request for an immediate audio call), you have only the options to accept, decline, or delay accepting until ready — the latter option leading to a high-anxiety moment and giving the impression of you not being responsive or even there.
Reviewing the current state
Unless working on an entirely new flow, I'll first audit the existing flow. Here we have two users: the initiator (Walter) and the recipient (Jesse). The initiator is knocking to start an audio call, and the recipient can either accept or decline.
Extending the response options
The existing response options above work great if you're either immediately available or unavailable. But what if you just need a moment before starting the audio call? Let's explore how to solve for keeping the experience smooth and worry-free for everyone.
A few quick drafts to extend response options:
While not usually the case, here it's simple and straightforward enough to add an action for a new option. I used a mustard color #FFCA28 from the existing Roam UI palette (it felt right for the middleground between accepting and declining), and decided on going with the Option C above where I made simple changes to the layout and styles to dial back the prominence of the secondary actions.
It gets a little more interesting in exploring the new flow for this action (below) and updates to existing flows.
Depending on the team process, expectations and timeline, the above examples and notes may be enough for this flow — certainly enough for sharing the concept for feedback. However, it's also involved enough to warrant a prototype to feel out the transitions for the "One moment" flow and work out any design adjustments before handing off to Engineering.
Updating the "Busy now" response confirmation
With the new UI and UX for the "One moment" response, we should also update for the recipient their "Busy now" response confirmation for consistency and more clarity.
Updates to receiving response from knock
From the perspective of the user who knocked, we need to show the "One moment" response and consider updates to other responses.
Other flows to handle
There are other flows we'd want to cover. When the initiator cancels the knock at any time, the existing flows (not shown here) would suffice, where for the initiator it would close the knock and return them to the office floor, and for the recipient it would open the direct message thread between them and the initiator with a new system message: "<FirstName> knocked on your office door then left before you answered."
When the recipient responds with "One moment" and then they cancel or even exit Roam, we could go the direction of showing a modified unavailable response to the initiator:
Wrapping things up
Comparing the before and after of just this key moment, we can see how allowing a response prior to accepting can improve the UX for users on both sides of the interaction.
Before
After
Revisiting our scenario timeline, we can see how these changes have neglible impact on total time to accept (+1s), while making a big impact on your ability to be responsive (-13s or 7.5x faster from original) in this core flow within Roam.
Reach out and say hello if you want to discuss identifying and tackling UX challenges like this one at your organization.
Have a distributed team and want a great virtual office experience? Be sure to check out Roam.
