Deskbird

Deskbird is a workspace management software that helps companies manage hybrid work environments by making it easy to book desks and meeting rooms.

My Role

I was the primary designer on this project, and led the design process end-to-end from user flows to hi-fidelity designs.

Stakeholders

CPO
Product Manager
Tech Lead
Web Developers
Mobile Developers
UX Writer

The Problem

Upholding privacy regulations

We had recently released a new feature called Colleague Profiles. However, in Germany for Enterprise customers, certain employee info found on those profiles is considered sensitive.

In order to allow those Enterprise customers to remain compliant with local regulations, we needed to introduce the ability for employees to control who can view their profile and schedule.

The Challenge

Time & technical restraints

We needed to release this on a very tight turn-around.
We needed to work with what we had in the existing product (i.e. working around lack of a notifications center)
We needed to untangle our different privacy layers and ensure it’s clear

Defining plan of attack

Our CPO and Product Manager spoke directly with German enterprise customers to get a better picture of why they needed this, and how it should work.

How might we make it so employees are able to define whether their information is public or private within deskbird in order to remain compliant with local regulations.

Let users control their privacy settings

Users should have an easy way of making their profile private

Let users control their privacy settings

Users should be immediately able to tell if someone’s profile is private

Request permission to view a user’s private profile

If a user wants to see a private profile’s schedule, they need to request permission

Inform user about permission request

Notify users that someone wants permission to view their schedule/profile

Let user respond to & manage permission requests

Give users the ability to accept or deny permission requests, and remove access

Understanding our current architecture

Our first step was to understand how this new privacy level would work on our existing architecture. We had 3 layers of privacy that played different roles and hid/showed different pieces.

Roles Permissions

Permissions by user role (i.e. global vs. office admin)

Office permissions

Permissions on an office level, if the company has more than one

Group permissions

Permissions on a user group-level, if the company defines groups

User permissions

Privacy permissions on an individual level

We synced up a few times to make sure we figured how each privacy/visibility level interacted with the other. Ultimately, we drew out this flow that helped us understand the implications of introducing a new privacy layer.

Making the follow experience intuitive

We wanted this feature to feel intuitive, and one way of ensuring this was research. I decided to look at existing following paradigms in social applications and gather inspiration from there.

I looked primarily at 2 very well-known applications and tested out different flows (i.e. following, removing a follow, rejecting a request, etc.):

Facebook

If I accept your follow request, we can see each other’s profiles

Why this didn’t work: In the case of managers, for example, they may want to see their employee’s schedule, but may not want the employees to see theirs.

Instagram

If I accept your follow request, you can see my profile but I cannot immediately see your profile

Why this works: It gives more granular control over privacy. Following someone doesn’t mean that the person you follow can view your information.

So we heavily based our functionality on Instagram’s following paradigm.

Defining user interactions

With all the information collected, I felt we had enough to start defining the user flows. This step was crucial so I could communicate the interactions with all teams (UX, Product, and Development). This helped showcase what the user journey would look like going through this feature, and to help catch edge-cases.

Here's what we wanted to communicate with this:

Interactions

Where do users have the ability to interact & view someone’s profile?

Where to receive & respond to requests

How would users receive & respond to follow requests given that we didn’t have a centralized notifications hub?

Visibility & permissions

What can users see depending on their role in the company?

Wireframing

For this project, I decided to incorporate the wireframes directly into the user flows. There were 3 main reasons for this.

Getting feedback

Doing this allowed developers to give feedback easily, and already start preparing the back-end for implementation, and not losing any time given the tight deadline.

Clarity

Since this feature was mostly designing smaller pieces like empty states, toast messages, etc., I wanted to ensure the interactions were crystal clear.

Source of truth

While we had a call to go over this map together, I wanted the map to be the ultimate source of truth regarding interactions. This meant being accessible and understandable even if I or the PM was not there to explain it.

The solutions

Now it was time for hi-fidelity. Here is where our design system came in handy. There were already a lot of pre-existing components that were used, which saved us time.

Let users control their privacy settings

We added a privacy option to the Profile Settings page that allows users to easily enable/disable. We had it placed in the bottom because

Show users that a profile is private

Users with a private profile that you aren’t following yet will display an empty state.

Request to follow a user’s private profile

The star (pun intended) of the show is the follow button, which was designed to communicate the different possible states regarding a request.

Inform user that they received a follow request

With the lack of a notifications center, we approached this holistically, thinking of what users expected and what would be realistic to implement.

Where would users expect to be notified?

In an ideal world, there’d be a centralized place for notifications. We couldn’t develop this without the time to think about the future implications. So the conclusion was to use email and push notifications (for those users that had the mobile app).

Where would users expect to be able to respond to requests?

Without a centralized notifications center, if requests come from colleagues, then the most logical place would be in the Colleagues pages.

How much are we able to modify the interface?

The most we could realistically do in the allotted time was to modify existing components, but not the higher-level architecture of a page.

Let user respond to a follow request

Building upon the conclusions from the previous requirement, we added the ability for users to respond to requests in 2 places – the colleagues page, and the requester’s profile.