Bluescape
Bluescape is a secure virtual collaborative workspace unify your content and conversations in a shared, persistent space that can be accessed from any device or location. Dispersed teams can now work better together. Our customers are from media & entertainment, the federal government, commercial brands, and creative design industries.
The Project
Custom Role and Permissions System on Bluescape Portal
Bluescape Portal is a platform for users to access their workspaces and manage collaborators, and for admins to manage users, organizations, walls, and other configuration settings.
Project team includes 2 product managers, 1 engineer team lead, 1 UX designer, 4 frontend engineers and a team of backend engineers, who also work on other products.
Timeline: May 2018 - Mar 2019
My role: solo designer for the portal team
Process: UX research, UI design, mockups, prototyping, presentations, usability testing, cross-team collaboration, visual design, design specification, documentation.
Background: One of the biggest advantages of Bluescape is that it is an extra secured platform. That's why many customers choosing us. We want to enhance this point and provide a better user access control system by introducing custom-built roles and permissions. This feature was asked by almost every client, especially the government instances, and will have a big impact on future selling deals. So the problem we want to solve in this project is:
“How might we create a flexible role and permission system to allow clients to built custom roles to meet their security and access control needs.”
For the design process, I want to tell 3 stories according to the 3 iteration steps, including what challenges I faced and how I solved these problems, and what I learned along the way.
Story 1
Product requirements
When I first got this project, I just started my work as a UX designer at Bluescape. I had basic training in the internal design process but not the products. Mostly, I learned the Portal product by reading through the existing Sketch file.
About this project, I had a brief conversation with the PM and she gave me a PDF file with her rough idea. There was no clear PRD with project background and customer requirements. That was not my expectation, but she said it's fine to have a mockup and start to work with engineers from there.
Research - industry standard
I researched about G Suite Admin console, Google Cloud Platform, Salesforce Administration, etc to understand the industry standard.
V1 Design
Based on the PM's material, it should be pretty easy to design the UI and flow. So I finished the V1 draft mockup quickly for early testing. I tested and collected feedback within the UX team, and improved the affordances and flows. I scheduled a meeting with the support and customer success team, who will use the feature. They thought the flow was intuitive, but they have feedback on how the individual permissions should be named and structured.
Here, I got confused. Everyone got their version the permissions. Which one makes the most sense to the end-users? Because the feature was mainly driven by a government client, I can't contact them to validate the assumptions. With the feedback, I tried my best to create a permission list. This was the V1 Design.
Story 2
Ah, I see!
As I know more about the product and spoke to more people, I figured out that the backend already has a permission structure. but they don't have enough time to improve it before the frontend engineers start to develop. What a waste of time! It was a valuable lesson for me and the team! We need to improve the communication within the project even we were from different teams.
Roles & Permissions
I updated the design based on the backend permission structure and split organization-level and workspace-level permissions. I created a spreadsheet to document the permission endpoints and make sure all the people use that file as the single source of truth.
V2 Design and release
After a few weeks of close work with frontend engineers, the version2 custom roles and permissions has been softly released to several customers for gathering early feedback. This version includes CRUD(create, read, update, delete) functions, change organization role flow, batch change organization role, change workspace role flow, admin email notifications.
Story 3
Issues of V2
The feedback about the flow is positive, but we can't avoid the permission changes in the backend. There're several issues exist.
1. The individual permissions are flat with no hierarchy.
2. The dependency relationships between permissions are missing.
3.The list of 30 organization-level and 21 workspace-level permissions are overwhelming to admins. 4.Some of the permission should only be controlled by built-in admin, but not custom admin role due to security reasons.
Finalize the PRD
The good news was we had a new Head of Platform Product Management came on board, who has clear logical thinking and also can directly contact customers. With his help, we completed a clear PRD, which is missing from the beginning. It listed the customer requirements into three phases: P1 for MVP asks for access control needs of the customer; P2 - fast follows(nicer to have; workaround exist); P3 - out of current scope.
Reorganize permissions into groups
I worked closely with the backend team lead to re-organize the permissions into groups, to have more flexibility for future changes. We also simplify the permissions by hiding certain ones that won't affect customer requirements or keep our platform secured. I create a chart to visualize the new permission group structure and shared it with the team. Now, information sharing already becomes my habit of working collaboratively.
Final Version V3
Compare to the previous version, the final version was pretty simple, and greatly reduced users' cognitive load, but meet all their needs. If we want to unveil certain ones, we can easily create permission groups with one or more permissions and show them in the UI.
During the user testing, users all finished more than 90% tasks successfully. User A said: "as a regular user, it might be overwhelming, but it seems standard and pretty easy for IT admins. " User B: "I would give 90 scores for this feature, seems pretty easy to understand, and the UI is very clear."
Visual and info hierarchy improvement
Rather than a plain page layout, I introduced the card element to the portal product to better categorize content on pages. Because it's a shared component, it can be reused in the other pages.
To better utilize custom roles, we've added default role setting. Admins can set default organization role, and default workspace role for org users, but the workspace owner can override it to another role. In addition to that, the workspace owner can assign a role to a specific collaborator.
Dialog experience collection
Organization and workspace level custom role dialogs, and permissions for existing roles.
Utilize Custom Roles
Things were getting smoother when we start to discover the right solutions for true problems. After creating these custom roles, the way of utilizing them is also part of the feature. I did the following design to accomplish the whole feature:
Permissions inside workspaces
I create the toolbar and context menu rules for the interactions inside the workspaces, which would reflect their permission. i.e. If a user doesn't have the permission to delete the object, the delete button will be hidden.
Portal 2.1 Role and Permission Guide
To introduce this relatively complex feature to other colleagues and customers, I created a roles and permissions guide. By repurposing the internal guide, I worked with the support team to create the tutorial pages for customers. Our CTO and the head of Platform highly evaluated this effort, and highly liked the documentation.
Release feedback
The options we see in the GovCloud instance are all we need. We created a "Basic User", restricted it's the ability to create workspaces and set that as the default role for new users in an organization - Boom! “This looks great!” We heard the comment from the customer who mainly drove this feature.
What I learned
- Always have a clear PRD with the background and detailed requirements, and make sure all the project member are on the same page
- Because we didn't have a good schedule between backend and frontend teams. The frontend team spent a few weeks to wait for the backend to be ready. I helped PM to prioritized some UX improvements for frontend engineers to work on. We also learned to smoothen the process by starting the backend work 1-2 sprints ahead, the same as design work.
- During development, I learned to utilize a design system cross design and engineer team using storybook. The shared components can be reused in future projects.
- Be self-directed and initiative. In the beginning, I either didn't know the project background, or how important this project is and how complex it would be. And I didn't expect this project would take more than half a year from start to finish. However, this was the most valuable experience for me. I truly understand who am I as a UX designer, what are the challenges in everyday work, and what I will do to not only improve my future workflow but also create a dynamic and cohesive team culture.
Appendix: my other works at Bluescape
My UX team
I’ve worked at Bluescape from Apr 2018 to May 2019. We have a UX team of five to work on various products within Bluescape, like web, wall(wall-mounted screen), portal, mobile, collab, etc. We follow the agile method and had 2-week sprints.
The projects I've worked on:
Portal team: As the only designer for the Portal team, I worked with PM, frontend/backend engineers, and QAs to create experiences for users to manage their digital workspaces and organizations and streamline users’ creation and collaboration process. Taking charge of research, information architecture, mocking-up, usability testing, iteration, design specifications, and user guidelines.
- Custom roles and permissions
- Enhanced user authorization
- Configuration center(future)
- Lobby/lounge(future)
- SSO providers CRUD
- Broadcast messages
- Tooltips + iconography + font improvements
- Custom help menu
- Identity client + error pages
- Instance settings/feature flags
- Wall onboarding and configuration
- Slack integration access request
Mobile team: As the only designer for mobile team, prioritize and design key functions for the mobile app in the iOS/Android store.
- iPad
- iPhone V1
- Mobile - iPhone+Android
Web/Wall workspaces: Worked on key features for Bluescape Web/Wall app to improve the usability of the workspaces. Created proof of concepts for future products and features. Run google design sprint for future directions.
- Embedded video player
- Web preview widget
- Large file upload
- Sapphire project
Bluescape design system: I created and maintain the Bluescape Design System, which includes a shared sketch library and various guideline confluence pages.
- Sketch library
- Typography
- Iconography - Icon font or SVG paths
- Color palette
- Gesture library + Shortcut
Made with ❤️ by Qian