Roles and Permission

Multitudes is a team analytics tool designed for use by both managers and individual contributors. Properly configuring roles and permissions was essential to ensure appropriate access levels and facilitate the implementation of a pricing structure.

Overview

Multitudes is a collaborative analytics tool designed for use by both managers and individual team members. A key aspect of Multitudes is that it empowers individual contributors to view and provide context to their own data. Performance metrics are exclusively displayed at the team level to emphasise the collective effectiveness of team collaboration.

Goal of this project was to release an MVP of the roles and permission settings for the beta product and through user research and testing, determine the critical features to prioritise for the next iteration.

duration

1 month

Tools

Figma, workshop facilitation, user testing

My ROLE

As the sole product designer, it was my role to lead the UX and UI for this feature. That included discovery, interaction design, UI, prototyping, testing and working collaboratively with engineers to implement and QA.

Background

Multitudes’s vision is to create equitable and inclusive teams through surfacing insights about team wellbeing, collaboration, and effectiveness. During its beta development the initial permission settings meant that everyone had the same roles and permissions. Customers were only able to invite new users to the product by emailing the team to update this manually. However, we knew that in order to allow the product to be customisable and scalable, customers needed to differentiate viewers (users could view the content) and contributors (users whose data was part of the insights) and be able to do this themselves.

Process

As the first full-time design hire at Multitudes and sole designer, my role involved establishing design methodologies and procedures to integrate a double diamond design approach into our workflow. The double diamond approached ensured we spent time understanding the problem in order to build the right thing.

As a relatively new product, Multitudes had regular communication with their customers, providing the perfect opportunity to advance towards a continuous improvement model. That's when I discovered the concept of continuous discovery, where discovery became part of the team's weekly work. It was a sustained practice of experimenting and engaging in customer conversations to inform product development decisions. Through continuous discovery, we were able to stay closely connected to our customers and potential future customers, using every interaction as an opportunity to learn more about the problem space and validate potential solutions.

Understanding the problem

As part of continuous discovery for this product I conducted initial discovery research with the following key learning goals in mind:

• What roles and permission terminology made sense for users in respect to a teams analytic tool?

• What are the main and secondary users of the Multitudes platform?

• User goals, needs and pain points with the existing roles and permissions.

• Best practice roles and permission settings and how it influences pricing structure.

Research methodology

• 5x interviews with current and potential future customers

• Desktop research on existing/similar role and permission features

• Opportunity canvas with team to understand the business goals and how we wanted to price our product as this would influence how we would set up roles and permissions within the product.

Intended outcomes of research

• Clear understanding of customer jobs to be done and business needs.

• Understanding of what features to prioritise and why.

Research insights

After my initial research I shared my high level findings with the team and together we synthesised key themes through affinity mapping.

Key findings

• Our main users would be:

  • managers who did not code - including executive leaders

  • system administrators that set up the product

  • managers who coded and

  • individual contributors.

• Secondary users would be:

  • contractor and

  • other roles such as Product managers

• We needed our roles and responsibilities to cater to different team structures - some organisations had clearly defined roles for managers that did not do any coding, while in order organisations managers were also individual contributors.

• We wanted to design the roles and responsibilities to serve our current customers while also allowing for flexibility and more nuanced permissions.
  

User needs identified

• Self-service onboarding
  Users want to add new users easily for just-in-time onboarding to enable existing users to create accounts and assign default roles with predefined permissions.

• Varying levels of permission levels
  Users need to establish different permission levels for security purposes, such as controlling access to billing by allowing users to choose from various roles (e.g., admin, viewer) when onboarding new users.

• Access management
  Users require visibility into who has what access by providing a dashboard to view and manage user roles and permissions easily.

• Billing management
  Users need to manage billing for new users by include billing features access as part of the roles and permissions setup.

define solution

Based on the research, I decided to model the roles and permissions feature on Role-Based Access Control (RBAC). RBAC method groups users into roles and assigns permissions according to those roles rather than grant permissions on an individual level.

I facilitated a workshop with the team to understand what permissions each role would have.

Validating the designs

Team feedback

Based on the roles-based access control established with the team, I created wireframes considering potential future states and prioritised features.

I shared the wireframes with the team to gather feedback before prototyping the feature for testing and validation. During team feedback sessions, I made sure to clarify the type of feedback required and the current stage of the design. For this round of feedback, as it was an early stage wireframe, I sought extensive feedback to guide the next iteration of designs. The feedback questions included:

• Content - is all the content the user requires to perform their job represented?

• Page purpose - is the page purpose clear?

• Layout - are the content elements properly placed and in a logical place?

• CTAs - does the feature have clear and correct call to actions?

• Technical feasibility - what are the technical limitations and considerations?

User testing

At this point in the design process, I had developed a design system which I was able to leverage to quickly produce a high-fidelity prototype. Over a period of 1 week, I conducted usability testing with existing customers and primary users to validate whether the design was intuitive for users and allowed them to easily update roles and permissions.

For the usability testing, I created a script with multiple tasks including:

• updating another team member’s role from viewer to contributor and 

• inviting a viewer

The usability sessions tested revealed some potential usability issues and also what terminology made sense for users. I implemented the feedback into the designs.

Implementation

Once the design was validated I did a walk-through of the designs with the engineers. At this point the design was a future state of what we would want to build over a few cycles and it was important to work with the engineers to estimate and break down stories in order to deliver valuable slices of working software to customers. I did this through facilitating a user story mapping workshop to map out out the phase 1 product release.

I worked closely with the engineers to spec out missing interactions and error validations. I conducted a UX review of each ticket that was implemented to ensure it was aligned with the designs before going live.

Next steps

• Monitor usage patterns.

• Conduct further usability testing sessions when looking to implement enhancements to the feature.

• Set up error logging to proactively pick up issues to fix.

Future considerations

• Automatically surfacing Github users to the application and allowing administrators to add the users, in order to help streamline onboarding new users for customers.

• Set up automatic notification emails for billing and team member updates.

Results and key takeaways

Since implementing the roles and permission feature we have seen customers self-service their own role and permission updates. This significantly cuts down the time-taken for customers to onboard new users by removing the need for engineers to respond to update user requests and configure roles and permissions manually.

Challenges

• Catering for various user flows: Important to accommodate the different permission levels and data inclusion updates, while also limiting access according to user permissions.

• Fixed timeline: We had a set deadline for the Beta release. To meet this, we recognised the importance of addressing specific knowledge gaps and risks through a one-week discovery period to ensure we delivered a functional feature that met customer needs and was user-friendly. Given the fixed timeline, we had to narrow the scope by deprioritising certain features for future releases.

learnings

• When creating new features it helps to define what is and what isn’t in scope. Creating a user story map helps map out the skeleton end-to-end process a user must go through to complete their task. By doing this, I was able to communicate with the team what features should be prioritised and validated before moving onto the next set of features.

• User testing should continue once the product is live. Design is a constant iteration of improvements for the end user.

• It is important to prioritise user feedback along with business goals. It may be tempting to jump onto the latest feedback from customers but when building out a beta product there are additional core features that also need to be prioritised.

• Collaborating closely with a cross-functional team during the early ideation stage fosters a thoughtful approach that balances technical feasibility with business goals. This teamwork enabled us to transform technical limitations into opportunities, refining the design for incremental delivery while also identifying potential edge cases that needed consideration.