In a recent user test, a user had considerable trouble trying to use and read the privacy protection modal while using a mobile device (iPhone).
Video can be found in p8hwqp-qF-p2
As they tried to scroll, there was a delay and sometimes the user had to try multiple times to get it to move.
Additionally, because of the narrow width of mobile devices, the user had difficulties digesting and understanding the content.
Screenshots for reference:

This is a proposed solution to fix both this issue and #12632.
The modal window is causing a couple issues and generally isn't a great UX, particularly on mobile. I'm proposing that we remove the modal. Aside from the poor ux of modals in general the current modal has a lot in it, more than may be necessary. Here is a proposal for a much simpler implementation:

This replaces the checkbox that is at the top of domain contact info form with a radio question. This changes from an opt-in only option to a required question, bringing needed visibility to the question. Currently if a user doesn't check the checkbox we show them the modal when they try to continue which is a bit jarring.
I also changed the copy around quite a bit. The main change I made with changing "Privacy Protection" to "Privacy Registration". The rationale was to remove any suggestion that the option is pay us more money or _we_ will post your info publicly (as raised in a recent usability test). For me “Private Registration” puts it on the registration process vs. “Privacy Protection” could be seen more as “We will not share your info publicly if you pay this amount.
After chatting with @ranh we might want to stick with "protection" but find other ways to address my concerns.
Design looks good. I agree that phrasing it as "Private Registration" puts the privacy on the registration process vs. paying us to not give away their information. However, the paragraph phrasing you have here clears up the confusion even if we keep "Privacy Protection". In stating that ICANN (even though it's jargon) requires the domain to have public info it puts the blame on them and not us.
The new hierarchy here also helps to clear up the confusion. In the previous version, the checkmarks were the focus and not the explanation of the domain registration requiring public info.
@mikeshelton1503 Are you thinking of having privacy selected by default or having the user make a selection? Is it a valid concern that adding that extra charge by default could be missed by the user before continuing to checkout?
Thanks, Dan!
Are you thinking of having privacy selected by default or having the user make a selection?
I considered it but that's susceptible to seeming pushy or tricky. I think the recommended treatment is a softer way of doing that. I realize now that that I'm showing it selected in the screenshot above. That was a mistake.
Currently if a user doesn't check the checkbox we show them the modal when they try to continue which is a bit jarring
I agree that this is very jarring and a poor experience for users. The modal itself is not the issue though. And I don't think we can make privacy protection opt-out when we don't include it in the price we show in search results. That would be much worse than the modal.
Keeping privacy protection opt-in and removing the modal is a worthy test, but seems a bit risky to just launch without testing first.
Rather than removing the modal, maybe it would make sense to integrate it as a step in the flow. There was no need for it to be a modal in the first place. That would address a lot of the confusion and jarring-ness, and probably the mobile concerns too.
That said, improving the copy on the first screen, switching to radio buttons instead of a checkbox, and moving it next to the submit button will all increase the chance that users will choose privacy protection on the first screen, and then never have to see the modal at all.
I also changed the copy around quite a bit.
Your changes are good, I just have a few notes.
We should really avoid talking about ICANN unless really absolutely necessary. I don't think it's necessary here. @danhauk's point above about passing the blame to ICANN could apply, if anyone knew what ICANN is. But even then, we can't blame them for setting the rules after we already agreed to play by them. Better to try to focus on the positive, somehow.
"Private registration" or "privacy registration" are not good labels here. They don't adequately describe to a lay person what the service does. And they can be understood to mean that the domain itself would be private, something no one would want.
I don't have very good solutions for these issues. Privacy protection is a tough nut to crack. We want to let people know that it's important, but don't want to bore them in the process.
Based on stuff I already had, I suggest the following minor changes:
Domain owners are required to share valid contact information in a public database of all domains (called "whois"). With Privacy Protection, we publish our own information instead of yours, and privately forward any communications to you.
- Privacy Protection
Protects your identity and prevents spam by keeping your contact information off the Internet.- Regular registration
Your contact information is published with your domain.
This deserves a closer look, but I don't want to put too much attention on this specific detail. The problems with Privacy Protection need to be address at a higher level.
And I don't think we can make privacy protection opt-out when we don't include it in the price we show in search results. That would be much worse than the modal.
Not sure if you meant that you thought this design was opt-out or not but just in case, no that's not the case. The question would be required but the user would have to choose which option they want.
Keeping privacy protection opt-in and removing the modal is a worthy test, but seems a bit risky to just launch without testing first.
Yes this would need to be a test.
That said, improving the copy on the first screen, switching to radio buttons instead of a checkbox, and moving it next to the submit button will all increase the chance that users will choose privacy protection on the first screen, and then never have to see the modal at all.
Since the privacy question would be required this wouldn't be a case anymore. I mean we could still show it if they choose public registration but that seems pushy to me since we're making the make a decision with the radio question.
Domain owners are required to share valid contact information in a public database of all domains (called "whois"). With Privacy Protection, we publish our own information instead of yours, and privately forward any communications to you.
Privacy Protection
Protects your identity and prevents spam by keeping your contact information off the Internet.
Regular registration
Your contact information is published with your domain.
This sounds good. I particularly like the phrasing you used for describing how we substitute our contact info and privately forward communications. I tried something like that but my version sounded more confusing than it did help.
The only part I'm not sure about is "Regular registration". It sounds a bit awkward. Maybe "Public registration"?
Your contact information is published with your domain.
This could be confused to mean that your contact info is published on your domain (website).
How about "your contact information will be listed in a public database"?
Made some copy adjustments based on @ranh's feedback. This is ready for development as an a/b test.

cc @aidvu @lucasartoni
Looks good @Refering. I think we should add the reference to the term "whois" as suggested above:
... database of all domains (called "whois").
Using this term here has a few advantages:
Also, in the last line there's a missing word:
... will be susceptible to spam.
It may be best to omit this though. Spam is the smaller issue IMHO (do people even still care about it?) For many people the fact that their home address will be associated with their site is much more problematic.
How about?
Your contact information will be listed along with your domain in a public database.
@aidvu @lucasartoni This test is ready for development. Can we plan to work this in to the testing calendar in the next couple weeks?