UX Scorecard – Secure FY22-Q4 – Identifying vulnerabilities in new code (Dynamic analysis)
/label UX scorecard-rec
- Personas: Sam (Security Analyst), Devon (DevOps Engineer)
- Previous score and scorecard: 3
- Walkthrough video: https://youtu.be/HmOxHcfqfFw
- Walkthrough deck: n/a
- Scoring Notes: UX Scorecard Spreadsheet
- Recommendations: #1829
Evaluation Details
JTBD:
When I am ready to release changes into production, I want to verify it is safe to release, so that I can release the changes responsibly.
Scenario:
Your engineering team just completed a new Rest API for a project, and until today they haven't run any security assessments against it. To maintain compliance with the organization's security guidelines, the API must be scanned for security issues before it can be used. The engineering team has deployed the API to a staging environment for testing.
As the team's dedicated AppSec Engineer, you're tasked with testing the staging environment for vulnerabilities.
Task: Ensure that the team's new API complies with your organization's security guidelines. The organization dictates that a running version of the API must be scanned for bugs and potential security issues with 2 different scanning tools.
Environment: Use the following project to conduct the scorecard evaluation. Feel free to use it directly or fork it first, if desired: https://gitlab.com/mfangman/pet-store-api
Persona(s)
Heuristic Buddy UX Scorecard Checklist
The Heuristic Buddy UX Scorecards are a twist on our UX Scorecard process. These are specifically designed to help identify areas of usability and learnability improvements. They are to be completed by a designer who does not work within the same product area(s) the job can be completed in. Learn more about UX Scorecards
The initial preparation is completed by the Group Product Designer. When the preparation has been completed they will hand it over to the Heuristic Buddy to complete the evaluation who will hand it back to the Group Product Designer when completed to add any recommendations. Read through the steps below for details.
@mfangman)
Group Product Designer (Click to expand
-
Add this issue to the stage group epic for the corresponding UX Scorecards. Verify that the UX scorecard
andOKR
labels are applied, then apply yoursection
andgroup
labels as well. -
After working with your PM to identify a top job, write it using the Job to be Done (JTBD) format: When [situation], I want to [motivation], so I can [expected outcome]
. Review with your manager to ensure your JTBD is written at the appropriate level. Remember, a JTBD is not a user story, it should not directly reference a solution and should be tool agnostic. -
Create script scenario(s) based on your JTBD. The number of scenarios used per job statement often depends on the complexity of the features tested. - Tip 1: You might find job statements to be too broad to serve as guidance for writing script scenarios. If that is the case, consider breaking the job statements down into user stories as an intermediary step. Then go back to draft your script scenario.
- Tip 2: Keep in mind your buddy may be missing the subject matter knowledge needed to understand the script scenario. If needed, offer a brief, high-level overview of the job to give them context. Avoid going into details about how to perform tasks within GitLab.
-
Make note of which personas might be performing the job, and link to them from this issue's description. Keeping personas in mind allows us to make the best decisions to address specific problems and pain points. Note: Do not include a persona in your JTBD format, as multiple types of users may complete the same job. -
Describe the characteristics this persona may impart if they were a new user for this job and the GitLab environment they will be joining. Consider that it most likely is not an empty group/project but instead could be an active team with multiple groups and repositories.
-
-
If your JTBD spans more than one stage group, that’s great! Review your JTBD with a designer from that stage group for accuracy. Note: This stage group's designer cannot be your Heuristic Buddy. -
Ping your Heuristic Buddy and let them know it's ready for them to conduct the evaluation. -
Work with your Heuristic Buddy to ensure they'll be evaluating GitLab in the correct environment setup that is appropriate to a new user attempting to complete the JTBD that you've selected. This environment should attempt to replicate the most realistic scenario that's appropriate for your persona in a "new user" state. This may not be a brand new/empty project.
@mle)
Heuristic Buddy (Click to expand
-
Review the current experience, noting where you expect a user's high and low points to be based on our UX Heuristics. Using an experience map, such as the one found in this template, capture the screens and jot down observations. - During the evaluation strive to wear the hat of the persona relevant to the JTBD and while doing so try to see the UI from their perspective as if they were a new user.
- As you progress through your evaluation this will be easy to forget so it's recommended to put a reminder somewhere in your view, such as a post-it stuck on your monitor that says "You're a new user!"
-
Use the Grading Rubric to provide an overall measurement that becomes the Benchmark score for the experience (one grade per JTBD), and add it to this issue's description. Document the score in the UX Scorecard Spreadsheet. -
Once you've completed your evaluation, create a walkthrough video that documents what you experienced when completing the job in GitLab. Begin the video with a contextual introduction including: - Your role, stage group
- Specify how you conducted the heuristic evaluation
- Add a short introduction describing the JTBD and the purpose of the UX scorecard (i.e. you're performing the evaluation in partnership with {stage group} and {product designer}.
- This is not a "how-to" video, but instead should help build empathy for users by clearly showing areas of potential frustration and confusion. (You can point out where the experience is positive, too.)
- At the end of the video, make sure to include narration of the Benchmark Score. Examples here and here.
- The walkthrough video shouldn't take you long to create. Don't worry about it being polished or perfect, it's more important to be informative.
-
Post your video to the GitLab Unfiltered YouTube channel, and link to it from this issue's description. -
Link to your video in the Engineering Week in Review. -
Once the evaluation has been completed ping the Stage Group Product Designer in this issue letting them know it's ready for their review and recommendation creation.
@mfangman)
Group Product Designer (Click to expand
-
Collaborate with your Heuristic Buddy to create recommendation issues as needed. -
Add a UX scorecard-rec
andOKR
label on every issue for traceability, then apply yoursection
andgroup
labels as well. -
Add Severity labels to every issue for prioritization -
Link your recommendation issues to your main UX Scorecard issue - Tip 1: Brainstorm opportunities to fix or improve areas of the experience.
- Use the findings from the Emotional Grading scale to determine areas of immediate focus. For example, if parts of the experience received a “Negative” Emotional Grade, consider addressing those first.
- Tip 2: Think iteratively, and create dependencies where appropriate, remembering that sometimes the order of what we release is just as important as what we release.
- If you need to break recommendations into phases or over multiple milestones, create multiple epics and use the Category Maturity Definitions in the title of each epic: Minimal, Viable, Complete, or Lovable.