I find myself getting into more situations where I have to convey the structure of a project, or the workflow of a functionality, or a general idea for a UI, and I have very limited skills at what I can produce. I can usually get by with simple diagrams and meetings to clarify the rest, but it would be nice to produce more expressive diagrams to convey more complex ideas.<p>Do you know any books or articles or software that have helped you develop these skills? Did you learn to draw diagrams for different scenarios (databases, networks, UI, workflows), or do the skills in one scenario translate easily to others?<p>Currently I usually get stuck into one of the following approaches:<p>- UML, but I find that you almost never want the whole database on screen when discussing something, and to show only parts of the database UML is not so descriptive to highlight the different functionalities.<p>- Boxes and arrows. I always find that colored boxes and arrows work well for 3-4 components, but start getting mushy after that and I need more resources to be able to convey different levels of abstraction.
Great question. I can’t recall any standards around this topic, and iirc it came down to common practices. I read a couple of texts to build some fundamental knowledge that I could say I had a reference for.<p>Now I can pass it on to you.<p>Had to open up my Apple Books library to find these again, but:<p>TECHNIQUES OF FLOW-CHARTING
Louis A. Schultheiss<p>IBM Data Processing Techniques
Flowcharting Techniques<p>I pulled these down from some searches on UML diagramming some few months ago since I needed to diagram some envelope encryption work for a team with a previous employer.<p>The UML-generated code thing is prior to my time, but basic flowcharting techniques on their own are a nice to have skill.<p>You don’t need to memorize endless shapes, but a few common ones like those in the texts above will convey almost everything you’ll care about day-to-day.<p>In my experience, this isn’t a skill you have to exercise often, but if you can do it without being overly sophisticated, some people may appreciate having a diagram now and again for large systems, or involved processes.
I like C4 for system design overview and sequence diagrams to show detailed process of interactions in one particular scenario.
I found these two the most useful for me.<p>I also like to write diagrams as code with <a href="https://plantuml.com/sequence-diagram" rel="nofollow">https://plantuml.com/sequence-diagram</a> cause you can then add it to git and easily version it. Also, a lot of tools on the market have support for PlantUML
Some tips:<p>- start on paper (or something analog like a whiteboard)<p>- focus on the essence of what you want to convey, the big picture of you will, not all the detail. Focus on what you want the audience to remember. Less is more<p>- iterate. If you see your audience isn’t grasping what you convey, you’re not clear. Edit<p>- draw real time as you explain, which allows you to draw based on audience understanding and what you want to focus on
(The C4 model)[<a href="https://c4model.com/" rel="nofollow">https://c4model.com/</a>] is a nice way to capture (IMO) the most important characteristics of a system, and you can learn it in half an hour. Optionally, you can add state transition and sequence diagrams for selected parts of the code.<p>One important thing to take in consideration is that diagrams are not blueprints. What they don't represent is as important as what they include. That's why I like C4: it's limited to answer an important but small subset of questions about your system.
Practice by trying to explain things in meetings or make sense of things. Started with MS Paint and drew terrible (but effective) images for years live in meetings. Later moved onto Visio but I still like Paint sometimes.<p>Learning specialist diagram types like basics of Fault trees has been really useful in some situations.
> it would be nice to produce more expressive diagrams to convey more complex ideas<p>Focus on your reader. It does no good to create an "expressive diagram" if it's too complex for anyone else to understand it.
Good intro to using UML effectively: <a href="http://agilemodeling.com/essays/umlDiagrams.htm" rel="nofollow">http://agilemodeling.com/essays/umlDiagrams.htm</a>
Drawing is the simplest way to get better at drawing.<p>Redrawing is the simplest way to refine a drawing.<p>The traditional way to do this is with tracing paper and overlaying sheets.<p>And letting the first attempt suck…and the second..and the…well the next thing is always more drawing.<p>Not that books aren’t good, it is that mostly you’ll be just nodding along instead of doing the hard work of drawing.<p>Good luck.