I feel you’re focussing too much on the graphics part. Sure, some carefully crafted graphics will usually be helpful to improve a reader’s comprehension of what

I feel you’re focussing too much on the graphics part. Sure, some carefully crafted graphics will usually be helpful to improve a reader’s comprehension of what you’re trying to say. But too much focus on the graphics part ends up with the same pitfall as modern software UI/UX, that seems to be optimised for having fancy, clean, modern looking screenshots on the product landing page and marketing materials, rather than actually improving the user’s experience when using the [software/contract]. I.e., the unstated actual goal of the UI/UX is to improve the vendor’s experience marketing and selling the product, instead of improving the user’s experience achieving the product’s intended purpose. In my experience, “legal design” frequently reduces complexity, not by carefully understanding and clearly explaining what is meant or by improving the underlying process or agreement, but by just deleting complex things altogether and only keeping the simple stuff. This ignores that even the most boring transaction can actually be pretty complex, in the same way that implementing a seemingly small feature in software may actually turn out to be a lot more complex when actually writing down functional requirements, let alone the technical implementation. It doesn’t help to have someone eagerly drawing some fancy graphics that only tell 5% of the story and deleting the other 95% as if it’s not relevant. Sure, it looks good at first sight but it completely misses the point. However, I am hopeful that more and more companies are realising that it makes business sense to actually improve their standard contracts. It just doesn’t make sense to have lawyers drafting a document that no one reads but that actually governs the client/supplier/employee/... relationship, and then spending a lot more money on creating a completely different set of materials (e.g. FAQ, help pages, standard support ticket responses, ..) that are actually read and (hopefully) understood but which are (almost) meaningless to determine the parties’ actual rights and obligations. It seems entirely logical to have these people working together to create a single set of materials that is both understood by all users AND the ultimate “source of truth” governing the relationship. The direct cost of creating this single set of materials will likely be higher than creating two sets, but the indirect benefits and cost-savings should be well worth it. Obviously, there are limits to this. In a lot of cases, mostly for non-commoditised enterprise products, ambiguity between the non-binding (transactional) marketing materials and the actual contract that no one reads, is not a bug but a feature. But that’s a different story...