Deskbird

Retaining enterprise customers with an advanced privacy feature.

Problem

As a Deskbird user, how can I be in control of who follows my profile and can see my bookings & schedule?

Enterprise customers based in Germany want the deskbird app to adhere to their privacy requirements, per local law. The challenge? We had a very tight turn-around to release this and we needed to use the existing architecture of the tool.

Stakeholders

CPO
Product Manager
Front & Back-end Devs
UX Writer
Understanding user needs
Users needed more privacy control

Deskbird had recently released the “Profiles” feature which allowed users to share and view colleague schedules.

Now, this feature needed to satisfy compliance with German regulations. Our Product Manager gathered user needs directly from the requesting enterprise customers. Together with the PM & Dev lead, we broke them down into requirements.

Enable/disable privacy settings

Users should be able to request to follow colleagues with private profiles

Request to follow

Users should be able to view requests and approve/deny them

Review & manage requests

Users should be notified about new follow requests

Empty state for private profiles

Users should know if a colleague’s profile is private

Notifications

Users should be notified about new follow requests

Organizing permissions
Figuring out the technicalities

We had 3 layers of permissions & privacy. This feature required us to introduce one more, which created a lot of complexity. To ensure there would be no conflicts in permissions, we defined how they would interact with each other.

Roles Permissions

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

Office permissions

Permissions on an office level, if there is more than one

Group permissions

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

User Permissions

Privacy permissions on an individual level

Defining Follow Behavior
researching how following should work

I started by researching existing “following” paradigms. We heavily based our functionality on Instagram. That level of privacy control was needed because, for example, a manager may need to see their employees’ schedule, but may not want them to see theirs.

Instagram Follow Request Paradigm

If I accept your request, you can see me but I may not be able to see you.

Facebook Friend Request Paradigm
If I accept your request, we can both see each other.
Mapping Out User Flow

Defining behaviors

With the general idea of how following should work, and with the permission levels well-defined, we mapped it all out and created detailed user flows so we could start getting feedback from our engineering team.

Wireframing

Defining how users interact with UI

With the direction approved by all stakeholders, we wireframed out our UI Design needs for each flow/scenario. Below is an example flow of a user searching for a colleague and requesting to follow them.

To ensure clarity on interactions and UI changes, we highlighted notable elements in red for our engineers.

Hi-Fidelity Design
Putting it all together for hand-off

With the direction approved by all stakeholders, we wireframed out our UI Design needs for each flow/scenario. This served as a crucial communication device between our PM, Engineers, and Design.

Requirement #1
Users should be able to set or unset their profile as private

We added a "Private profile" toggle to enable and disable to the user settings page. It was decided to not emphasize this setting so much, which is why we didn't add it higher.

Requirement #2
User should know when a profile is private

How we display private profiles on the web app.

How we display private profiles on mobile devices.

Requirement #3
User should be able to request to follow a colleague

Clicking on the follow button will change it to a pending state, letting the user know that the follow request was sent.

Clicking on the follow button will change it to a pending state, letting the user know that the follow request was sent.

Tapping on the "Following" button will unfollow the colleagues, letting the user know what will happen if they do so.

Requirement #4
User should be notified of request

User is notified via email about the request. In the email, they have the ability to review the request and accept or delete it.

The user is notified via their mobile device as well.

Requirement #5
User should be able to see and respond to request

User is notified within the colleagues list (at the top) about requests, where they can confirm or delete. 

On mobile, we follow the exact same behavior.

Impact & Next Steps
What I learned & what comes next

Balancing timelines, managing restraints, designing collaboratively can be tricky, but it is entirely doable. Working on this project reinforced the importance of relying on the strengths of my teammates in Product and Engineering – early and often.

Launched on Schedule

We launched the feature on both web and mobile by the promised date.

Positive feedback

The client that requested the feature were very happy with the results and the support provied along the way.

Going the extra mile

We rolled out a nice hand-book for the office admins to understand the feature.

Follow-up Research

Created a research proposal ahead of time to measure adoption, engagement, and how users interacted with privacy settings.

Get in touch

If you’re interested in working together or are interested in learning more about my background, shoot me a message and let’s chat!