Pinnacol Assurance – 2020
New Feature: Roles and Permissions
Using data and design thinking to solve enterprise user problems, create new designs, and target the right users for MVP and beyond.
Overview
At Pinnacol I was responsible for creating and iterating all customer facing portal designs; Roles and Permissions is an example of a feature set where I leveraged quantitative and qualitative research to inform and iterate my designs and then support engineering handoff—all in close collaboration with development, architecture, and product.
Project scope
The scope from my product owner was to create MVP user permission designs to ultimately support the larger company goal of capturing 80% of new business in our new system, so we could retire the legacy system over the next year or two. Additional designs for reaching the remaining 20% would be created later when further development resources became available.
Specifically, my responsibility was to design, test, and handoff mockups representing how insurance agency admins would create and manage user permissions—and identify how my designs could scale to support the future needs of users.
The UX risk of getting it wrong was substantial; agent customers generate the majority of Pinnacol's revenue, and have been generally happy with the legacy systems in place. I addressed this risk by building fresh relationships with Pinnacol's internal agency relationship managers to ensure their customer knowledge was shared with the team and for help building a list of customers for user testing purposes.
Discovery
I began by supporting product discovery efforts to further "shape" the project, meeting with stakeholders from architecture, frontend development, agency relationship team, and other key stakeholders. I also spoke with a handful of agency employees directly about their organizational structures and how they use permissions today.
Learnings: It was clear from the outset that the existing permissions structure offered too much customization, to the point where admins often skipped past them entirely or just gave their users full access or no access. Furthermore, there was a strong imperative from the architecture team for the new system to have fewer permissions that would be cheaper to maintain.
I also learned that the new system would initially be able to accommodate agents with integrated corporate structures, but not decentralized structures. Agents with more complex setups would need to limit users access to, as a theoretical example, locations A and C, but not B and D—though it was not yet clear what percentage of customers would be affected.
Initial design and user testing
I mocked up a handful of design options for testing and shared them with dev and design colleagues for feedback and feasibility. Thanks to their critique, I was able to narrow down my variety of UI explorations to two primary designs to develop into prototypes for user testing.
Drawing from the spreadsheet of relevant customers I had created with the help of the agency relationship team, I organized and facilitated the first round of moderated user tests.
Results: My initial designs did not match user mental models of roles within their agencies and also proved too cumbersome. Consistently, testers thought of permission groupings as activities rather than job roles. Furthermore, they preferred two roles to three, with all features spelled out. And in terms of verbiage, they preferred 'User' over 'Account' as latter was confused with 'Customer Policy'.

Design and iteration with user testing
Before I began integrating the feedback from my first round of testing into a single prototype for the second round of testing, I realized there was an opportunity to fill in gaps of understanding in terms of agency business models and how they relate to Roles and Permissions.
With the project significantly ahead of schedule, and with buy-in from my team, I took a deep dive into researching and categorizing agents into personas. I spent several weeks working closely with the Agency Relationship Team to categorize all of our agents (over 700!) into similar personas, capturing their characteristics, structure, size, and more. Once complete, I created a slide deck to share in our company-wide, bi-weekly demos.
With the persona knowledge in mind, and the feedback from the first round of testing, I created a second round of moderated user tests with different users in similar roles.
Results: The new testers responded positively to the new prototype, paving the way for product and dev handoff and development for the fourth quarter of 2020.
Next steps & measuring impact
To capture my learnings from the user tests and gain stakeholder buy in for dev-ready designs as part of Q4 product initiatives, I created a research report to socialize the findings with the product team, Agency Relationship Team, and others.
Finally, I created redline mockups so that front-end development would be able to quickly map my design intent to the components and styles in our React library.
The next steps include supporting dev during development and, following release to production, reviewing analytics data from FullStory and Pendo to measure the impact of my work and keep the product team abreast of iteration opportunities.