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.

Check out full map

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.

View all wireframes
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.

Reflecting on the impact

We released the feature with time to spare, and by all accounts, it was considered a success. Here’s what we achieved:

We released on time
With good and frequent communication through the process, we released on time.
~80% of components used were already existing
We kept the # of new components that needed to be implemented low to speed development.
100% Customer Satisfaction
We received positive feedback on the outcome and were able to help customers remain compliant with local regulation.

We attributed the successful launch of this feature to:

  • Close collaboration between all stakeholders, particularly Development, Product, and Design helped us ensure everyone was aligned on the timing and solution.
  • Early planning and technical discussions which helped to uncover potential blockers before even starting the design phase.
  • Speaking directly with our German enterprise customers (done by the PM and CPO) gave us direct insights into what it was we needed to solve.
  • Using existing architecture and as many existing components helped to cut down development time in order to release on time.

Next steps

While the immediate release was a success, we needed to measure the long-term impact of the changes we implemented. Deskbird is a tool meant to promote engagement and transparency within a company, so we were keen to understand the implications of introducing a feature that did the opposite. Here’s what we wanted to understand:

How do private profiles impact overall engagement?
# of set schedules and active users/month before & after launch to understand if private profiles negatively impacted engagement.
What is the # of active users engaging with private profiles?
% of public vs. private profiles over time helps us determine whether users are actively engaging with the privacy feature.
What is the rate of acceptance for follow requests?
% of follow requests that get confirmed vs. deleted/ignored in order to get a sense of user behavior towards colleagues viewing their schedule.
Where do users intuitively go to accept a request?
% of requests are accepted on requester profile vs. colleague’s view to see which is the more intuitive location for responding to requests.
Are users clicking the email notifications or push notifications?
% of push/email notifications that are clicked, to get a sense of whether users are ignoring or responding to requests.
Samdock Case Study

If you aren't a big fan of contact forms like me, you can reach me at hello@ginabrigette.com.

Gina Brigette © Copyright 2025

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!