It is hard to draw reliable conclusions about an organization from two paragraphs in StackExchange, but it sounds to me as if you're going too fast. The fact that you are constantly changing the product suggests it is fairly new. With new products and new companies, when most of your users are early adopters, it may be more important to release quickly than to release with high quality. If that's really where you are, you may have to live with that condition until you have the luxury of more time.

You referred to UI issues in the title and twice in the question, so I assume your quality issues are specific to the UI; i.e. the rest of the software is in better shape. If you have the time to spare, I suggest slowing down and taking measures ensure that the UI is more thoroughly and consistently tested. If your testers don't use a test plan, someone should write one for them, at least for the aspects of the UI that are especially buggy. Are your testers using the same kind and variety of environments as your users? For example, if you have a browser-based UI, are your testers using same variety of browsers and screen resolutions?

You might investigate why your developers are creating a lot of UI bugs. Are they aware of the quality problems? From their perspective, is it more important to go fast or to unit-test their work before they check it in? Are the developers using the right infrastructure? If a change in one thing causes a cascade of bugs in other places, you may have a design problem.

It is hard to draw reliable conclusions about an organization from two paragraphs in StackExchange, but it sounds to me as if you're going too fast. The fact that you are constantly changing the product suggests it is fairly new. With new products and new companies, when most of your users are early adopters, it may be more important to release quickly than to release with high quality. If that's really where you are, you may have to live with that condition until you have the luxury of more time.

You referred to UI issues in the title and twice in the question, so I assume your quality issues are specific to the UI; i.e. the rest of the software is in better shape. If you have the time to spare, I suggest slowing down and taking measures to ensure the UI is more thoroughly and consistently tested. If your testers don't use a test plan, someone should write one for them, at least for the aspects of the UI that are especially buggy. Are your testers using the same kind and variety of environments as your users? For example, if you have a browser-based UI, are your testers using same variety of browsers and screen resolutions?

You might investigate why your developers are creating a lot of UI bugs. Are they aware of the quality problems? From their perspective, is it more important to go fast or to unit-test their work before they check it in? Are the developers using the right infrastructure? If a change in one thing causes a cascade of bugs in other places, you may have a design problem.

It is hard to draw reliable conclusions about an organization from two paragraphs in StackExchange, but it sounds to me as if you're going too fast. The fact that you are constantly changing the product suggests it is fairly new. With new products and new companies, when most of your users are early adopters, it may be more important to release quickly than to release with high quality. If that's really where you are, you may have to live with that condition until you have the luxury of more time.

You referred to UI issues in the title and twice in the question, so I assume your quality issues are specific to the UI; i.e. the rest of the software is in better shape. If you have the time to spare, I suggest slowing down and spending more time testing.

You should take measures ensure that the UI is more thoroughly and consistently tested. If your testers don't use a test plan, someone should write one for them, at least for the aspects of the UI that are especially buggy. Are your testers using the same kind and variety of environments as your users? For example, if you have a browser-based UI, are your testers using same variety of browsers and screen resolutions?

You might investigate why your developers are creating a lot of UI bugs. Are they aware of the quality problems? From their perspective, is it more important to go fast or to unit-test their work before they check it in? Are the developers using the right infrastructure? If a change in one thing causes a cascade of bugs in other places, you may have a design problem.

It is hard to draw reliable conclusions about an organization from two paragraphs in StackExchange, but it sounds to me as if you're going too fast. The fact that you are constantly changing the product suggests it is fairly new. With new products and new companies, when most of your users are early adopters, it may be more important to release quickly than to release with high quality. If that's really where you are, you may have to live with that condition until you have the luxury of more time.

You referred to UI issues in the title and twice in the question, so I assume your quality issues are specific to the UI; i.e. the rest of the software is in better shape. If you have the time to spare, I suggest slowing down and taking measures ensure that the UI is more thoroughly and consistently tested. If your testers don't use a test plan, someone should write one for them, at least for the aspects of the UI that are especially buggy. Are your testers using the same kind and variety of environments as your users? For example, if you have a browser-based UI, are your testers using same variety of browsers and screen resolutions?

You might investigate why your developers are creating a lot of UI bugs. Are they aware of the quality problems? From their perspective, is it more important to go fast or to unit-test their work before they check it in? Are the developers using the right infrastructure? If a change in one thing causes a cascade of bugs in other places, you may have a design problem.