In a very simple and direct way, I would say that there are three criteria that need to be observed:
1. Functionality
If your web application is a commercial or scientific system, it is natural that the most important thing is functionality. That is, the interface should allow the user to use it to achieve one or more practical goals (i.e., solve the problem). If it doesn’t serve this purpose, it completely loses its purpose. Thus, the planning of the interface should consider how to offer such services: for example, input fields for the data that are needed, buttons for the execution of actions, etc.
2. Usability
In addition to the functional character, it is also important that the interface is sufficiently well made to be easily "usable" by the user. This involves several aspects (I suggest reading also this other question) with the intention of making the interaction easy, safe and efficient. An experienced designer can embed his interface planning with good practices, but it is always useful to evaluate this project with real people, representative of the type of user of the intended system, so that problems are perceived as soon as possible. It is therefore a common practice to carry out tests with low fidelity prototypes (made on paper, even) to test interaction ideas, metaphors, logical restrictions, etc.
3. Experience
Far beyond usability (which has a pragmatic character about the interaction being easy, succinct, efficient, etc.), there is also a tendency to worry about the "hedonic" character of the interaction. Hedonic means more subjective issues such as appeal, preference, taste, and even fun. In entertainment applications this "requirement" is very obvious, but it is increasingly perceived that this is a great need also in commercial and scientific systems, especially when the use is optional (discretionary) or requires support (intended to maintain the user’s attention for extended periods). In these cases, prototyping tests also serve to evaluate aesthetic preferences, appeal potential, curiosity generated by certain aspects of the interface, and even satisfaction (not in the sense of merely meeting expectations about interface options, but overcoming them in unique and interesting ways).
Concluding
The planning of an interface in general follows these three criteria, because there is a certain hierarchy of importance between them so that a product is really effective in producing a good usage experience, something comparable* to Maslow’s hierarchy of human needs:
*Patrick W. Jordan. Designing Pleasurable Products. Taylor & Francis, 2002
Utility products (such as a hammer, for example) need to be functional first (useful for something). Only then do attributes such as effectiveness and efficiency become relevant to the user. Finally, less pragmatic attributes (commonly called hedonic or affective) such as appeal, aesthetics, etc., can then become relevant and allow satisfaction to be something beyond the mere absence of discomfort (ergonomics) and users to create meaning for the product ("my hammer works just like yours, but it’s way cooler").
It turns out that as much as this hierarchy exists, the boundaries between them are pretty blurred depending on the type of product intended. Not every product has a mainly utility character, and this also applies to computer systems. Digital games, for example, do not have requirements to be met, so the hedonic/affective character becomes more important. This does not mean, however, that usability attributes are not necessary for this type of product. After all, even though the "problems" in digital games are intentionally designed to are not easy, players still need to be able to understand the interface and know/remember how to use it effectively and efficiently. In fact, some authors** indicate that these attributes have their values changed according to a utility axis (which indicates whether the application is more than "office" or "entertainment"):
**Bentley, Johnston and Von Baggo. Putting Some Emotion into Requirements Engineering. Proceedings of the 7th Australian Workshop on Requirements Engineering, Deakin University, 2002
In any case, part of the "planning" is the evaluation of the design concepts, using prototypes of increasing fidelity and with participants representing the actual users of the system. Because, only in this way it is possible to validate that the function meets the need and that the interaction is as usable as possible, besides gaining very valuable indications about the design choices that carry most affective potential for users.
To learn more about prototyping, I suggest reading this really cool stuff. Also, right here at SOPT there is a lot of useful information on the subject in tags ux and usability.