# Self-Invented Notation Drawback

**In short:** A self-invented notation is a set of diagram symbols the author made up. Readers cannot tell what the symbols mean without help. A legend, or a standard notation, reduces the problem.

## Explanation

Many architecture diagrams are drawn as free-style boxes and lines. The author picks colors, shapes and line styles as they go. No one has defined what these symbols mean.

**What goes wrong**

- The notation is not explained, or it is used inconsistently. Colors, shapes, line styles and element sizes may all be affected.
- The purpose and meaning of elements stay ambiguous. A reader cannot interpret the diagram without the author's help.
- Diagrams drift as a system changes. Research on deployment diagrams reports that diagrams commonly become ambiguous or inconsistent as the system progresses.

**Why teams end up here**

Free sketching without structure tends to produce a confusing result. Many teams dropped UML (see Unified Modeling Language (UML)) in favor of much simpler boxes and lines. That choice trades precision for speed and ease.

**Mitigations**

- Add a legend (also called a key) to every diagram. It should explain shapes, colors, border styles, line types and arrow heads.
- Use a notation that others already know, such as UML, ArchiMate or SysML. Even then, keep the legend, because readers may not know that notation.
- The C4 model (see C4 Model) prescribes no particular notation. It still requires a key on every diagram.
- A design practice repository describes notations as ranging from ad hoc and informal to full-fledged. It says a non-standard notation needs a legend.

## Example

A team draws a diagram with blue boxes, green boxes, a dashed arrow and a solid arrow. The author means blue as "built by us" and dashed as "asynchronous call". A new colleague reads blue as "database" and dashed as "optional". Nothing on the page settles who is right. Adding a small legend that lists each color and line style removes the guesswork.

## Trade-offs

Free-style boxes and lines are quick to sketch and flexible. The cost is ambiguity: without structure the result can be confusing, and readers need the author to explain it. A legend adds a little effort per diagram but makes the diagram readable on its own. A known notation adds learning effort, and teams have dropped UML for simpler diagrams for that reason. Either way, the legend stays.



## Checks

- Every diagram carries a legend or key.
- The legend explains shapes, colors, border styles, line types and arrow heads used in the diagram.
- Any non-standard notation is accompanied by a legend.
- Colors, shapes and line styles are used consistently across diagrams.

## Related

- [C4 Model](https://arc.fuet.ch/concepts/documentation/c4-model.md)
- [Unified Modeling Language (UML)](https://arc.fuet.ch/concepts/modeling-uml/uml-unified-modeling-language.md)
- [Guidelines for Documentation](https://arc.fuet.ch/concepts/documentation/guidelines-for-documentation.md)
- [UML Modeling Anti-Pattern](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-anti-patterns.md)
- [Architectural Overview Antipattern](https://arc.fuet.ch/concepts/documentation/architectural-overview-antipatterns.md)
- [Why Use UML in Architecture Documentation](https://arc.fuet.ch/concepts/modeling-uml/why-use-uml-in-architecture-documentation.md)
- [ISO/IEC/IEEE 42010 Architecture Description Standard](https://arc.fuet.ch/concepts/documentation/iso-iec-ieee-42010-architecture-description-standard.md)
- [Architecture Viewpoint](https://arc.fuet.ch/concepts/documentation/architecture-viewpoint.md)

## Sources

- [Introduction | C4 model](https://c4model.com/introduction) — c4model.com, accessed 2026-11-09
- [Notation | C4 model](https://c4model.com/diagrams/notation) — c4model.com, accessed 2026-11-09
- [design-practice-repository | Summaries of artifacts, templates, practices, and techniques for agile architecting (DPR-mm) and service design (SDPR-nn).](https://socadk.github.io/design-practice-repository/activities/DPR-ArchitectureModeling.html) — socadk.github.io, accessed 2026-11-09
- [[2008.11060] Applying system descriptors to address ambiguity on deployment diagrams](https://arxiv.org/abs/2008.11060) — arxiv.org, accessed 2026-11-09