Overhaul of Pure1 Views
The Controversy of Pure1 Views
In Pure1, we allow organizations to onboard multiple users, even in large number. Those users can have different level of access and focus on various information.
While permission level can be controlled by roles, information access is permitted by views. Based on the idea that administrator can grant access to a subset of arrays belong to the entire organization to a user.
In that sense, we can perceive views as a set of filters help narrowing down the array selection. so:
View = n * filter (n ≥1)
How does it scale? Facing large volume of users, organizations may want to assign the same view to a group of users. In order to support the reuse of views, we let admin name their views and apply to individual users in user profile.
How does our customers like the current view?
Turns out it fails to meet our expectation. According to data source from Chart.io, since its initial introduction by mid 2019, the total usage of views is constantly dropping.
There are a total of over 300 views used, among them 174 are assigned, 169 are unused. (Created but abandoned)
There are only 94 views has assignee and has filter.
Among 3000 overall Pure1 users, views are only assigned to 551 users within 83 client organizations. The biggest view got 66 assignees.
Statistics show one view is assigned to 2.95 users on average, which means most views are probably assigned to one user. Whereas only 10% of users uses “simple filter” feature, which is especially designed to allow 1 filter assignment, without needing to name it.
Hurdles in Using Views
We start to asking ourselves, why the adoption rate is so low? Based on the current view statistics, we believe the primary reason was because of the cumbersome process involved. I performed some heuristics analysis on the existing feature, and noticed a couple of potential hurdles that may hold people back from engaging more with views:
- Plan ahead is required: There is a dedicated “View” pane detached from “Users” pane, admins need to know clearly how they want to set filters in view as well as assign them to users ahead of time.
- Extra Naming effort: To create a view, admins need to name it manually. Not to mention this is some mental and motor effort people try to avoid, turns out even if they do, admins generally name views in a random manner, which turns each clearly defined filter into a random name, like “Disney”, “DB IS”, “CORP”, “CHINA” which may prevent them from using further. Datasheet
- Unintuitive Assignment: “Simple filter” turns out to be an “Easter egg” feature available to admins only, but it is so hidden that even many Pure employees didn’t discover.
- Difficult Selection: Current selection of views under user setting doesn’t show detailed filter configuration.
- Inflexible Update: If updates were to be made to a single user’s view, admin need to create a new view in “views” pane and come back to finish assignment. There is no means to update any views on the fly.
The take away after heuristic analysis is
- Access Control: The ability to assign a view should be available upon configuring user access control.
In the new design, selection of views is presented as a dynamic dropdown.
- Auto Naming features: As many users create never used views, or non-filter views, looks like they struggle with giving a meaningful name to them. Why don’t we ease up their mind by directly name the view for them based on the filter assigned? So they can save the trouble of naming views manually.
The “view name” must associate with the filter detail, to convey a clear inclusion of the view. Given most views only contain 1 single filter, it is totally feasible and intuitive to make such auto named view match with the presentation of original filters. So it is clear to tell detailed composition of a view.
Resizable Input: Considering cases of multiple filters set under one view, the input field need to be fluid and adjust its size according to the number of filter entries.
Users will be able to delete any view on mouse over or create a new view with other filters as well.
- Advanced features like Save and Update of an existing view are not only available to the Views page, but also accessible on the spot at user access control component.
Original View page remain the same, allowing for manipulations like edit, delete and add on the panel.
Conducted user testing with our prototype and presented following tasks for user to complete. Including how to create view, assign views to multiple user etc. They were having absolutely 0 friction in getting the done.
Interesting finding: Newly added [+ Create View] button on dropdown get to used more than
Results after Improvements
After 4 months of launch(Jul -October), the “total views with assignment” increased from 174 to 298, increased by 70%, similarly total unassigned view (for discovery/testing purpose), has nearly doubled by increasing from 169 to 329. Same does the number of users get assigned to views has also increased from 551 to 947.
Most noticeable factor is the number of organizations using views has increased by 10 over the past 15 days, with new views being created everyday.
- The Views remain being a corner use case, only applies to a small group of user when administrator wants to restrict access.
- Significantly more customers has started noticing this features, begin exploring and making use of it. New designs bring better discoverability and usability to the feature.
- Views are definitely a useful tool for customers to easily configure the role-based access control for their user base. As Pure onboard new customers, new customers are trying to make use of it.
- What didn’t work: Simple filters (Unnamed views), engineers team doesn’t believe it will be useful, so naming is still a required process in creating of a view.