We are having a discussion on what fields should always be asked on a form - First Name, Last Name, Email Address?
There is a thought that we only need to ask for First Name and Last Name and Email will be the first progressive field - only asking for it once. That seems like an odd experience because when the prospect comes back, we could be asking for First Name, Last Name and then Company Name or Budget..
So my question is what are your "always on" fields for progressive profiling? And does email address matter? If so, then why?
Here's the thing: there's no one right UX, and building your dream UX (even if just for internal testing) takes JS skills.
The argument for having a field labeled Email Address be always-on is you want to make sure the lead gets the chance to re-identify her/himself. But there are two sub-cases that are very different:
One case is if the lead means to say I'm the same human, but I'd rather use this address. You can't use the actual Email Address field in Marketo in this case, because if the lead changes that, Marketo will create a new lead. You instead want to use a proxy field (the equivalent of "user-supplied email correction") which is a field that can be used (on the back end) to change the associated email address.
The other, very different case is when the lead means I'm a different human using this browser now. In this case, you do want a new lead to be created, and you do want the actual Email Address to be posted with the new value.
Navigating the differences between these cases requires developer assistance and some firm planning, to be sure.
Granted, the above is only the barest introduction to your question. (Save for my firm view that Email should be one of your always-ons. Although that may -- and perhaps should -- mean an always-on but read-only field that only allows editing when a lead clicks a Change link/pencil icon, etc.)
I think once you get First Name and Last Name, those can be hidden or read-only fields for subsequent fillouts. They should not be editable fields unless the person chooses to edit Email. It is vanishingly unlikely that someone will want to change FN or LN without also making a change to their email, and showing that you understand that makes the form more "human."
So in all of the above cases. we're talking about a third class of field -- the conditionally editable but always-on field.
Opt-In and Comments are two other fields that are typically always-on (and always editable) in my experience. The first is self-evident. The second allows the lead to post questions alongside each form fill: no reason to prevent that. On the back end, you can append that data to a history field that stores all their notes over time.
There are many interesting UX questions around ProgPro. I'm glad you're asking them because people tend to leap into "that'd be awesome" and back out to "that wasn't at all awesome, let's turn it off" due to poor planning.
This is great information and I appreciate your time writing this out. do you have an example of what a form would look like with an always-on and conditionally editable email address field? I understand your reasoning, but I'm have trouble picturing this in real life.
This would be a (primitive) example: HTMLForm :: Click to Edit