deskbird
The One Where We Introduced Privacy Settings
Introduction
In Germany, certain employee data is considered sensitive. To facilitate compliance with local law, we needed to introduce the ability for users to control who can view their deskbird profile and schedule.
Goal
How might we allows individual users to set their own profile privacy within deskbird so employers can remain compliant with local law?
Company
deskbird is a workplace management app for hybrid companies. Employees can see who is in the office, schedule office or work-from-home days, and book desks.
Role
End-to-End Product Design
Team
Chief Product Officer
Head of Product
Desktop & Mobile Engineers
Head of Product
Desktop & Mobile Engineers
Before introducing privacy settings, we had to understand current permission & privacy layers.
At that point, we had 3 layers of permissions & privacy. This feature would require us to introduce one more.
User roles permissions
i.e. Global Admin, Office Managers, Group Managers
Office permissions
i.e. Acme Inc. has 2 offices, but may not want employees to see information outside of their own office
Group permissions
i.e. People in the Marketing group cannot see employees in the Product group
individual user visibility (NEW)
i.e. I do not want my profile & schedule to be visible to everyone. People need to first request a follow so I can approve it.
Untangling the permissions wasn’t easy.
Because of how complex this was, mapping it out was an iterative process. We started with a rudimentary chart. This is what the first version looked like:
Then the map evolved into this.
This was the second iteration, but it had a lot of the small details not found in the first version. The intention was to catch edge-cases and any weird interactions between permission levels.
Now it was time to look into the visibility & following behavior.
I started by thinking about existing “following” paradigms. We heavily based our functionality on Instagram’s following feature.
This level of granularity was needed. For example, if I am a manager, I may need to see my employees’ schedule, but may not want them to see mine.
We had the user flows mapped out, but now I had to start thinking about the UI.
This is the final form of the MegaMap. I wireframed out what our visual design needs actually were for each flow/scenario. This served as a crucial communication device for any conversations I had with our developers.
If you’re interested in viewing the full thing, you can find it here.
This is a close-up of what happens when a follow request is sent to a user.
Take a look at the next step to see how this translated into the Hi-Fidelity designs.
Let’s say that Cristina Paterson decided to send me a follow request.
Where would I see the request?
This was an important question because we didn’t have a dedicated requests or notifications center. Nor did we have time to develop one.
It appears inside my colleague’s list.
Requests will always appear on the top of the list to make sure I don’t miss it.
I will see it on Cristina’s profile.
In the example below, I am visiting Cristina’s profile (who I don’t follow yet). Her request appears at the top of the page, similar to Instagram.
I will get an email and push notification of the request.
We wanted to be transparent about what happens when you both accept or delete a request.
Okay, but what does Cristina see on her end?
How can cristina track the status of her request?
Similar to Instagram, the “Follow” button will let the user know the status of their request. If it’s declined (or deleted), they are not notified.
Initial state
The button will say “Follow” with an outline star icon, denoting that they are not following yet.
Request Sent
The button says “Requested,” with an hourglass icon. There is a success toast message as well.
Request Accepted
The button says “Following” and the star icon is filled, unlike the initial outline state. The button style itself was changed to something less inviting to not inadvertently call for too much attention.
What about Mobile?
It works the same as in the web app!
How did you measure success?
Because we hadn’t set up analytics tools yet to give us hard data, we were reliant on our customer feedback loop. This feature request came from specific clientele, so we used them as a sounding board to make sure we were on the right track with this feature.
But in general, here’s how I would measure success in this project:
Discovery
Are users able to find/send follow requests with ease?
Engagement
How does this feature affect engagement/usage of deskbird?
Conversion
Does release of this feature impact support volume?
Want to see more?
Check out how we updated the sign-up and onboarding process at Samdock