4

I'm creating a form in which a user downloads an analytics report. There are multiple fields that are technically required for submission, but we prefill certain fields so that it's less work for users. Here's a sketch:

enter image description here

More examples:

Report Name: [Monthly Report]

^ We would prefill the input with a name, but users can also edit that name

Send Date: [01/01/15]

^ We allow ability to schedule the report and prefill with today's date, but they could also edit it.

Should these fields still be marked as required?

EDIT:

Thanks for the comments below. I realized I was a little unclear in the definition of the input. It's not an example of what should be placed in the input. It's real content that would be used. So more like a default: http://designinginterfaces.com/firstedition/index.php?page=Good_Defaults

While the examples in that article are from local applications, I wondered if the same rules apply to web app?


ANOTHER EDIT:

I've found some other examples/variations. Perhaps someone could speak to those or at least let me know what the term for these scenarios are. Or even if this is the better route to go?

Editable fields:

Noticed that in JIRA, when you hover over content it is editable, but otherwise the default is not editable. But how do you teach people that those areas are editable? I think Squarespace does this too. http://screencast.com/t/Z2EvPiAN

Showing the preselected input as not editable, but asking for confirmation:

enter image description here

Improve this question
5
  • Hi @Camay and welcome to the forum! Great UX question. Every time you ask a user for input it is a potential barrier to entry so I'm seeing more apps only ask for required input and remove all (required) / (optional) qualifiers. Of course you still need to let the user know when the input field loses focus that it is required but only if it ever happens to be empty which isn't very often especially in your case. – DaveAlger Apr 9 '15 at 21:38
  • @DaveAlger thanks for the welcome and comment! I was editing my question while receiving your answer... What are your thoughts on asking for confirmation on "required fields" like the Amazon example above? I know best practice is to limit fields to only what's essential. What's the best practice for confirmation of info needed for submission? – Camay Apr 9 '15 at 21:55
  • @Camay why not add some help text to make things clearer then? That way your users don't have to think/guess. But the rule of thumb is to design the input so it is as simple as possible rather than create situations where the intended behaviour might be ambiguous. – Michael Lai♦ Apr 9 '15 at 22:01
  • The Amazon example is user friendly because the call to action button Ship to this address is clear and stands out while the other two actions are very rare. In your situation are you asking the user to confirm something that rarely changes? If not then the Amazon pattern doesn't help and forces most users to always click Edit. – DaveAlger Apr 10 '15 at 2:16
  • I don't have any data yet that will tell me if our presets are sufficient for our users. Theoretically, if they just left all the default fields as is, they will get what they need. The editability is to allow them to make it even more custom to them (ie Last 6 Months for Group A instead of just Last 6 Months or Send at 10am [time right now] versus time in the future). You bring up a good point about considering what actions will be dominant and catering to that. Thank you @DaveAlger – Camay Apr 10 '15 at 19:28
2

Those are still required fields.

Based on your edit, your watermarking is using actual data, so you need to signify what fields are required.

The From field you obviously need them to fill in, so you can't accept the default.

The Report Name, Subject, and Date Range fields, however, that's your call. They are valid defaults that the user may want to leave as is. I think that is up to you or maybe some A/B testing.

I would still mark them as required fields though (it's just that the requirement has been met).

Improve this answer
4
  • 1
    Thanks for your comment! The prefilled input is real, suggested content and not an example of what should be filled in. We know the user's email since they have to be logged in to even see this form, so instead of asking to add it, we do it for them. In the case that they want to send from someone else (if it's a reseller account or something), they can edit it. Does that make sense? Also see my edit comment above. – Camay Apr 9 '15 at 20:53
  • Yes, it does. I have read however that it would be better to move the label above or to the right of the input in that case. Otherwise, what @devin is mentioning above happens. – Camay Apr 9 '15 at 20:59
  • Without totally redoing my answer, I would say that in that case, you simply just need to mark your required fields as required, however you want to do that: asterisks, required, red box, or wait until validation. – Code Maverick Apr 9 '15 at 21:00
  • @Camay - I edited based on your edit. – Code Maverick Apr 9 '15 at 21:08
1

While it depends on the form and the data, in your particular case I wouldn't do it. If you pre-fill fields, most users will leave them "as is" because they won't know if they can modify those fields, or they won't care. Either way, a bad behavior because neither you nor the user will get the expected results.

Pre-filled forms should only be used when the input is preferred (for example, pre-selected price options you want the user to choose) or when the form is so long some help may be appreciated. And in any case, it should be very clear they can modify the information. Keep in mind you can always have non-modifiable data as part of your form, but it wouldn't look as a form input anyways

Improve this answer
1
  • Thanks for the comment. That is a good point about indicating whether the form is editable. – Camay Apr 9 '15 at 20:52
0

Some really good answers here and they pretty much nail down the situation. To throw my two cents in, I would say that the more you can do to reduce ambiguity, the better. Prepopulating the fields is a great convenience for the user, but I think that there is still a need to give them a clear indicator of what is expected of them if they decide to interact with the data. I like the idea of field description notes as mentioned above, but a little red star goes a long way on it's own. I guess my litmus test would be what would the user expect if the form wasn't prepopulated; if the mechanism that populates the form was broken for some reason, perhaps. They would definitely need some sort of extra indicator then.

Improve this answer
1
  • Oh and welcome to the forum! :) – Gareth Davies Nov 30 '16 at 16:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.