I get that ugly software diagrams are not fun to look at, but to me dressing them up is like adding curves to a line chart - yes it's visually appealing but it interferes with the data being conveyed.
I get that ugly software diagrams are not fun to look at, but to me dressing them up is like adding curves to a line chart - yes it's visually appealing but it interferes with the data being conveyed.
Had to take Color Theory to get my BFA. We learned things like the "speed" of colors: yellow is the "fastest" and purple is the "slowest". Only a little yellow is needed to balance out a lot of purple. Same for balancing the other colors. You use these balances for guiding the eye (lots of yellow on a purple field).
When you keep this in mind, diagrams or not, then the output will be "pretty" (not jarring) and "informative" (guiding the eye to the most relevant info).
Most diagrams have not had that must thought put into them. They should look a little ugly because that implies it might not be right so look for errors.
Weirdly, prettiness is the bigger red flag for me wrt to error. I see that and feel like more attention was put into that than the underlying information.
Ugly, brutalistic, utilitarian stuff tends to imply a focus on correctness to me.
If that means creating an overview of the system architecture for new team members that uses pretty colours and multiple fonts and icons and shaded boxes but that helps them to understand the system more quickly and correctly than an overwhelming page of black-and-white text and arrows, the extra styling has done its job.
The fewer right angles, the better: I can just draw shapes and put them in roughly the right spots and it'll look fine.