> Replace default file inputs with custom ones
Be careful with this. A non-trivial fraction of the custom file inputs that I’ve seen have been imperfect in ways that made me wish they’d stuck with the default. (This used to be a much more common problem; now it’s normally done right, or right enough.)
> Autofocus the first input input
Be careful with this. Focusing a field is disconcerting if the user didn’t expect or desire it: on desktop computers, Space is commonly used as equivalent to the Page Down key, but if you’ve focused something, it won’t do that; and on mobile devices, it’ll probably pop a keyboard open, perhaps blocking the user from seeing what’s actually going on. Only ever autofocus anything if an explicit user action has indicated they certainly want to interact with the form (some examples for the public internet: the user clicked a “log in” or “sign up” link, or you’re a search engine and they opened your front page; but if you’re an advertising landing page and have a form you want the user to fill out, don’t autofocus it; or if you have a search bar, don’t autofocus it).
if the page you’re loading has only the one If there’s anything else on the page, don’t autofocus anything.
I’d argue that most forms shouldn’t use autofocus.
(Also, s/input input/input/. While I’m thinking of this, I noticed a “recuve” that I think should have been “reduce” earlier in the document.)
> Help users fill the form without errors
> 3. In login/signup forms provide social authentication methods.
That’s… quite a way out of scope for UI design considerations. Subjectively so, anyway.
> 4. Use masks for such fields as dates and phone numbers so that users don't guess the correct format.
Strong disagree, with prejudice. Masks are evil. Unqualifiedly so. It’s difficult to implement them in a way that won’t lead to unpleasant surprises anywhere, and outright impossible on the web. Do not use masks. Rather, prefer to validate and reshape data afterwards. e.g. accept all kinds of date formats, then on blur rewrite it to an unambiguous and well-understood format if possible, or at least a canonical and clearly-described format (e.g. for dates if you really want to put the month as a number rather than a name, make sure the order is clear, otherwise you’ll confuse either those pestiferous middle-endian people or the rest of the world).
> 6. Limit the symbols that the input accepts. For zip code it's reasonable to allow inputting only numbers.
Be careful with this. If you’re in the US, not all ZIP codes are just “five digits”: ZIP+4 codes are formatted like 12345-6789. If you’re in the UK, postcodes are alphanumeric. Oh yeah, also make sure with all of these things that you still represent them as strings, never numbers, or you’ll drop leading zeroes (e.g. in Australia, Darwin City is 0800) and probably run into validation problems in frontend, backend or mailing. Related: not all payment card numbers are 16 digits long. They can be 8–19 digits long.
> Show validation errors in the right place
But at the same time, make sure that the user can find the errors. I’ve definitely had forms where… there’s an error somewhere, but where is it?—because they didn’t make the styles clear enough.
> Put an overlay on images for better text contrast
Also consider blurring the image (in whole or in part). That’s very effective. For a detailed background image, a 30% black underlay and blur may be more effective than a 70% black underlay.
> You can quickly check the contrast level with chrome developer tools.
Wah, I dislike singling out just one browser. No idea about Safari, but Firefox has had this sort of stuff for a while too. (With these sorts of things, it’s a mixed bag as to which browser gets them first, but the other usually follows not long after.)
> Watch your shadows
The “good” example here actually shows a problem: the blur radius on the second box is too large and so sits on top of the first box. It’d be really nice if you could specify a different z-index for box-shadows to avoid this, but you can’t. So if your blur radius is large enough to collide with other containers, you have to be very careful about z-indexing. (If the shadow increases on interaction, like a hover effect, you may wish to pair that with a z-index bump so that the element draws on top of its previous and next siblings.)
> Don't rely on dots in gallery sliders
… but at the same time, consider whether you want to keep the dots as a supplement to indicate position. Or some kind of M of N indicator. (I say consider; it may or may not be useful.)
> Label your icons
You can even try going further: see what it’s like if you ditch icons altogether in favour of labels. Often it works out nicer this way (though you’ll probably still want to keep icons in a few places, for well-standardised icons).
> Leverage empty states
But be careful with this: you should strongly prefer your empty state to guide the user to the UI that will persist after the empty state is no more, e.g. draw an arrow up to the “add new” button, rather than putting an add button in the empty state that will only appear that one time. It’s all about training the user.
> Use skeletons
Skeletons are drastically overused these days. You might not notice it if you’re in the USA, but come visit us in Australia (once COVID border restrictions are done!) and experience the high-latency internet, and you’ll get tired of seeing skeletons, especially animated ones. I’m going to glibly say: just make the stuff load faster, and come up with alternatives to skeletons. (“Don't show loader right away” a couple of pages later deals with the periphery of this problem, thanks. s/traction of seconds/a fraction of a second/ there as well.)
> Button loading state
Ah, good times. I’ve designed a UI before where it would have multiple rows, each of which could have an “Add” or a “Remove” button, and I wanted them to be the same width, but it wasn’t a grid or anything. I settled for rendering both labels inside the button, with the false label given a height of zero (and hidden from screen readers too, don’t forget them). I was quite proud of the trick.
> It will give users some assurance that the app is working and not broken.
Except that I am very unlikely to believe the text, because I’m used to the idea that if it took longer than a few seconds, it’s probably not going to work, for various possible reasons (e.g. JS client error, network error, server error).
> Forbidding users to enter lengthy content by limiting the number of characters they can input
This is far too likely to backfire. Either you’ll upset people because the limit is too low and now they can’t enter something that they need to enter, or you haven’t actually solved the problem because someone keeps spamming ﷽ just because it’s typically so absurdly wide for a single Unicode scalar value. (And here I’m not even getting into the discussion of how you define “characters” in your limit.)
----
There are also quite a number of grammatical errors that you might want to look into dealing with.