From my experience the number one enemy to good UI and UX is when the interface becomes a reflection of the underlying data rather than the users perceptions and goals.
I once had to test a piece of software that was meant to be an emergency application for when server access failed. It was designed to run standalone and then the data could be uploaded to the server when it was back online so that network outages would have a temporary method to allow work to continue.
Now the single biggest problem with this software is that the user interface was developed based on the steps the database required rather than the steps that the user should perform.
Uploading the offline data should have been a relatively easy process but instead it was an extremely painful process demonstrating a huge lack of user empath throughout.
Stage 1 was a form to define the offline data outage. Then there was a second form where you imported the data files. Then you had a third form to check the validity of the file, then you had to return to the definition to confirm everything is set ok, then select commit. This is essentially because those are all of the underlying database process that need to take place and they are simply reflected with data entry forms for each of the steps.
The user interface should have been a much simpler process, just select the offline file test its validity and if there are no issues commit the changes. If there are conflicts then alert the user. This should take a process from 4 steps with lots of data entry to 1-2 steps with almost no data entry. All the same processing would take place at the database level, but quite simply the end user should not care they should be lead towards their expected goal as simply as possible.
I see lots of this type of design that the user interface reflects the database, and most of the time this is entirely wrong, and can become embded throughout products.