Zero to One
⏱️ 1 month for design proof-of-concept
⏱️ 2.5 months to deliver full design mocks and specs
👩🏻 Me - lead product designer / product manag
👨🏻 Staff backend engineer / architect
👩🏼 Front end engineer
💵 Designed and product-managed a complex permissioning system from zero to one, unblocking 6 contracts and generating ~$200k in revenue.
💥 I led research and drove insights that saved effort and time.
💪 Working only weeks ahead of front end, I delivered scalable designs that were quick to develop.
Whitney was able to closely collaborate with the backend architect on research and design for an important, complicated project without much support.
Intro
What is Syndio and why a permissioning system
Syndio is a series C startup and industry pioneer in global pay consistency. Our customers include leaders in a variety of industries, like American Airlines, Salesforce, and more.
I worked as the lead designer for Pay Finder, which helps recruiters, hiring managers and compensation analysts maintain pay consistency through a data visualization interface.
We had no permissioning system, which was a big blocker to customer growth.
Problem
Partitioning data efficiently
As a leader in pay consistency, Syndio contains a wealth of legally sensitive information: not only how much each employee is getting paid, but why.
Currently, we hid and showed information in a very inefficient way: our systems engineers added individual users to workspaces for each customer implementation.
Without a permissions system, making sure the right users had appropriate access to the right information was too difficult.
These workarounds could take months to implement. Customers would churn before implementation was complete.
constraints
Design for scale and deliver under tight timeline
We planned to rollout permissions to Pay Finder first, then to our three other products. The permissions system would need to work for all of them.
Pay Finder was first because of its pressing need: of the 12 Pay Finder customers, eight were blocked.
Pay Finder also had the largest potential user-base--recruiters and hiring mangers--and therefore the greatest potential for growth.
While the project had been defined by leadership, the scope and implementation was left to our team to define.
We only had 4 months to design and build the first version of our permissioning system, but the team was very small—just myself, a backend architect / engineer and a front end engineer.
research & collaboration
Collaboratively defining requirements for MVP
To begin to define the requirement and scope, I collaborated with our backend architect to understand the fundamentals of permissions systems.
I led Figjam brainstorms and we came up with a first pass at requirements and key flows.
Research
Reviewing research to define use-cases
Simultaneously, I reviewed notes and recorded calls from 12 customers to identify the most important use-cases, which I synthesized and shared with the backend architect.
Two primary use-cases emerged that mapped to two different user types and workflows. These correlated to two different access levels.
I created a visual artifact of this synthesis, which helped leadership and team members to quickly get up to speed and kept us on track during trade-off conversations.
research
Driving a change in strategy through research
I also drove feedback sessions with customer success which revealed a scalability issue.
The system assigned permissions around roles; for example, calling one type of user an “admin”. Then permissions could be assigned to that role one by one; for example, this admin can view employee salaries in Washington.
But this turned out to be too granular. While “employee salary; Washtington” was simple enough, some customers would have over <50,000 data categories. Adding each one-by-one to a role was too time consuming.
This drove a key pivot. Since each company had just two types of use-cases, restrictive and permissive, we realized we could group data together and create a permission framework around it. We called this a permissions policy.
We could also make make applying a permissions policy to users easier as well. Instead of assigning roles, we’d allow users to be grouped together. Then a group could be linked to a permissions policy, thus controlling access.
research
Three key flows for setting permissions
- Create a permissions policy
Group data together and create restrictions around it (i.e., restricting job title searches so that results are limited to only certain job titles.) - Create a user group
Group users around a particular role, (i.e., “recruiters”, “C-level”, “compensation analysts”). - Link these two together
💡 spotlight on design
Balancing simplicity and development speed
The “create permissions policy” was a key flow. Here, users would create a permissions framework that would then be assigned to a group of users, thereby limiting that group’s access.
To “create” a permissions policy was only four steps, but it utilized abstract concepts and terms.
I wanted users to be able to complete this step without much reliance on our customer success team. But again, I had to balance usability against simplicity and development speed.
I explored three different ideas: 1. everything on one form, 2. using a stepper, and 3. progressive disclosure. After discussion, we landed on the first idea:
✅ Everything on one form
❌ New “stepper” component
❌ Progressive disclosure
Design solution was a balance of development efficiency and maintaining a simple user experience
delivery
Sharing with leadership and working with engineers
With MVP designs complete, I created a Figma prototype and demo’d to senior leadership, who commended our efforts and the result.
At this point, the business had more bandwidth to give us more engineers. To aid development speed, I created a small map of the information architecture for each flow with a “you are here” to help engineers orient themselves. I also added Jira links to the designs, and held a design “office hours” with engineers at a weekly cadence to keep things moving.
