Shaz Aziz, Director of Client Solutions and Engagement at Neota Logic
We all know the theory of agile project development. Break the project down into manageable chunks. Get a working prototype out quickly. Make continuous improvements based on how the users react rather than what committees write on Post-it notes.
But in the legal world, putting agile into practice is not always easy. Lawyers are understandably wary of pushing out incomplete products, even as a starting point for iterative development. All their professional training is about managing risk and thinking of contingencies – dotting the ‘i’s and crossing the ‘t’s. By the time they have had their input, what should have been the prototype of a minimum viable product may look very much like a final product, with all the bells and whistles.
Which is bad news if the product turns out to be addressing the wrong problem, or the right problem in the wrong way.
This is just one of the factors behind the legal sector’s struggle to keep up with most others in digital-based innovation. Bluntly, while legal departments have plenty of bright ideas, few have a clear system for building prototypes.
Technological innovation can help, but perhaps not in the way you might think.
At Neota Logic, we have shown that users of tools such as Canvas, our rapid application builder, can learn to build prototypes of apps in a lunch break. But just because this stage has become quick and intuitive doesn’t mean we should skimp on the overall process. Rather, we would do better to take advantage of the technology to put more of the right kind of thinking into the preliminary design process. That means getting the right people together, – and ensuring they start from the right point.
Let’s start with the people. Say we want to build a tool to determine whether a process or product is GDPR-compliant. At the outset, we should draw champions from across the business, from legal, to operations, IT, design and others. Apart from anything else, this will help the business case: finding budget for a solution which crosses over from legal to, say, procurement, will multiply the benefits while sharing the cost.
Then we need to think about the problem to be tackled – making sure it is the right one from the dozens which might emerge from an ideation process. What is it costing us in money or opportunity? It may sound obvious, but unless this is nailed down, then all work on the prototype could be wasted.
The way we approach this is legal design thinking. We need to:
- assume that we don’t know anything. That includes what the problem we’re trying to solve is, and the solution to that problem;
- drill down into and validate the need. It is easy to make the mistake of accidentally solving a “downstream” problem – where a solution at a different stage of a business process may have been more effective and alleviated pain points for more people.
- trust the process.
We should not confuse the process of evaluating an idea with ‘blue sky’ thinking. Legal design thinking is about thinking without barriers, but it is also rooted in the reality of choosing, having to prune the peripheral branches of an idea. Hence the need for a diverse team (with legal and technical expertise), and the focus on the minimum viable product: the smallest thing we can build that satisfies our goal, audience and output – and only those three things.
Once we have buy-in for the minimum viable product, now is the time to build the prototype. It may have taken longer than cobbling something together at the initial project meeting, but the approach will save money in the long term. Everyone who has assembled flat-pack furniture knows the importance of reading the instructions before attacking the ‘apparently’ obvious…
With prototyping, the main pitfall is the “building a spaceship” problem: biting off more than we can chew. So, let’s remember the key points:
1: Don’t get distracted. Shiny object syndrome affects us all.
2: Don’t focus on needs in favour of wants. Answer the three central questions (what is the goal? Who is the audience? What is the desired outcome?).
3: Don’t assume that good is the enemy of the perfect. Even the first version of your solution might be more efficient than the existing process.
We have the tools. Build, get it out there, and iterate. But do the groundwork first.