Update Secure & Protect User Personas
<!--Please answer the below questions to the best of your ability.--> #### What's this issue all about? (Background and context) This Epic will be used to track research issues following the process listed in the Handbook Page on [How to Create a User Persona](https://about.gitlab.com/handbook/engineering/ux/persona-creation/). Updating, & Validating Secure and Protect user personas, Creating additional personas if necessary. This research came from a synced meeting with @sam.white in which he related the shortcomings of the current secure & protect personas, which were lacking accuracy compared to the industry and client outreach. Primary areas of concern are: 1. The JBTD and tools for multiple persona would more accurately belong to one or several other personas. With the Security Operation Engineer (Alex) persona being researched in the past with both internal ([issue #358](https://gitlab.com/gitlab-org/ux-research/-/issues/358) and [external](https://gitlab.com/groups/gitlab-org/-/epics/2215) participants, it is more likely that this research will focus the Security Analyst (Sam) persona. 2. There are several personas missing that could provide significant usefulness to both secure and protect groups. These include Application Security Engineer and Infrastructure Security Engineer. #### What are the overarching goals for the research? 1. To update any personas as needed with more relevant & useful information. Since these concerns have been felt for some time (which was confirmed through multiple team members), it is likely that substantial changes may be necessary as the outcome of the research surface. 2. To create any persona as needed, to build a more clear picture of our users. A possible sub-goal for this may be to investigate other avenues for displaying the JTBD for each persona, as early feedback indicates that there is significant variance from company to company which may depend on the size or maturity of the company. 3. To gain a deeper understanding of the user personas in secure and protect, including ones not currently existing in the handbook. Specifically, to gain familiarity with the common frustrations, tools, and workflows of those personas. A priority for this goal is to create a neutral perspective for each persona, rather than a gitlab-centric perspective. Gitlab specific details will be surfaced only when necessary. The practical reason for this being that a neutral perspective will eventually help identify areas of growth for gitlab software. #### What research questions are you trying to answer? Fundamentally, all goals should be fulfilled by answering these major questions: - What are all of the relevant User Personas necessary for my stakeholders - What are the Jobs to be Done (JTBD) for each persona? - What are a the tools for each persona? - What are the key frustrations for each persona? - What are the additional core values, motivations, workflows, and associated teams in their workplaces for each persona? #### What persona, persona segment, or customer type experiences the problem most acutely? - Sam (Security Analyst) - Alex (Security Operations) Potential additional personas: - Applications Security Engineer - Infrastructure Security Engineer #### What business decisions will be made based on this information? Product Designers will use these personas to provide context for the use cases concerning each design by understanding the JTBD or intersecting software workflows. Product Managers will use these personas to provide context for product direction and potential areas of improvements by using the frustrations, JTBD, and motivations. #### What, if any, relevant prior research already exists? A previous [Epic](https://gitlab.com/groups/gitlab-org/-/epics/2215) was created which resulted in numerous persona - related outcomes by using external interviews. [Internal interviews](https://gitlab.com/gitlab-org/ux-research/-/issues/358) have also been conducted, which was linked to the same study as described above. <!-- Have a look at our UXR_Insights repo: https://gitlab.com/gitlab-org/uxr_insights and look at our sales calls archive: Chorus.ai (requires getting access) --> #### What timescales do you have in mind for the research? #### Who will be leading the research? @moliver28 #### Relevant links (opportunity canvas, discussion guide, notes, etc.) This HB page on [How to Create a User Persona](https://about.gitlab.com/handbook/engineering/ux/persona-creation/) will help guide this research. <!-- Assign this issue to the researcher for your group. If you're unsure which researcher is assigned to your group, you can check: https://about.gitlab.com/handbook/product/categories/ If there is no one listed or you're unsure, assign the issue to the UX Research Director. Leaving an issue unassigned means it may go unnoticed by the UX Research Team. --> <!-- #### TODO Checklist Consider adding a checklist in order to keep track of what stage the research is up to. Some possible checklist templates are here: https://about.gitlab.com/handbook/engineering/ux/ux-research-training/templates-resources-for-research-studies/#checklists --> - 1. A-sync stakeholder conversation sheet - [X] Create issue to track stakeholder conversation sheet. - [x] @molive28 Fill in [Stakeholder Conversation template](https://docs.google.com/spreadsheets/d/1uxrA72Y0Tk3J28n81tWVAJ0LaAcZ7irX5ruQNBVGlLQ/edit?usp=sharing) to prepare for stakeholder - [x] Give Stakeholder Conversation sheet to stakeholders, @ them through this issue. - [x] Have stakeholders fill out sheet by `12/17/21` - [x] Summarise the information given. - 2. Internal Interviews - [x] Create new issue to track internal interviews.
epic