There's a common split in how software gets built: engineers build the system, and then an interface gets placed on top of it to make the system usable. That split makes sense organizationally. It's a mistake architecturally.
The interface isn't a presentation layer bolted onto a finished system. It's one of the system's outputs, as real as an API response or a database write. When a form doesn't tell someone why their submission failed, that's not a missing UI detail — it's a system that fails to communicate its own state, which is a systems problem wearing an interface costume.
Some of the best engineering decisions I've made started as interface questions. Designing what an empty state should say forced a decision about what 'empty' actually means in the data model — is it zero records, or zero records the current user can see, or a query that hasn't run yet? Those are different states that a hand-wavy interface would have flattened into one blank screen.
Working this way means involving interface decisions earlier than usual, before the backend model is fully locked in, because the questions an interface forces you to answer are often questions the backend needed answering anyway.
The practical implication is sequencing. Sketching the states an interface needs to represent — loading, empty, partial, error, success, and the transitions between them — before finalizing a data model tends to surface gaps that pure backend design misses, because backend design rarely forces you to imagine a real person looking at the screen with nothing on it.