Open laurenluz opened 3 weeks ago
Please take a look at the proposed structure and designs for the Profile page.
So with the new method in mind, I create two sections for the profile page.
1. User Verification On the first section, User can verify with the MBD method, or [in case they couldn't pass the MBD] use Gitcoin Passport.
2. QF Donation Eligibility This section is more like an informative section just to make it crystal clear for user either they are eligible or not.
Now let's dive into the designs!
Users A, are those who don't have a connected Gitcoin Passport and are Not verified using the MBD method. For these users, they can only see the MBD card and the Gitcoin passport card is grayed out and disabled.
When they pass the MBD check successfully, the Gitcoin Passport is get enabled, but on the QF eligibility card, they can see that, they are already eligible for QF matching.
In case the user fails the MBD check, the Gitcoin passport is get enabled as an alternative way for user to verify.
And when they passed the Gitcoin check...
User B, are those who already connected their Gitcoin Passport
User C, are those who passed the MBD check and also connected their Passport before.
Thank @mosaeedi that's looking great! I just shared your comment w/ @CarlosQ96 as he's working on the backend API integration.
One thought - I wonder if users will be confused if we name it "Quick identity check", since it's not really related to identity. Maybe we can name it "Quick on-chain activity check" or something similar? What do you think @laurenluz ?
Hey @mosaeedi! This looks pretty good but tbh I think we can make it a lot more simplified for the user. Seeing all these parts "user verification" and having that separated from "qf eligibility" imo is not necessary because the user verification IS the eligibility, it's just the method by which they verify that changes. The advantage of the MBD system is that we can make thing a lot less complex for many users... so I would like the design to be a lot simpler as well.
If you think it's ok, I would suggest removing the bottom box entirely and having the user see just one box basically... that changes in copy and appearance based on the following states. They would only see the gitcoin passport info (replacing the 1st box) if they do not pass the 1st check on the MBD. So the states would be: (1) wallet not connect (2) wallet connected but not yet checked w/ MBD (user sees button saying "Check eligibility") (3) wallet connect MBD passed (button grayed out, user see label "QF eligible") (4) wallet connected, MBD failed, gitcoin passport not yet checked (Copy is "We need a bit more information to check your uniqueness. Please verify your Gitcoin passport") (5) wallet connected, MBD failed, gitcion passport checked and not passing (6) wallet connected, MBD failed, gitcoin passport check and passing (button grayed out, user sees lable "QF eligible")
For initial copy, I'd suggest:
Title for the page: QF Donor Eligibility Subtext: Verify your identity to ensure your donations can be matching in quadratic funding rounds.
Box copy, e.g. for case (2) wallet connected by not yet checked w/ MBD Box title: Quick Identity Check Subtext: Verify your donor uniqueness with a quick check of your on-chain activity. Button: Check eligibility
After the user passes, the label says "QF eligible".
What do you think? Also could you link to the figma? cc @koday1
Aside from that, can you also help to outline the banner copy & the donation success page copies for each of the different states? I think we will need to make adjustments to the logic and it would help to make this all clear for our devs.
Also, thinking about this... should we keep all this verification information in the user profile? or do you think it would be better to make this a kind of replacement for the https://giveth.io/passport ?
And then we direct users to that page through out existing QF flow?
Hey, I've updated the designs and made some adjustments,
I've added the QF eligibility badge to the header instead of showing it at the bottom! please take a look.
(1) wallet not connect [ No Change ]
(2) wallet connected but not yet checked w/ MBD (user sees button saying "Check Eligibility")
(3) Wallet connect MBD passed (button grayed out, user see label "QF eligible")
(4) wallet connected, MBD failed, Gitcoin passport not yet checked (Copy is "We need a bit more information to check your uniqueness. Please verify your Gitcoin passport")
(5) wallet connected, MBD failed, gitcion passport checked and not passing [ I'm not sure what I have to do for this step ]
(6) wallet connected, MBD failed, gitcoin passport check and passing (button grayed out, user sees lable "QF eligible")
Take a look here -> Figma Link
Here is the mini banner for the Projects list/view project page I've updated some and disabled some(Grayed out). Please review all of them and let me know if we need to add any more banners or won't need any of them.
take a look here -> Figma Link
@mosaeedi @koday1 let me know if the design is done so @Meriem-BM can start on it.
Here is the final designs for the My account / Overview tab
My account / Overview
The screen on the left shows the overview tab with the new QF card. On the right side, you can see the QF card in all different states.
And the QF eligibility page, aka Passport page(before).
The QF Eligibility page on the left! and the different states of the QF Eligibility card on the right.
Also you can look at the prototype here to better understand how it works.
@mosaeedi let's finalize the banners before we pass this to devs.
also @koday1 @CarlosQ96 @Meriem-BM we have the made sure we don't merge this issue until the GIV-earth round is over. we can introduce a big change of eligibility like this mid-round, and it's ofc not going to be finalized tested and merged before tomorrow morning.
@mosaeedi The banners look good! @Meriem-BM please see the new banners above from Mo, and let me know if you have any questions.
We are adding a 2-part user verification model for qf eligibility. Backend is explained in https://github.com/Giveth/giveth-dapps-v2/issues/4221
This issue is for design. The user flow is essentially:
We will have to consider:
@mosaeedi @koday1 cc @CarlosQ96