✅ Pilot: Consider Secure stage experience split for designer focus
Outcome:
Description:
The Secure Stage has gone through a team split, mainly on the Backend and Product Management so there is more focus for specific areas of the stage. Now that we have 2 designers (to be 3 in the fall) we should consider a similar split within the stage to give each designer an area to focus on and a sub-group to be the main contact for.
Goal:
- Decide whether an interstage split is the right decision
- Decide what the split should look like and the responsibilities of each area are.
Decision:
How we've divided the stage
It's difficult to divide the stage based on the categories we have today and how those align to an experience or set of features for a designer to be responsible for. With that said, we believe we've found a way to assign a designer to each sub-group based on the experience categories we've defined in: #447 (closed) Saving you a click here is what that looks like:
| Engineering Groups | Static & Dynamic Analysis | Software Composition Analysis | N/A | N/A | N/A |
|---|---|---|---|---|---|
| Experience Group | Security Scanning & Testing | Compliance & Auditing | Vulnerability Management | Status, Reporting, & Metrics | IA, Core functionality, Inter-stage experiences |
| Assigned Designer | @andyvolpe | @kmann | Shared | Shared | Shared |
We aligned the experience group with the engineering group that had the most overlap but keep in mind it's not a clean split. There might be times when an issue is for the ~"Secure::Software Composition Analysis" that has more relation to (Security scanning & testing) and visa versa. We'll try our best to stay aligned with the engineering groups as much as possible and in the event that an issue is better suited for the other experience group we'll communicate that with both a label and a note in the issue for awareness.
UX Workflow adjustments
Labeling issues
The best way to implement this initially is through the use of labels. We'll create 3 scoped labels to help us identify which experience group a particular issue falls into and which designer should be subsequently assigned.
-
Secure UX::Shared- Issues relating to (Vulnerability management) • (Status, Reporting & Metrics) • (IA, Core Functionality & Inter-stage experiences)
- Examples: Adding Secure to the left nav, Inline vulnerability management, Dashboard designs.
- Who to ping: IF no designer is assigned: Both @andyvolpe & @kmann. If a designer is assigned, ping them in the issue.
-
Secure UX::Security Testing & Scanning- Issues relating to security testing, scanning, and detection of vulnerabilities or weaknesses.
- Examples: MR Widget security report design, Secret detection, DAST - list of scanned URLs in MR.
- Who to ping: @andyvolpe
-
Secure UX::Compliance & Auditing- Issues relating to features that support Compliance and/or Auditing activities
- Examples, Security gates, License Management, Dependency list.
- Who to ping: @kmann
Note: These labels are only to be used when UX support is required.
They do not need to be applied to issues that are solely engineering based. In the beginning, UX will apply these labels due to the nuance that could be involved. More on this below:
Grooming, planning, and assignments
Secure UX will have its own grooming session which will take place during the planning phase of a milestone. During grooming, we will add the proper label to all issues requiring UX support.
Meetings
Secure UX weekly meeting:
- For now, there will continue to be 1 UX Secure meeting where we discuss all things UX + Research + Secure.
Engineering group meetings:
- The assigned designer will attend (sync or a-sync) their associated engineering groups meetings.
- It's the designers' responsibility to communicate with one another in the case that something is discussed that may impact the other designer's work.
What does this mean:
- For PMs, Engineering managers and engineers