The logic for what you display is driven by business concerns. The logic for how you display it should be driven by usability, design, and maintainability (in that order, IMO) concerns. Sure, there are inevitably some ties between what you need to display and how it will be displayed. For the best flexibility those should be kept minimal, though.

Model, view, controller (MVC) application development is one major way this is done. Your core business data is in the model. What to display when (as well as how to manipulate the model) is in the controller. How the data from the model is displayed is in the view.

My applications tend to have a class for each kind of business data with which I'll be dealing. An object of that class stores and retrieves the data. There is another object for the screen or web page. There is some code that retrieves data from the business object and updates the screen object. It's not a full-blown MVC framework, but my business logic doesn't need to be concerned with colors, placement, or sizes of items on the screen.