Legal Operations are all about proactive management of everything in the legal services that is not directly practice of law.
As with any big systemic change, it needs design to best serve its users – which is where legal design can be quite useful.
The good news is that you can start small – there are a few tools in the design toolbox that legal ops professionals may find useful.
In this article, I will cover five (5) basic (legal) design concepts that every legal ops professional should know.
#1 Understand your starting point
This can never be emphasized enough: it is really essential that you know what is your starting point.
In design and in legal operations, it is important to study the context, the current state, and the metrics before you start changing anything. Learn how the institution works in the first place, especially where the resources go.
Only then you can formulate your task and its scope, and above all else, define and measure its benefit.
Read about this in detail: Do this before you start innovating.
#2 Humanise Your User
The design of legal operations should primarily be centered around the core business functions. To better understand and serve your users, borrow the trick from UX designers and create user personas and map out their client journey. Think of Brenda from Business or Mike from Marketing.
What are their motivations, what do they need to do their job? What is their definition of success? What language do they communicate in – is it stories? Or cold hard numbers? How do they consume information?
A good starting point is the following sentence: [Person or group] needs to [need] because [insight]. (zdroj)
Think of both your users (e.g. the head of a business unit that wants a clear, bump-free contractual process) as well as your end users (the humans who will actually have to interact with your solution on a regular basis). Both of these angles are important and valuable.
Think of them as real people, with all the imperfections and hard realities of everyday work.
#3 Define your challenge and definition of “done”
Once you have done the first two – you now understand the players, the playing field, and all the data you could get – it is time to define your challenge.
There are two designer-y sentences that can help you along the way in defining your challenge.
The first is How might we… statements. How might we capture internal knowledge to allow for its effective use? How might we simplify the negotiation process for our salespeople?
The second is to look at it from a perspective of an experience, which can be a little bit more specific: Redesign [activity] experience for [user] using [tool]. Don’t forget to check in with your user persona.
Your definition of the challenge should also come with a definition of done. Set yourself a SMART (Specific Measurable Achievable Relevant Time-Specific) goal.
The definition of done is the end goal. It can be to reduce time spent searching for know-how in emails by 80% by the end of Q3 2023. The definition of done is not the solution itself (installing a know-how management system).
#4 Embrace prototyping and iterating
Here is where your bias for action should come into place. Once you have interrogated the situation, and defined your challenge, probably a few solutions come into mind.
Now instead of pondering it forever, or recklessly purchasing the shiniest tech, I would like to encourage you to find the cheapest possible way how you can validate your idea that will require the least effort to build and test.
If you want to develop a comprehensive negotiation playbook, do a clause or two, save it somewhere, and then track how many times it gets open. Ask people what clauses are they looking for the most. Only then spend the time putting the rest of the playbook together.
If you are looking for a contract management platform, try a couple of demos and free trials. Map your contracting process and do some wireframes, and consult them with your users. Once you have prototyped your way into really understanding what the users are really after (not what they necessarily say that they are after), go ahead and start your procurement process with plan and intention.
#5 Get feedback
Getting feedback should always be an inherent part of your design process.
Show your work to your colleagues from different departments. Ask them what they think. Watch them interact with your prototype. Would they use that? Is it reacting to the most pressing issues they have with your unit? Is it frustrating to use?
Try to gather as much feedback as possible from all ranks of the company. Again, your users and end users may have different outlooks.
Make sure to listen to everybody. Then take your time to be very intentional in reflecting on what you found out and how/if it can be incorporated for the benefit of the whole system.
Final Clauses
Design is a powerful mindset combined with sound processes that should be at the heart of any transformation, including building any legal operations function.
At the end of the day, you need to make sure that your core business – the reason why they have lawyers in the building in the first place – is flourishing. So being very intentional about what that exactly means, and remembering your users while creating it, can have a massive effect.
What about you? Would you add anything else to this list? How else can legal ops enrich design and the other way around?
Baru
