Everyone wants things to look good. Apple taught the tech industry about the value of design, and that you can charge a substantial premium for it. There are even studies that suggest that products can be made more usable simply by looking better, regardless of the actual ease-of-use, since people will spend more time exploring something that looks good.

The thing with analytics platforms is that they don't fit into this category. No one uses analytics tools recreationally -- they exist to solve a problem. And when you need to solve a problem, you care less about what the solution looks like as long as it works.

One of the things about the UIs for analytics platforms -- dashboards -- is that they come out of a great motivation. That inspiration is simplicity. The designer always wants a simple way for the user to get at their data. The catch is that this often takes the form of a "clean design", which involves varied colors, gradients, and other visual treatment.

I've written before about building the data sources and reporting tools in a Lean way. This approach fits in perfectly. The point is not to build ugly software. The point is to build software a few features at a time, and while making sure they work as needed while avoiding the overhead of styling. Once they work, then finish with the styling.

One of the biggest things that comes to mind is the humble graph. If you're displaying data-over-time, there's going to be a graph. When most engineers see a design comp showing a particular graph, they're going to spend time customizing a plugin to look like the design -- colors and such. (If the design team is especially good, they'll base your designs off a widely-used graphing plugin and provide you with the customization details)

Other style elements that typically show up in early versions are the stylized "trim" around the data and the ability to show or hide different elements. These aren't essential to the functionality of "will the platform give me the data I want?" which means they should be deferred until that question can be answered.

This deferment ends up being the responsibility of the product manager to tell their engineers "don't worry about making it look exactly like this at first, just get the data graphed and we'll make it look right afterwards". This kind of statement starts the discussions to give the engineers the understanding of the product's real needs, and the flexibility to get those early versions out the door quickly, ensuring that the product will end up serving the user's needs.