First, let's look at properties in general. Essentially, a property is data related to an object which describes some aspect of that object. Some properties affect the appearance of an object (e.g., a graphic's foreColor), others affect the behavior (e.g. a window's style or a script), and others simply contain data you can use however you like (the text of a field, the textData of graphics, and user properties). The commands most commonly used to work with properties are "get" and "set", for reading and writing the properties, respectively.
Now, with user properties we have something special. Before user properties, the only data you could attach to an object were those already defined for that object, such as script, name, forecolor, etc. If you wanted anything else, you either had to hide it in the script and parse it out later, or use a global variable, or hide it in a separate field hidden away somewhere. Since SC 3.0, all that's changed.
With user properties you can attach any data of any length to any object. Why would you want to do that?
Suppose you have a flow chart, made up of several button objects. Each button object has its name set to the job title, but suppose you want to be able to have the user click on a button to open a window which displays a job description related to that job title. Where would you store that job description?
Before user properties, you would probably make an entirely separate object to store the data in, maybe a field hidden on the card. But then every time you wanted to add a new object to the flow chart, you also had to make a new field object to store the data, and when you delete a flow chart button you'll also want to make sure you delete the corresponding field. The mechanics of maintaining such a system is needlessly complicated now that we have user properties.
Using user properties to store this data, you have the job description attached directly to the button in the flow chart. If you copy and paste that button, the data goes right along with it, and if you delete the button the job description data is also deleted with the object. Ultra convenient.
To display the data, you could have a simple handler like this in the card script:
on DisplayJobDescription -- called from mouseUp handlers in the buttons
put the uJobDescription of the target into fld 1 of wd "Display"
open wd "Display"
Note: I preceed my user prop names with a lower-case "U" to make them visually distinct from local variables, global variables, and keywords. This is not a requirement of SuperCard's, just my own style.
This brief introduction only touches on the basics of user properties. The ramifications for real-world use are too broad to cover here. But hopefully with even this basic understanding you'll have the building blocks needed to experiment on your own to find great solutions for your projects.