Software is What We Learned Along the Way

Trent absolutely nails it:

[the why is] where I provide the most value as a designer. I am not merely the picker of fonts, the dropper of shadows, the executor of deliverables. My greatest value as a designer lies in orchestrating the process and gathering insights — applying the whys to the create the optimal what.

Those insights don’t cease to be valuable after a product ships, but instead become more valuable as historical resources that contextualize design — provenance. This accounting of how we arrived at our solution should be retained and organized, accessible to others when needed to prevent repeat work and inform confident decision making.

This is a great articulation of the value and purpose of “design”. As Baldur said, aesthetics (color, type, etc.) are part of what design does but it is not what you hire a designer to do.

Great designers help you get you to the what, but they start by defining the why and its rationale. Unless well documented, archived, and made easily accessible to teams, these rationales are often lost over time.

New team members ask, “Why does the product look and function the way it does?” The only answer is often, “Because that’s the way it was when I got here.”

This is illustrated perfectly in this line, again from Baldur:

Software is the insights of the development team made manifest.

A software product is the manifestation of a living body of insights from the people who build it.

What’s in prod is only half the equation. Why it’s in prod (in the state it’s in) is often only understood in the collective minds of a team of people.

If you can’t capture that to contextualize historical decisions and then improve current and future decision making, you’re falling prey to the classic blunder of history: those who don’t learn from it are doomed to repeat it.

Anyway, excuse me while I look into Luro a bit more…