Thanks Bryan, it’s been a pleasure!
1 Like
@caoimghgin the only thing that worries me about designers building these architectural style guide documents is designers themselves breaking them when it’s convenient. I do think that if designers can get this right, it massively extends into scaling not only designs but the code-base architecture as well… thus increasing the development and decision-making speed.
Fantastic article by the way!
I love this! This is a finger pointed at me, but when engaged in design research it’s the most valuable way to identify where the answers lie.
I’m curious how you might view the lack of formal design education in today’s workforce. Do you think that formal design education helps with critique and modern thinking? Is post-modern though also a cultural norm at this point?
1 Like
The decline in practitioners’ ability to form value judgments based on defensible principles and critique work is institutional — not something you’d pick up from YouTube or a boot camp. This is post-modern culture capture: university epistemology transmitted as professional norms, absorbed without the scaffolding to recognize it.
This isn’t an argument against education but an argument for teaching better. Falsifiability, evidentiary reasoning, the ability to say “this is good and here’s why” instead of “it depends on context” — design education has largely abandoned these tools.
Without them, practitioners can deconstruct but can’t build. And when nobody can make an affirmative case for what’s good, the loudest or most senior voice in the room wins by default.
2 Likes
Thank you very much!
To your point, the fix is procedural and understanding that a rules-based environment provides a more stable, enjoyable, and professional work environment.
A style guide needs a governed exception process: you can break the rule, but you document why, and the exception either gets absorbed into the system or rejected. Without that, every deviation is entropy. With it, deviations become evolution.
The deeper issue: a rules-based system only works if people accept losing in the short term. You follow the constraint, even when breaking it would feel better right now, because the alternative is the tyranny of “I feel this way today” — where nothing scales, nothing compounds, and every decision becomes politics. You’re right that this extends into the code-base. When design and engineering share architectural constraints, the style guide stops being a document and becomes infrastructure. People break documents. They don’t break infrastructure.
2 Likes
Intersting perspective. In your opinion, what happens when people push back against the infrastructure?
1 Like
This was an awesome response. Thank you @caoimghgin !!
1 Like
@caoimghgin love this example:
Especially when providing user feedback/research as the reasoning. We often try to do this on the fly with our client work, attributing design decisions to data reasoning, though we don’t often (if ever) see that reasoning applied to a framework that team’s can refer back to. The decisions are made, and then the research is often lost among the pile of other data. Definitely a strategy to build around!
2 Likes