Using “Visualizations” in Contracts

I was recently contacted by Nancy Hupp. She’s a lawyer who’s director of, a legal-practice resources website for members of the Minnesota State Bar Association. She’s also enrolled in a graduate class at the University of Minnesota, for which she’s writing a paper on visual representation of legal information.

She was wearing her graduate-student hat when she contacted me. Here’s what she asked:

Law schools use visualizations of legal concepts and legally relevant information, and, of course, trial lawyers utilize visualizations. By visualizations, I mean charts, diagrams, images, layout, timelines, geographic maps, process maps, mind maps, and decision trees. I am wondering what your experience has been with use of visualization in legal documents:

  • Have you come across effective use of visualizations in litigation or transactional documents?
  • Have you come across them in documents intended for the non-legal audience?
  • What is your opinion about the use of visualizations?
  • What problems do you see presented by their use?
  • What kinds of legal information do you think would be well-suited to visualizations?

And here’s what she said in a follow-up email:

Visuals are used routinely in litigation, but I can see how they could be useful in transactional settings. For example, I used to draft transactional real-estate documents; sometimes they would have attached a sketch or map of the property showing a shared easement or other relevant information. And visuals could conceivably be used to depict relationships between parties. Even how an entity signature line is set up serves to convey visually information regarding relationship and authority. And you could use timelines to illustrate notice provisions.

I could imagine charts, graphics, and the like being used in different contexts in contracts, but I haven’t seen any examples recently, so I turn the court over to you: Do do you use “visualizations” of any sort? Have you seen others use them? What do you think of the idea generally?

About the author

Ken Adams is the leading authority on how to say clearly whatever you want to say in a contract. He’s author of A Manual of Style for Contract Drafting, and he offers online and in-person training around the world. He’s also chief content officer of LegalSifter, Inc., a company that combines artificial intelligence and expertise to assist with review of contracts.

8 thoughts on “Using “Visualizations” in Contracts”

  1. I can’t think of any in contracts, exactly, but it’s fairly common practice in some kinds of structured securities to use diagrams to explain the terms in the offering document, which is for all practical purposes the “contract” (the indenture, etc., are papered later to match the offering doc). S-17 to S-21 here for instance: is explanatory rather than independently binding but believe me people look at this more than they look at most of the text.

  2. Visualizations can be used well; it’s just difficult. It’s not unusual in second-level outsourcing documents (i.e., not in the MSA but in an SOW or a procedures manual) to use charts and diagrams. I’m thinking of a flow chart describing a particularly complex BPO change management process that accomplished in half a page what otherwise would have required more than a page of text. And system diagrams are common in IT outsourcing SOWs.

    Two issues come to mind, both manifestations of the same problem: what makes a visualization useful is often its ability to leverage the reader’s vocabulary of symbols and spatial relationships to convey meaning. The more a visualization relies upon readers to fill in blanks, the more open it may be to misinterpretation. (Not always, of course. Equations are visualizations that rely on the reader knowing what a division bar means or what to do with a superscript in that context. By relying on implicit meanings that are common and well-defined, equations are visualizations that can make misinterpretation less likely.)

    First, if the visualization describes something that is also described in the contract in words, it is important to make sure they say the same thing. Smart drafters get this wrong when they fail to recognize the existence of reasonable interpretations alternative to and inconsistent with their own. In those situations, I like to state clearly which governs in the event of a conflict.

    Second (but first in our hearts), the lawyer must really understand the visualization, especially if it is a substitute for, or allowed to govern over, a prose description of the same subject matter. A visualization describing the required deployment of network security hardware and software that was designed by one network administrator for another probably contains or implicitly incorporates information that would be invisible to most attorneys. If the lawyer doesn’t understand what the visualization actually conveys, it’s hard for the lawyer to properly put that visualization to work in the contract documents.

    • I concur. The most significant thing I have seen is workflow diagrams specifying processes that occur as part of a service. They are most useful when the “service” is large set of activities where the customer is making a lot of decisions along the way. So, there’s a little piece of the service, then a customer decision, then another little piece of the service, then a customer decision, etc.

      One could create text that describes these instead, but the nesting of the outline soon becomes intolerably complex compared to the workflow diagram. And all the “if … then …” repetitions are mentally dulling to the point that you stop seeing mistakes.

      One midway point I have used is to take the words out of the workflow diagram and simply put a number in each item in the workflow diagram. I then associate text with each of the numbers, like a key. That way, I can use appropriate language of obligation or discretion, and identify the actual actor as the subject of the sentence.

      The image in Hank’s article (which D.C. references — hi, Hank) is a little like this, except that
      (a) the actual structure of the diagram is circular, rather than linear or branching (circular processes are highly difficult to represent no matter what),
      (b) he deviates from what I think standard workflow diagrams use (circles as both entities and processes and lots of arrow heads on connectors — not sure if these are meaningful), and
      (c) he has put words and numbers where I would use numbers alone.

      For lawyers interested in using workflow diagrams, I would recommend that you get a copy of Microsoft Visio and play around with the “Cross Functional Flowchart” template, using the shapes for what they purport to be used for. There’s actually a whole pile of learning there.


  3. I don’t recall ever seeing a diagram used in a contract. If it was, a court trying to interpret it would almost certainly end up first reducing it to words in any case, so perhaps one is better off writing the words that you want in the first place.

    I see diagrams commonly used to illustrate corporate structures, where they convey simple structural information far more quickly and clearly than words can. I also see them in fund prospectuses in some cases, showing fund performance and (again) corporate structures. Prospectuses are basically contractual documents, albeit the diagrams are representations where the standard is that they need to be reasonably clear and not misleading (essentially to avoid misrep), rather than deal terms. Diagrams don’t seem to work that well on precision and detail, which is perhaps why they don’t get into the contracts much.

    I think you have posted on equations before (which is perhaps not quite the same, but similar in that it uses a different language). I like them because I think they convey information for formulas much more precisely than words do, as well as more concisely, but not everyone is as familiar with mathematical conventions as you might expect – and you do need to be, to be clear what an equation means and to write one unambigiously. It isn’t hard for someone to write 2 + 3 x 4 thinking the answer will be 20 (when conventionally it would be 14).

  4. My friend and former law-firm colleague Hank Jones published an article some years ago about using flow diagrams in contracts:

  5. One that comes to mind is a trademark license agreement, which often has the artwork of the mark(s) in an appendix and may also have illustrations of how the mark may or may not be applied to products and packaging. 

  6. GANTT charts are often used in the work schedules of R&D services agreements, particularly in the biotech sector.  I use mathematical formulae in payment provisions, eg in royalty calculations.  Images of trade marks and designs are used in licence agreements. Very occasionally, flow charts might be used to illustrate processes, eg a QA approval process for accepting delivered products.  I have seen organisational diagrams used in business documenation, eg to show group company structures, but not much in contracts.

    Visualisations are only used occasionally in business contracts, as contracts are mostly based on words, not pictures.

    At the other end of the spectrum I have seen extreme examples of non-visualisation, eg a tax lawyer’s opinion (costing the client a six figure sum) that didn’t use headings or even numerals, but instead numbered paragraphs by using introductory words such as “twenty-sixthly”.

  7. Ken, I only just spotted this blog.

    The answer is yes. In fact, the topic was a significnat stream at our recent IACCM Amercas conference, where we had several academics outlining work in this field. There is significant drive and sponsorship for such initiatives within the EU, because of the belief that this can reduce risk through increased understanding. At its core is a concern that growing contract complexity, coupled with increased cross-cultural trade, is rendering traditional contracts a source of risk, because many of their users cannot understand them.


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.