Summary
Aimed to work on a digital production tool for legal consultants to ease and create a more efficient process in building designs and visual language, the project led to learning various coding languages to build a viable product. Designers do not need to silo themselves into one creative role, but with the right support and drive to learn, can solve problems for multiple team members and fellow colleagues.
Problem
Consultants navigate through a dense environment of data. Whether it’s a patent infringement case or a contract dispute, corporate litigation has a near incomprehensible list of files and documents in reference to a case. Parallel those obstacles with multiple case loads and collaborative environments dependent on other team projects, deadlines exponentially shorten. Many legal consultants, depending on experience, are not well-versed in a case initially and require expert witnesses to provide explanation. This in turn requires constant iteration of visuals and infographics to accurately portray the technology. Despite these hurdles, the tools are inefficient in resolving the design problems that come up in the process.
Identify the Design Language
Despite the hurdles, there appeared a visual language that consultants used to communicate. There were discussions over titles, captions, footers etc. But one core visual element were visual units defined as Callouts, where consultants take an image of a disputed language in a contract or reference and showcase that terminology to help build their case. This becomes a core aspect of the consultant’s visual design language as well as an opportunity to create a more efficient workflow.
The following is a general outline of the workflow to create Callouts and a diagram describing the basic layering required for production:
Fairly simple for any designer to create. However, in conjunction with multiple outlines and interactions, one callout easily turns into thousands. Rather than just defining the design language, if we can define and create a unit for production that will greatly reduce the strain on workflow.
The following is the proposed workflow:
Workflow in conjunction with user screens
The How
The process of coding this tool required a series of translations from different coding languages to enable a workable product. Initially, the tool was coded in VBA, a simple programming language, but would require users to share the file to enable the tool. The tool was then translated into C#, the app coding platform for Microsoft Office Core that would enable an install file for users to refer to the tool within their toolbar. Certain tools were already installed in the pre-existing toolbar, so integration required that new code exist harmoniously with other functions.
A Deeper Dive
into Users
After 3-4 months of usage, we were able to find that those that used the product in their daily work had certain shared traits as well as those that did not adopt the program. Across the board, young users under the age of 35 found this tool to be essential in their process. Between 35-50, a small percentage of users did not adopt the program. Above the age of 50, little to no users adopted the tool.
This tool was adopted in similar trends as to what you would find in most technological adoptees. Generally younger, tech-savvy users were the most eager to use new programs and older, less tech-savvy users, felt little need to adopt new processes.
When new designs and technologies are developed, it is important to note that they will generally serve a younger community where most of their issues are derived from technological errors where they do not have the benefits of experience. These tools should not be presented as a general prescription but a method of assisting new consultants.
