This is in no way an exhaustive list of everything you need to consider when designing for users, but this is a great collection of pointers and links to get our web development team thinking in the right direction.
Terminology & Wording — Apple HIG
In the same way that it’s best to work with a professional graphical designer on the icons and images in your app, it’s best to work with a professional writer on your app’s user-visible text. A skilled writer can help you develop a style of expression that reflects your app’s design, and can apply that style consistently throughout your app.
Almost all apps need to use some words to communicate with users, even if the only words are in button labels. It’s important to choose all of your app’s words carefully so that you can ensure that your communication with users is unambiguous and accurate.
IN GENERAL, AVOID JARGON
Above all, you want to use the terminology your users are comfortable with. If your app targets sophisticated users who frequently use a set of specialized, technical terms, it may make sense to use these terms in your app. But if your user audience consists of mostly novice or casual users, it’s usually better to use simple, widely understood terms. For example, the Parental Controls preferences pane uses simple, straightforward language to describe the feature and explain what the user can do.
AVOID DEVELOPER TERMS
As a developer, you refer to UI elements and app processes in ways that most of your users don’t understand. Be sure to scrutinize the UI and replace any developer terms with appropriate user terms. For example, Table 12-1 lists several common developer terms, along with equivalent user terms you should use if you need to refer to these items in the UI.
CREATE SUCCINCT LABELS FOR UI ELEMENTS
Make labels for UI elements concise and easy to understand, but don’t sacrifice clarity for space.
WHEN THE CONTEXT OF A LABEL IS CLEAR, AVOID REPEATING THE CONTEXT IN THE LABEL.
For example, within the context of a document-modal dialog, it’s clear that the dialog acts upon a file or document, so there’s no need to add the words “File” or “Document” to the Format pop-up label. Similarly, users understand that the items in an app’s Edit menu act upon the current editing context, so there is seldom a need to make this explicit in the menu item names.
USE THE CORRECT CAPITALIZATION STYLE.
The capitalization style to use in the label for an interface element depends on the type of element. For information on the proper way to capitalize the words in labels for different types of interface elements, see Capitalizing Labels and Text.
Use an ellipsis in the name of a menu item or button that produces a dialog. The ellipsis (…) indicates that the user must take further action to complete the task. The dialog title should be the same as the menu command or button label (except for the ellipsis) used to invoke it. To learn more about using an ellipsis, see Using the Ellipsis.
Best practices for button labelling - stackexchange
To apply a little Einstein, all labels should be as simple as possible, but no simpler. Unnecessarily long labels take longer to read, which wastes users’ time. My impression (based on a little eye-tracking data) is that the longer the label, the less likely the user will read it, as if users follow optimal foraging theory when hunting for commands. Long, descriptive labels can paradoxically make it harder to identify the right command.
So using the example question: “View Project Reports” or “Project Reports”? Everyone together now: It depends.
USER EXPERIENCE WITH PRODUCT
First of all it depends on the frequency of use by each user. A use-once web site generally needs more descriptive labels since users are learning it on the fly. For a regularly used app, the user has to only recognize the command, so the label can be shorter as long as it’s distinct.
To assist the users in optimizing their foraging, each word in your label should have high information value. “View” usually has low information value, mostly because the designer really means something more broad than just strictly viewing. Not only will users view the project report by selecting this command, they also interpret and evaluate the report. They may print, send, copy, archive, and rate the report, if those actions are supported in your Project Report window/page. Other low value words are "Get" and "Manage."
At worse, users might subconsciously interpret a word like “View” too literally. Users looking to send a project report will not think of clicking on View Project Reports because they’re thinking send project report. If the label were simply Project Reports, it would better match the users' search image.
On the other hand, if you really mean just View, as distinct from, say, Analyze (which is done elsewhere in the app), then keep "View" in the label.
To further support foraging, the first word in your label should ideally have highest information value, so the user can reliably pursue or reject a command with an initial glance at the beginning. So if the other commands are Edit Project Reports, Delete Project Reports, and Send Project Reports, you’re good with View Project Reports. On the other hand, if the other commands are View Inventory Status, View Shipping Receipts, and View Personnel Evaluations, maybe you should drop the View.
PAGE/WINDOW/MENU ORGANIZATION AND LABELS
Proper layout and labeling of the context can also reduce your total number of words users need to read. For example, if the commands are Edit Project Reports, Delete Project Reports, and Send Project Reports, maybe you want a frame labeled “Project Reports” with controls for View, Edit, Delete, and Send inside. If it’s View Inventory Report, View Shipping Report, and View Personnel Report, then it’s a “View Reports” frame around Project, Inventory, Shipping, Personnel.
PRODUCT DEVELOPMENT STAGE
In usability testing it’s easier to detect the impact of inadequate text (the user gets stuck or lost) than it is to detect the impact of excessive text (slightly longer hunting). Thus, prototypes should have the shortest labels you judge to be sufficient, and words should be added only when testing shows they’re needed.
If you're going to be doing usability testing, maybe try leaving out "View" but be ready to jump at adding it if you see any signs of user confusion.
Finally, the control you use can provide information that makes a longer label unnecessary. Users understand that a link lets them view (in the board sense) some content. If you had a Project Reports link rather than a button, you shouldn’t need “View.” Restrict buttons for specific actions that actually manipulate the content and have active labels like Delete and Send.
For more on labeling commands see my answer to What are good rules for naming menu items? Actually, see everyone’s answers.
Extensive guide to form usability - smashingmagazine
Form usability - uxforthemasses
Use the user’s terms and names.
It’s important when considering labels that names and terms are used that users will understand and recognise. Try to avoid using your own terms as something that might make sense to you might not make sense to your users.
USE SUCCINCT AND DESCRIPTIVE LABELS
Form labels should be short, clear and descriptive. If extra information, clarification or context is required use help text to do this rather than long rambling labels.
PLACE LABELS NEXT TO INPUTS
Eye tracking studies have shown that placing labels next to inputs (e.g. above or to the left – i.e. right aligned) make it easiest for users to read and associate labels with fields (taking advantage of the Gestalt law of proximity).
DISTINGUISH REQUIRED AND OPTIONAL INPUTS
It’s important to distinguish the required inputs on a form so that users know what information that they must enter. The standard convention is to use a ‘’ to distinguish required fields. For example, ‘Name ’. Don’t forget to also include text at the top of each form page stating that the asterisk signifies a required field.
If most of the fields on a form are required with just 1 or 2 optional then it often makes more sense to highlight optional fields, rather than required fields. A good way to do this is to append the labels for optional inputs with ‘(optional)’, such as ‘Mobile number (optional)’. Short forms, such as a password reset form might have all fields required, in which case it’s usually not necessary to highlight required fields.
This notifies the user that an error has occurred, and it usually prevents them from proceeding further in the form. Emphasize error messages through color (typically red), familiar iconography (such as a warning sign), prominence (typically at the top of the form or beside where the error occurred), large font, or a combination of these.
Use this to notify users that they have reached a meaningful milestone in the form. If the form is lengthy, a success message encourages the user to continue filling it out. Like error messages, success messages should be prominent. But they should not hinder the user from continuing.
ONLY WHERE NEEDED
Excessive validation is as bad as its complete absence, because it will frustrate users. Restrict validation to confirming key points (such as the availability of a user name), ensuring realistic answers (such as not allowing ages above 130) and suggesting responses where the range of possible data is finite but too long to include in a drop-down menu (such as a country-code prefix).
Use smart defaults to make the user’s completion of the form faster and more accurate. For example, pre-select the user’s country based on their IP address. But use these with caution, because users tend to leave pre-selected fields as they are.