A UI isn't just an app, or a program running on a screen, everything man has built to interact with by others have a UI, from simple tools cutlery, to complex industrial control systems.
UI design has a very simple goal, "simplify usage", from the shape of the handle of a knife to a color coded matrix of indicator lights at an industrial monitoring system, it all comes down to "simplify".
Unfortunately there are just so many, many different needs of the person interacting with different systems that there are very few exact rules to follow.
You mention apps, so let's limit outselves to software...
The first question that the UI designer needs to know is "what should the UI allow the user to do".
It could be as simple as "register a smartphone when issuing the phone to a user".
This means the UI needs to accept input of six pecies of data:
Manufacturer of the phone
Model of the phone
IMEI number of the phone
Name of the user
Date
Name of the person issuing the phone
Ok not that bad, so you make this, but then you quickly realize that the user of the system needs a way to check if the phone was added to the system correctly.
If this is just added in Excel, then it is a solved problem, but if you are building a completely new system, then you need to add a way to get a list of all phones issued in the system to the UI, you also need to add a way to update posts in the list.
Then you realize you it would be very helpful to have a way to see the actual status of phones in the system, there will be times to log if a phone is sent for service or if it gets stolen or so, so you add a status field.
After a few months of accumulating data, the list looks good, if a bit messy, you can't get a good overview of it.
So you add color coding to the status field, white for in storage, green for in production, yellow for on service, red for lost/stolen, grey for retired.