Overview
As the Sensat Platform gained traction among enterprise clients in the construction industry, there was a growing demand for enhanced enterprise controls, particularly in terms of data access and administrative functionalities.
In 2023, I spearheaded a project to implement permission controls within the platform, addressing the need for increased user restrictions.
The Data Access project, although fully designed, remains unreleased with designs pending confirmation and potential changes.
Analysis of past data, including research and user feedback, revealed a prevalent fear among both existing and prospective users about fully adopting the Sensat platform. This fear stemmed from the absence of robust restrictions on data access. Users, especially those dealing with sensitive information like Work in Progress, expressed a desire to limit access to specific users or teams.
Additionally, users were reluctant to explore the platform due to concerns about privacy. The lack of privacy features made them hesitant about experimenting with the platform and sharing their work, as they felt it might disrupt the experience for others.
In summary, there exists a significant barrier for new users to embrace the platform fully, and existing users exhibit hesitancy in openly sharing data due to the absence of adequate restrictions.
The Goal
The goal for the project was to ensure users felt safe and secure in our platform by allowing users to implement data access controls. Our assumptions were that by allowing users to create restrictions and permissions within what they were sharing users would feel less anxious being in the platform leading to more platform adoption.
Our high-level goals were:
Our high-level goals were:
- Create data sharing permissions
- Make the experience intuitive and easy for users to understand
- Give administrators more control over other users.
Role
I led the design of the data access experience from Jan 2023 to September 2023.
I worked with a product manager throughout the entire end-to-end product process as well as 4 engineers on matters such as technical difficulty and back-end implementation.
I worked with a product manager throughout the entire end-to-end product process as well as 4 engineers on matters such as technical difficulty and back-end implementation.
As stated this project has not been released but has gone through the end-to-end product journey.
Who, What, When, Why Exercise to determine research scope
Kickoff: Unveiling the Optimal Journey
In contrast to the data organisation project, Data Access had a more sequential nature. Creators focused on effective data sharing, while consumers sought assurance of accessing accurate information.
The plan aimed to understand how existing sharing methods in Sensat impacted workflow. It included direct inquiries into users' preferred data sharing approaches, gathering insights from both creator and consumer perspectives. Outreach targeted a diverse user group, including those heavily engaged in creator actions and users wanting wider Sensat sharing but facing privacy obstacles.
A specific focus was on the 'Systemiser' Persona, dedicated to ensuring data reached the right individuals and maintaining integrity.
In total, we engaged with 11 users across various projects and clients.
Research plan written in Notion
Research notes: Users want to be able to limit certain capabilities in Sensat
Research notes: Users want to be able to get to the view they want quickly
User Insights
Users want to be able to limit certain capabilities in Sensat
Users, especially administrators, want to limit specific actions in Sensat, primarily focusing on editing and content creation. As the user base grows, the emphasis is on ensuring the platform's content remains secure and unalterable.
User Insights
Users want to be able to get to the view they want quickly
Users desire swift access to their preferred views. In the data organisation project, users found themselves overwhelmed with excessive and irrelevant data due to a lack of effective data access features. This often resulted in data being accessible to everyone, even when it was unrelated to their needs.
Research notes: Users want to feel safe when creating data
Research notes: Users want to work within their relevant teams
User Insights
Users want to feel safe when creating data
Concerns arise when uploading data or creating markups, as users fear that such markups could be accessible to everyone. There is also hesitancy in uploading new data, driven by the worry that it might clutter others' views.
User Insights
Users want to work within their relevant teams
A significant aspect is the ability to selectively share data with specific groups or individuals. As the project welcomes more users, there is a heightened need for a mechanism to precisely share information, ensuring its relevance to the intended recipients.
Solutions Tree Diagram for Data Access project
Navigating Insights: The Solutions Tree Approach
Having established key insights from our research, we seamlessly tied back to our problem statement using the Solutions Tree method. Notably, a distinctive aspect of this project, in contrast to the data organisation initiative, was the sequential nature of the user flow for data access. While Data Organisation influenced changes across different parts of the platform, the Data Access Project highlighted the necessity for a well-defined flow—from a user creating to sharing, and from a recipient's perspective, determining what the user should see. Recognising this, we identified the establishment of a happy path and key areas for focused solution development.
Happy path accompanied with customer quotes from research
Crazy 8 outcomes from Workshop
Building on Established Logic
Our ideation workshop made it evident that to address our users' challenges, we must further expand the sharing capabilities existing in the platform. Proposing the introduction of a level between Personal and Project (Everyone) would enable users to precisely share with designated members or teams.
Additionally, it became apparent that alongside permissions, implementing levels of restrictions based on User Roles is necessary. This approach empowers specific users with designated actions within the platform, assuring administrators that selected users won't be able to manipulate or introduce unnecessary information in their projects.
Initial user flow diagram covering proposed changes (creating groups, settings permissions and managing access)
Tables for roles and data access permissions
Not reinventing the wheel
After team alignment on the logic, a comprehensive effort ensured all platform areas conformed. This involved an audit, documenting role systems, user actions, and data-sharing permissions.
We researched existing software solutions for valuable insights, maintaining alignment in our approach. This research proved beneficial in navigating complexities, providing guidance for challenges and edge cases.
Proposed changes:
Enhance User Role and Data Access permissions
Add ability to create groups
Introduce a Manage Access workflow
Ensure logic integrity across all workflows (comments, viewpoints, markups panel)
Add ability to create groups
Introduce a Manage Access workflow
Ensure logic integrity across all workflows (comments, viewpoints, markups panel)
Do and Don'ts of role and permission levels
Creating Groups
Users have said that when sharing data, they want to be able to share with a certain group of users (utilities team, design team etc). Groups allow users to streamline data access and also help manage users in a project better. We believed that with Groups it would allow Admins to conveniently share data quickly, and easily with certain teams within a project.
Flow: Redesign the 'Team Manger' modal to hold the new "Groups" Tab
Flow: Create group / Invite members modal
Flow: In the members tab, added Group and Role column to support new change
Flow: Group list expanded to show list of groups a member is a part of
Future thinking: Expansion of Manage Group/Profile Model to allow users to offer description of group as well as an easy way to see relevant access the group has
Hierarchical Roles
In line with features observed in other software, the Sensat Platform introduced the capability to establish hierarchical roles. These roles, distinct from data access permissions, focused on defining users' actions across the entire platform rather than their actions on shared data. Through interviews, particularly with systemisers, a recurring request emerged for certain users to have a 'God' view status, allowing them to override permissions for monitoring and ensuring data integrity.
We anticipated that introducing roles would empower users with a self-serving approach, addressing the desire for more 'control' within the platform and alleviating user anxiety.
Flow: Role drop-down showing list of hierarchical roles
Scenario: Warning to users what happens when roles get downgraded
Flow: Affordance to show role change successful
Scenario: Delete member flow, granting users the ability to transfer ownership of existing data to them, ensuring shared data doesn't get lost.
Manage Access: Granual Data Sharing
The current state of the platform makes information sharing too public, residing either in 'personal' or 'project' spaces, visible to everyone. Introducing access management enables more precise sharing with relevant users or groups.
This feature aims to alleviate sharing anxiety by empowering users to define exactly who has access to shared information.
Flow: Removed Project and Personal Tabs (Left) and opted for a free-form file manager panel, using icons as an indication when a file type has been shared
Flow: Share flow button
Flow: Share/Manage Access modal
Logical Flexibility: Inheritance and Detached Logic
Our paramount goal was to ensure that data sharing didn't become a source of frustration for users but rather a second-nature experience. Safety within the platform was crucial, and we aimed to minimise barriers to accessing desired information.
Inheritance Example: In the context of Inheritance, users who had been granted access to data might feel frustrated if that data was relocated. We wanted to avoid users feeling lost in such situations. Thus, we ensured a smooth process for users to both receive shared data and exit from it under an admin's control.
Detached Logic: Similarly, Detached Logic operated on the principle that if users wished to revoke a group's permission, potentially disrupting the sharing logic, we should inform them while providing an uncomplicated means to restore the data to its original state.
User flow: Explaining data sharing behaviour in regards to inheritance and detachment
Flow: Detached Logic
Flow: Restoring Access
Ensuring consistency in existing behaviours
Amidst the proposed changes in sharing permissions, we delved into design modifications for existing features like Comments and Viewpoints that operated in contrast. Initially lacking privacy logic, these features allowed any user to view them, posing a potential breach of privacy and breaking the proposed logic. For instance, in Comments, users could tag markups, and if comments remained visible to everyone, unauthorised users might access those markups.
To avoid scope overload, we chose this juncture to communicate to users why certain data pieces weren't accessible. For features like Comments, we restricted visibility to comments a user was tagged in, mitigating anxiety around others viewing conversations.
User flow: Example of comment flow fitting within the new data access logic
Affordance: Tweaks to notify users why they don't have access/view tagged markups
Affordance: Banner to notify users they don't have access to all items therefore viewpoint may not be shown as intended
Validation Testing
Upon solidifying the foundational flows, our attention swiftly turned to executing validation testing to ensure users grasped the impending platform changes. We reached out to individuals interviewed during our discovery research phase, apprising them of the upcoming alterations. Our validation strategy involved evaluating users' comprehension of group concepts and the intricacies of group creation, extending to more nuanced assessments of user flows regarding permissions and inheritance.
Overall, the feedback garnered from this session was overwhelmingly positive, bolstering our assurance in the feature development process.
Research Plan for our Validation Testing (Left), Prompts and Script for prototypes shown (Right)
Usability Matrix for Data Access
