How can document management support lawyers working in a practice centric manner? That is the question my business partner Joshua Fireman of Fireman & Company will answer. This is a live blog post from NetDocuments‘ ndElevate annual user conference. (As with all my live blog posts, please forgive any typos or misunderstandings of meaning.)
Practice-Centric Design. Practice-centric design starts with understanding lawyers’ requirements. And requirements are not always what lawyers say they want. It’s important to over-design – that helps increase adoption. The design must meet practice requirements.
Matter-Centricity: The Original Sin. Matter centricity came from wanting to give lawyers something that felt more like Windows file explorer and Outlook. It was based on mistaken beliefs about how lawyers want to work. Lawyers need working files – they don’t need the digital equivalent of old-fashioned master files, which is what matter-centricity yielded.
Matter centricity also tried to anticipate everything that might happen on a matter. It built a superstructure that often was far more than needed. Furthermore, it assumed a form of synchronous collaboration that does not apply to how lawyers really work, which is more linear.
Understand Requirements: Art + Science. To collect information systematically, you have to segment law firms by the right segments: practice, role, and geography, for example. Each segment has a different set of needs and requirements. Also, don’t ask about specific features. It’s much more important to understand how lawyers work and what they need and want to do. That information will drive the features required. There is also an art: you have to listen and interpret what users say. Find out how lawyers work a matter, how they interact with clients, and how they use (or don’t) the current system. One way to represent requirements is using a mind map:
Simplicity Does Not Mean Utility. Its better to have content in a system, in consistent organization. This requires moving barriers to saving documents. A base requirement is to easily save and find a document. We can’t predict how a matter will evolve and what folder structure they will need. And they won’t to be told how to manage matters. “Let the lawyers respond to the needs of the matter.” It should be easy for lawyers and other on a team to group documents in logical folders. They should be able to drage from document folder to a folder of their own creation. In some systems, moving a document to a folder actually moves the document. In NetDocuments, that dragging operation does not change the document location.
Having a working file is critical. That means having access to your own documents the way you want, without cluttering everyone else’s view of the shared document space. In NetDocuments, users can create a working file that shows exactly what they want. Those docs are still in NetDocuments; in the personal folder though, one lawyers’ selection is purely personal – it does not force that view onto the rest of the team. This type of personal folder – which “gets the system out of the way” – makes it easier for lawyers to work.
If we make it easier for lawyers to work how they want, the are much less likely to save outside of the DM and then at end, move a subset of docs to it. With personalization and flexibility, docs start in the DM but allow personal views.
“The Closer. Creating a closing binder is a high risk activity for associates and others. A closing is a chaotic process, often late at night. Many things change, many things can go wrong. It’s easy to lose track of what version of the document is the right one. With the ability to create your own folders, lawyers can set up, in advance of the closing, a closing set of folders to use in the closing. In this example, folder names reflect the names of the pre-agreed upon closing index:
The same logic for closing binders applies to trial binders.
Flexibility Meeting Policy Requirements. The goal is to go from beginning of work to end, systematically, making it easy for lawyers to do their work, share, and organize. With this approach, avoid classic problems, for example, regular failure to save first drafts into the DM. Joshua tells story of a client where a lawyer ignored firm policy because that policy did not reflect how she worked. The save all drafts policy is more important for transactions than for litigators. Litigators may be embarrassed by sharing their first draft with inchoate ideas. The solution here is a more flexible policy, which might say the first draft does not have to be public to the firm (or even the matter). The key goal is to get all docs into the DM from the outset. (One can even set up policy and rules that allow a litigator to keep the first and second drafts private, but subsequent ones must be public.)
Patiently Focus on Adoption. It’s important to start with metrics. Without metrics, you cannot measure adoption (and changes in it). “Build a Luddite Scale(TM)”: group users by skill and address training in doses required to meet differing needs. Don’t necessarily train or aim for adoption of all features right away… set realistic timetable over time.