When someone (remember to define who!) looks at your app, they’ll subconsciously build a map/model of how your system works. This model doesn’t have to be accurate nor complete, and very often it certainly doesn’t match your system model and architecture diagrams. But it needs to be good enough for the user to get their task done. Example: many devs think of a git repo as a tree of commits, and they mostly get the job done even if that’s not at all how git actually works.
The challenge then becomes to communicate a sufficient mental model with the minimal amount of effort on the user’s part. (You could write a user manual or an interactive onboarding tutorial, but let’s be honest nobody is going to read that.)
How? Reduce the burden by explaining in terms of things they already understand. Examples:
* Practically all UI toolkits come with buttons that resemble real-life physical buttons. You don’t need to read the label or anything else to recognise that pressing it will trigger an immediate action. * A bus ticket app will visually display the ticket in a design that resembles a paper ticket. This helps drive home the point that «this box with a QR code in it is just like having a ticket in your hand».
A lot of design work can be seen as mapping out first what the users need, then how to communicate to them through the UI how your system can help them achieve whatever they want to do. This involves finding users and asking them a boatload of questions to understand how they think, what they really need. And also whether your UI communicates a sufficient mental model (don’t contaminate their minds by explaining your UI!) and how to fix it when it’s inevitably not correct on the first attempt.
After all that, you can start worrying about colors. There’s lots of good recommendations here already, highly recommend both reading some of the books and observing some real users trying real systems for the first time afterwards.