Two key aspects make these diagrams useful.  First, they isolate the parts and relationships in the program relevant to the intended changes, which keeps them simple.    This makes it easy to  visually reason about the current and future state of the software, which has been called ``reasoning in the diagram’’.  Although the programmer might be aware of other parts of the program which might be impacted, they aren’t necessarily represented, again to keep the diagram simple.
	The second aspect is that they record problems and intended changes in the program, so they can serve as a visual `to-do’ list when later implementing the changes.
	These hand-drawn diagrams are very flexible, but take effort to produce, may be an inaccurate, and can’t easily represent redesigns (unless the programmer goes to the trouble of drawing multiple diagrams).