Kincentric Org Manager
My team and I worked on this product from inception to its latest release. Hundreds of our clients are now using it — and it's completely transformed how they manage their employee data.
Role – Lead Product Designer
UX Team – 3 UX Designers
Hierachies = non-stop headaches
Client hierarchies fed into all aspects of our platform. Our data scientists were managing these manually in Excel. Any change took days or weeks to make.
We needed to make this easier and faster — a new, custom SaaS tool. One that could make changes instantaneously, calculate all the necessary counts and feed this to our other applications.
The product acceleration workshop
I helped conduct a 3 day product acceleration workshop to get Org Manager off the ground.
Day 1: Problems, solutions
We spent day defining photo-personas, their problems encountered with client org management and solutions to these problems.
Day 2: Narrowing the scope
Day 2 was devoted to narrowing the scope of features to an doable MVP test, then putting together sketched prototypes.
Day 3: Testing, then iterate
Finally, we ran user tests to validate the features, information, etc and iterated to a final rough wireframe of the MVP.
Workshop results: answers and more questions
The workshop helped answer a lot of questions, but brought up many more.
A: Focus on managerial hierarchies
This was the most common hierarchy the our clients used (and misused), according to our data scientists. We focused on the this type of hierarchy first.
A: the mvp Features, info
For the most part. Moving employees, deleting, total employee counts, direct report counts, etc mattered most. Total level employee counts, changing attribute values, etc not so much for the MVP.
A: Visualizing the levels
We tried a number of different combinations to visualize the levels in all states (open, closed, no children, unparented, etc), and hit on a good UI that represented all of these well.
Q: How to move employees around?
We didn't realize how many usecases there were for moving employees - at least a dozen. Getting these usecases correct was paramount.
Q: How to get better usability?
Over and over the users liked the features but found many tasks hard to accomplish. We needed to solve this.
Usability, requirements testing
We conducted 4 rounds of testing, evaluating everything from language used to information needed to user tasks. By round 4 we were confident that the design solved the core problems.
Click to view prototype
user: client1
pass: pass1
Click to view testing script
Mapping the move usecases
The ease of moving hierarchy nodes and covering all the usecases was of upmost importance. The data scientists, business team and I spent 3 days mapping out dozens of move scenarios and how to deal with them in the UI.
Click to view move usecases
The launch
We launched the MVP with a user login, a table with all uploaded hierarchies and the application.
Creating hierarchies from an employee file
An employee file is a company database that kepts all employee information: ID, email, title, pay, location, etc. Management of it was vital to our applications.
We needed a way to not just visualize hierarchies, but create them from an employee file. And also manage and change the employee information in bulk.
Dealing with multiple hierarchies
Because hierarchies are created from a single source, how would we deal with conflicts when one hiearchy changes. Would the others change too? Would the source change as well?
My team and I mapped out 3 solutions and worked with product management and the data scientists on deciding which approach was best.
Click to view coupling options
Click to view testing script
Click to view testing script
Mapping out the upload process
The uploaded employee file had to be error free and able to generate hierarchies. The data scientists did all this using macros and R. I mapped the upload process below and converted this into interfaces.
Click to view process map
Click to view the wireframes
The launch
V2.0 could create/manage a new category hierarchies, process and manage employee files, calculate relevant column counts, and make bulk or individual edits an employee information.
Integrating the hierarchies
The final step was to pipe over the hierarchy data when and where it was needed in all our other applications. This included survey branching, reporting analytics, survey distribution, reporting setups, survey administration and more.
How to deal with multiple users?
One major issue was when users made changes to the same employee file at the same time. My team and I mapped out varous async processes for this and user notifications. We user tested multiple times until we arrived to following below.
Click to view async process and designs
Integrating into Survey Builder
The main application of integration was Survey Builder, which had a number of features like question branching and survey distribution that required a hierarchy. My team and I went over 10+ rounds of designs and user testing.
Click to view integration designs
Creating, integrating reporting users
Reporting survey results to the proper employees was a key piece of our entire platform. We needed to be able to create reporting users in Org Manager / hierarchies. And then integrate this into our Reporting and Analytics applications.
Click to view reporting wireframes and designs
Click to view reporting wireframes and designs
More revenue, less time wasted
Kincentric has signed over $15 million dollars worth of new business since our new application suite has launched, with Org Manager being at the center of it. Org Manager has also allowed clients to manager their own hierarchies and cut down on lead time for survey reporting by 90% in some cases.
Org Manager has been a huge success and the linchpin of our new platform.