Document Verification Interactions/Methods

Description

It seems we are starting to see more experiences and interactions where users need to verify their identity in one way or another (registering, challenged at login etc). While more teams start looking into verification, it might be beneficial to look into creating component sets or add some documentation to keep everything consistent.

Based on conversations in this issue: Automatically delete unverified unconfirmed use... (gitlab-org/gitlab#352514 - closed)

I think we are seeing enough of these types of verification interactions to document these components and flow in Pajamas so we can implement them consistently when different teams work on them.

Some verification interactions that were done for https://gitlab.com/gitlab-org/modelops/anti-abuse/team-tasks/-/issues/9+

Credit Card Verification	Phone Number Verification	Email Verification

Note: If it is too early to start talking about these interactions, we can close this issue and re-open when it makes more sense.

Figma file

View working file in Figma →

Checklist

Make sure these tasks are completed before closing the issue. If you have any questions, reach out to a Foundations designer.

1. Assignee: Identify the necessary updates or additions, and define a clear scope of your contribution in the “Description” section above. Learn more about objects in the object overview page.
2. Assignee: Change or add an object's conceptual model.
   1. Create a branch in Figma from the Conceptual model file, and add the issue/MR number to the new branch name. That new branch is your “working file”.
   • Follow the existing product data structure as closely as possible. The GitLab API documentation is a good starting point to identify the existing objects, their attributes, actions and relationships.
   • Study the UI layouts that represent the object to inform your diagram. However, keep the object model UI-agnostic. Sometimes an attribute or action in the UI is inherited from a different object. For example, a CI Job might have a reference branch associated with it in the UI, but the reference branch attribute is actually inherited by the Job from the Pipeline object.
   • Use the existing file components to map out the object diagram.
   • If possible, gather feedback from Engineers, Product Manager, or Technical Writer to make sure your object diagram is accurate and understandable.
3. Assignee: Change or add an object's semantic layout. This may be required if the object's conceptual model was also changed.
   1. Create a branch in Figma from the [Semantic layouts file]((https://www.figma.com/file/shVF8UZwrQtkNfMDjcrsyH/Semantic-layouts?node-id=1%3A79), and add the issue/MR number to the new branch name. That new branch is your “working file”.
   • Map out the primary layout for the object you're adding or updating. View Layouts for more information.
4. Assignee: Update the link to the working file(s) in the issue description.
5. Assignee: Ask a Foundations designer to review your working file(s) (ensure they have edit permissions in Figma).
6. Reviewer: Review and approve assignee’s working file(s). Specific questions can be addressed with comments in Figma. Comment in this issue when the content is less specific to the working file(s) or requires greater visibility.
7. Reviewer: Assign to a Figma maintainer for final review (make sure they have edit permissions in Figma).
8. Maintainer: Review and approve assignee’s changes.
9. Maintainer: Merge the branch or add the changes or additions to the target file.
   1. Ensure that all styles and components now belong to the target file.
10. Assignee (or Maintainer, for community contributions): If it’s a new object or a significant change, add an agenda item to the next UX weekly call to inform the team.
11. Assignee: When applicable, add or update the object’s documentation page and create an MR with your changes using the Documentation MR template. If you do not have the capacity, create another issue using the Object documentation issue template so we don't forget about it. Mark the new issue as related to this one. Bring the issue to your team planning session for prioritization and scheduling.
12. Assignee: Congrats, you made it! You can now close this issue.

changed milestone to %Next 1-3 releases

added Figma UX pajamasdefine labels

assigned to @emilybauman

Hi @emilybauman,

Please make sure that both a workflow label and weight are added to your issue. This helps to categorize and locate issues in the future.

Thanks for your help!

This message was generated automatically. You're welcome to improve it.

removed Figma label

added workflowstart label

mentioned in issue gitlab-org/gitlab#352514 (closed)

Hey @tauriedavis - I wanted to get your thoughts on documenting verification methods in Pajamas, as we are seeing this experience pop up in more areas lately. Or if this is too early to be thinking about?

FYI @jackib

@emilybauman Thanks for the issue! If we are using verification in multiple places, and foresee us doing it more, I can certainly see a need to add some guidance in Pajamas. I don't think this would be considered a component, but perhaps a section under Usability?

It's more a pattern than a component so I think something under Usability would work. Seems to make sense to start documenting it asap, before we add even more flows like this! Thanks for the issue @emilybauman! cc @kcomoli @dmoraBerlin

@jeldergl As a tangent/thought exercise here, where would something like this live in the hierarchy you are working on? Is this considered a pattern under that structure?

@tauriedavis good question. I've have to think on it a bit, but initial thought it that it could live in one of two places:

1. Patterns - Specifically a form pattern with required inputs. I think this could be abstracted out to a form with required fields where each of the steps represented in the description are just individual forms with validation.
2. Flows - If this is more about a verification process and the steps are repeatable and shouldn't be viewed as individual steps then I could see there being a verification flow.

Ultimately what I see is just a form with required fields where the input has to match some parameters to be valid. Of course it could be both: a form with validation and alert when invalid; and a verification flow that includes specific steps.

In my working draft I have the current Usability section content being moved under a new Guides section. In that way there could be a page about verification, and if no specific or repeatable UI patterns exist and it's more conceptual, then I suppose it could live there in that form. If there's concrete UI, then I would opt for one of the other considerations.

@jeldergl - Thanks for your input here.

If there's concrete UI, then I would opt for one of the other considerations.

I think this is what we are moving towards. We want to keep the same input fields and content anytime someone needs to validate their credit card, phone number or email, so the experience is always the same. These pieces can fit together in assorted ways (someone may have to verify all three), but the forms themselves should stay consistent.

This post could have some good form inspiration https://adamsilver.io/blog/where-to-put-buttons-on-forms/.

@jackib @jeldergl - As I'm not working in the area of verification anymore, I'm wondering the best way forward with this issue? Any ideas?

@emilybauman do you think this is something that still needs documented or is still relevant? I can't recall it being brought up recently. In the meantime I think you could simply unassign yourself. Is there anyone currently working with verification who could pick it up or provide further input?

@jeldergl - This was mostly related to design work being done with groupanti-abuse - but I don't think they have a designer at the moment, so I don't think its immediately relevent.

Perhaps this can be circled back to when they do, I'll un-assign in the meantime.

unassigned @emilybauman

added groupdesign system label

added devopsmanage sectioncore platform labels

added Category:Design System label