Defining the persona(s) for Compliance
What’s this issue all about?
groupcompliance is refining its vision to align with customers and their needs for compliance-enabling features. In order to articulate our vision well, we need a formal, defined persona. This issue seeks to create a new persona for the "Compliance" or "Auditor" role within an organization.
What questions are you trying to answer?
- Who is the typical user of Compliance features? (e.g. downloading audit reports, viewing audit logs, conforming GitLab permissions to internal policy)
- What challenge(s) are they trying to address? (e.g. "audit evidence is too hard to find", "Our password policy requires
{{ rules }}
") - What user personas are currently asking for Compliance features?
- Are the existing user personas intermediaries for the real Compliance persona(s)?
- Do existing user personas want the burden of the Compliance features?
- Would an "auditor" role and complementing features resolve the pain points of existing user personas?
- What information does the Compliance persona(s) need from GitLab?
What hypotheses and/or assumptions do you have?
Assumption: The current user personas are seeking features or value on behalf of other personas, the actual Compliance stakeholders. Assumption: The current user personas would prefer information be made available directly to the Compliance persona(s).
What decisions will you make based on the research findings?
We will modify the Compliance category strategies and feature prioritization to align with the findings.
When do you need this research to be completed? (Milestone or date)
Ideally, this research would be completed before January 1, 2020.
Progress
This persona has been shaped by research conducted for Project Compliance (#637).
- MR to add persona to handbook: gitlab-com/www-gitlab-com!47186 (diffs)