How to articulate the difference between design principles and aesthetic style?

Question

One of the barriers I've encountered within UI design is a blurred distinction between implementing proven design principles and a designer's judgment for aesthetics and style. I would like to know how to best articulate these different influences when discussing within a team, and with stakeholders? With the goal being, to improve one with minimal impact to the other.

To elaborate on this further, I'll give you an example.

A UI Designer creates a new comp. Technically it's sound, and there really are no usability concerns. The designer has even factored in proven design principles such as the Golden Ratio or Fitts Law. Everything is great, and we could move forward with making a good product, except... it could look better. The design team is attached and thinks it does look good. After all, it uses the Golden Ratio! So how could it not? The stakeholders are impressed, the developers are on board, so what is left to critique without nitpicking?

The Inverse Problem

A UI designer comes up with a slick, shiny, impressive visual UI design as a high-fidelity mock-up. This would be impressive on dribbble or any other established gallery. While they didn't use the Golden Ratio, they used their own judgment, and they're talented enough that it still looks amazing. The design even includes common, familiar, UI concepts. So stakeholders are impressed, and developers are excited to get started. Everyone is enamored by what they see. But now the problem is, it could work better.

To Recap

I think it is best to marry these separate influences as seamlessly as possible, to make one final amazing product. But in my experience teams tend to focus disproportionately on one over the other. Sometimes to the point of sacrificing valuable quality in one area of potential influence.

So how do you explain, and quantify, the differences internally to a team and to stakeholders so that both get the necessary consideration without bias?

Answer 1

This is exactly why you build wireframes separately from look-and-feel work: it makes a very clear separation between these two separate concerns, and ensures you do them in the correct order -- because, as you point out, it's far too easy to mistake an aesthetically beautiful design for one that actually functions properly.

Wireframes themselves can come in a couple of sub-stages, it's generally best to start with the overall structure and rough interaction design, before handling the layout, grouping of controls, and proportions of page elements in a second pass.

Only after those concerns are nailed down should the aesthetics, look-and-feel, styling work begin. Layout ratios and proportions can still be tweaked at this stage, it's not paint-by-numbers work, but if you find yourself doing any large-scale rearrangement of features it's time to go back to wireframes until you've sorted it out.

Even in organizations where the same people do both the structural and the aesthetic design, it's essential that they do these tasks separately, and not concurrently:

• The value of wireframes is that they let both stakeholders and the designers themselves evaluate the product design on its own merits, without being distracted by look-and-feel.
• Separating these tasks helps keep non-designer stakeholders on track, and leads to more meaningful and useful feedback about the structural design. It's really easy for anyone in the room to form snap opinions about what particular shade of blue something should be. It can be really difficult to have meaningful discussion on how product features should be arranged; that takes more thought and attention. Therefore, in any review meeting in which there isn't a hard line drawn between the functional and aesthetic design, 99% of the discussion will naturally wind up being about the colors and icons instead of the functionality. (Even when there is a hard line drawn, this takes vigilance; I can't count the number of times I've had to remind the sales guy or the marketing guy or etc that no, these are wireframes, we're not talking about colors right now, that'll be next week...)
• It (nearly always) ends up improving the look-and-feel, because the designer can focus entirely on that when building it, without having to think too much about structure; similarly, that structure provides useful constraints on the rest of the design process (there's no "blank sheet of paper in front of me, what do I do" stage to work through.)
• Stakeholder review of the look-and-feel, too, ends up being more focused and useful, because everyone's already been through the layout and structural issues at the wireframe stage; now they can think clearly about the aesthetics without distraction.