In my opinion, there is no fundamental difference between a "bug" and a "improvement". Both should be prioritized against other issues, and both can span the full range of severity. It is the job of QA to ensure that the product meets the target quality, or at least inform management about the current quality and let them decide if it meets the target. If "Too many colors on the progress bar" is reported as a bug or improvement is irrelevant, the important thing is if it should be fixed, and if so, when.
When considering if something is a bug or not, one guiding principle is "does it bug you?". So do you think the colorful progress bar fits the application? You should in principle report any issue that you think will affect the quality of the application. But in practice it is often useful to report the most serious issues, it might not be relevant to report poor color choice if every other button crashes the application. We have a saying that the number of reported bugs does not decrease as testing progresses, but the severity does.
Any design documents can be useful input when considering if something is a bug or not, but this should be treated as guidelines, if the UI design guidelines specify a colorful progress-bar for a serious business application, it is perfectly possible that the guidelines are wrong. If your company does not have such documents, you can look at other comparable applications, guidelines for the platform you are using etc. It can also be useful for QA to be somewhat involved in all stages of product development, to be able to catch potential issues early.
It might be useful to put on different 'hats' or perspectives when testing. What is the initial impression? How easy are common tasks accomplished? How does it compare to the competition? What would a novice user think? How about an experienced one? Does it look nice visually? Is it reliable? Does it work on different devices? Does it work well for a German customer? How about a Japanese one? How about some kind of visual impairment? etc...
Another important thing is to communicate. It you are uncertain about some issues it might be effective to make a list of them, and go to the product owner, UI designer, developer, or other stake holder and say, "Hi, I'm concerned about some things, do you mind taking a look together?", instead of blasting the bug-tracker with a ton of bugs. If the application is old it is likely a whole bunch of things that are bad, but to costly or unimportant to fix. It might take some time to get familiar with the product and business to get a better feel for what is important or not.