An app is, essentially a program that interacts, among potentially other entities, people. Implicitly, an app runs on a mobile platform by an older standard. By the current (2022) standard, an app can also run inside a browser.
Increasingly, an “app” also implies that the program needs to be flexible and work with different devices. This includes flexibilities regarding the following:
Last, but not least, an “app” may be installed on a device, or it may be served as a webpage at an URL.
The UML (Unified Modeling Language) is a “rich” language that can be used to describe a system. While the whole UML can be overwhelming to specify an app, especially one that is being developed using the Agile method, some of the conepts of the UML are still quite applicable.
It is crucial to first think of the actors (classifications of entities interacting with an app) and use cases (how the app provides values to each actor).
An “actor” is not a single user, it is not an instance. Instead, an actor is a classification of a group of users. You can think of an actor as a class in object-oriented programming.
A “use case” is not a feature, or a screen, or a menu, or anything concrete in an app. Instead, a “use case” is a reason for an actor to interact with the app.
The UML allows many different relations defined between actors and use cases. For simplicity, a use case diagram/map can be quite effective even without these special relations.
Starting with, and maintaining, the use cases and actors is important. This is because this part is regardless of the design of the app, it has to do with the objectives of the app.
Some may think UI/UX comes next. Interestingly, that is not the case.
In order to serve and accomplish each use case, the “back end” needs an implementation that depends on how data is organized and the logic to perform the operations.
The data that is needed for a use case is particularly important, and so is the outcome (information/data) of a use case. The logic is important only to the point where the specifiation of input data and output data can be documented.
Once the input/output data specification of the back end is determined, then the front-end can be designed.
For each use case, start with a bucket (unstructured and not organized) of data items. This bucket should be coming from the back-end data input/output specification.
While some data items do not require much thoughts, such as plain text fields, others, like date and time, or values with a range, can utilize more fancy input elements.
It is important to determine how each individual data item is presented because this determines the amount of screen space needed. The screen space for each data item needs, in return, determines how much data can be presented on one screen.
For each item in the bucket, take care to specify how much display real estate it will take. This measurement is tricky because pixel count is not useful for high resolution handheld devices. For user interaction, this specification should be in angle of view because the distance from a desktop monitor is typically further away from the distance from a mobile device.
This property is needed in order to determine how many items can fit in one physical screen.
Note that each interaction mode may have a different user interface. For example, on a touch screen, a slider may be intuitive for a small range of discrete values (for example, 1 to 10, with steps of 1). However, a slider is not effective when a user is interacting with a pointing device, or has access to a physical keyboard.
(Recursively) form larger structures by grouping related items. However, be extra clear in the organization where the boundary is when the app runs on the smallest screen. Structures that are too large/complex may need multiple screens in a user interface.
Clearly indicating where “too large for a single small screen” is important because it allows the app to present the user interface in different number of screens automatically.
In an HTML document, the effect of “several screens” can be accomplished by choose which elements to expose and which elements to hide.
It is also helpful to add attributes such as “title” and “description” to each structure so that an engine can automatically generate a title and a brief description of a screen, or a portion of a screen. This helps end users locate specific data items.
Now that related items are “clumped”, it is time to consider how they should be ordered and presented. This can be specified in the form of preferred and secondary direction. For most European languages, the preference is most likely left to right, then top to bottom.
This helps to inform an engine to automatically determine how to “flow” items onto a screen space.
Some data items, but input and output, are mandatory. Some others, however, can be considered optional. An optional data item implies there is a default value, and possibly a user preference that can be stored.
Among optional data items, some may be more important, or more frequently used, than others. Ranking optional data items supplies information to an engine to automatically place such data items in an optional part of the user interface and automatically determine the ordering of these items.
w3schools has a good article on responsive web design. This is about creating content that can be displayed effectively on devices that have different resolutions and orientations.