Law firms, before you build legal tech: stop, breathe, and design
More and more large law firms are building their own software these days. These typically come in two flavors — products for internal use and products that are client-facing.
The development of products for internal use has been happening for a while, but with more and more off-the-shelf solutions in legal tech to meet those needs, this trend is on the decline, and for good reason. Building and maintaining enterprise software is hard work, and when there are suitable off-the-shelf options, that should clearly be the first choice.
At the same time, based on the inquiries that come through our office, the development of products that are client-facing appear to be on the rise as law firms are looking for new ways to generate revenue, increase client loyalty, and develop new pipelines of work.
For those firms, I offer some advice. There is a wrong way to build software. There are multiple right ways to build software. None of right ways, however, involve skipping design, testing, validation, and iteration. Many firms seem to be going down the path of building software the wrong way.
Why We Build
Let’s consider the goals law firms have in building client-facing software, which I’ve outlined above. You meet those goals by creating digital products that signal to clients and potential clients some or all of the following:
That your firm cares about providing value
That your firm is a subject matter expert in a particular area
That clients and prospects should trust your firm and come to you when they need help
That your firm cares about the success of its clients
Despite the need for careful construction to communicate one or more of these messages, here’s how many of these products tend to be built:
Partner A, Head of X Practice Group, has a brilliant idea for an app, and goes to his firm’s IT group to ask them to build it. The firm’s IT team has a few developers that can build products, but they have a large backlog of other projects from the heads of A, B, and C Practice Groups. There may be some internal discussion at the Partner level to make the case that these various products should be built. Once they are in the pipeline, they are churned out by a few time-strapped engineers. A designer never even touches them.
The product rolls out, press releases go out, awards roll in, but the client never uses it and the firm’s goals for the product are never met.Sound familiar?
This approach is fine if your goal is “innovation marketing,” but it’s not a useful approach if you intend to actually advance both current and prospective client relationships.
I have two main points of advice for firms that are moving towards building client-facing digital products:
Validate the product’s value first, and
Hire a designer.
To the first point, I’m assuming that your firm does not have an unlimited technology budget to hire multiple fully staffed teams of developers and designers, but it has plenty of partners who want things built. There’s one really excellent method of deciding what products to prioritize and which ones to push back on: validation testing.
In validation testing, we create a prototype of the product, document our assumptions around the value that this product would create for the intended users, and then go out and test those assumptions directly with clients using the prototype.
What this process allows us to do is to understand from clients whether a product is valuable to them, how it fits into their existing workflow, whether and how it changes their perception of the value that a firm offers them, etc. Doing this early in the process helps to understand if you’re on the right track, if you need to do some course correction, or if an idea needs to be scrapped altogether. This can provide added leverage to convince an executive team to either execute or forego an opportunity.
Tied in heavily with validation testing is the need for a designer to be involved. Your firm may not be able to hire one full-time, but if you can bring someone on as-needed, don’t skip this step. You need someone on the team not only bringing attractive visual design into the process, but also someone who is skilled at understanding how people use technology to put together the architecture and user flow of even a simple product and test for usability. These two functions of a designer are a critical component for a successful product, and are also the most regularly overlooked.
It’s very easy to spot the products that had no design intervention. The beauty of design is that it allows us to present or gather information in ways that are enjoyable and easy. If your firm has an app that includes a bunch of radio buttons on a page, it’s a pretty good tell that it wasn’t actually designed. Below you’ll see my amazing sketch that reflects this common form of law firm web application.
Sure, this product provides a service, but it provides it in an entirely lackluster manner that neither encourages the user to put in the effort to use the product, nor reflects well on the firm’s brand.
I can’t say this enough — when developing products that need to reflect well on your brand, more is not better. Better is better.
Slow down, validate, prioritize, and design. Your product will be much more likely to be successful at meeting your firm’s goals than if you continue to churn out product after product to satisfy partner whims.
About the Author Nicole Bradick is the Founder and Chief Executive Officer at Theory and Principle, a legal technology product design and development firm. Nicole and her team work with global law firms, foundations, and legal technology companies to build innovative digital products related to law and justice. They are on a mission to bring smart design and seamless digital experiences to the legal industry.