Learn how to build legal apps for pro se litigantsFree consultation
Interview of Jack Madans
Jack Madans is the Digital Service Principal at the Judicial Council of California. Founding team member at globally-recognized civic innovation non-profit Code for America.
Judicial Council of California
It's rare to find a court system that isn't struggling to serve pro se litigants (individuals who arrive in court without a lawyer). In California, one of the ways the court system is trying to meet this challenge is with better self-help technology; specifically, document assembly apps.
Developing technology for pro se litigants is a unique experience in many ways, but product design & development best practices still hold true. In this interview, Jack Madans, Digital Service Principal at the JCC, describes how the JCC is using Afterpattern to implement many of these best practices, in particular rapid and inexpensive prototyping.
We created testable versions of guided interviews for a fraction of the time and cost. That's unheard of and gives us a lot of room to iterate.
April 2, 2020
You have a deep background in technology, including a tour of service with Code for America — When you joined the JCC, did you find the sort of product development culture you had been used to?
[laughs] — Yes. But only because I’m quite familiar with government.
When I started working with the Judicial Council I recognized many of the traits that keep governments from developing great product cultures: low tolerance for any sort of risk, waterfall development, not enough collaboration between policy and tech.
And the cure is the same: We need to change the way product decisions are made so they are more aligned with the end user. If government - or any organization, really - wants to build tech that’s useful for the public, they need to get out there and get a deep understanding of their users and being ready to fail before getting it right. And the only way government can get comfortable with failure is by reducing the cost of starting over. Which is why choosing tools that allow for lots of iteration - like Community.lawyer - is so valuable. It makes organizations way less scared of user feedback.
What does product development look like at the JCC?
Right now, I serve as the Digital Services Principal for the JCC. I help lead the digital transformation at the state court system. Our current project is focused on the most vulnerable users of courts.ca.gov: self-represented (or "pro se") litigants; people who typically can't afford lawyers.
A self-represented litigant doesn't have to just be their own lawyer, they have to be their own law firm.
We've put together a team of designers, technologists, and lawyers. We're focused on the question: how can we radically simplify the process of dealing with court without a lawyer?
We're answering this question with new approaches to the way we write and deliver procedure guidance to pro se litigants.
Right now, people will look for procedural guidance either in a self-help center in court or online. There is very little mixing of the two,
We have passionate, self-help attorneys who spend most of their day repeating the same instructions, over and over again, about how to fill in a form. Yet this is exactly what machines are particularly good at. Machines can repeat the same thing over and over again concisely and reliably 24 hours a day, 7 days a week. What machines are not good at is providing the reassurance, emotional support, or understanding that a person can.
It sounds like your goal at the JCC is to find those small opportunities where injecting technology will free up people to do the high-level work.
Exactly — We're asking: where can we use the logic and capability of the internet to radically increase the odds that a pro se litigant will get the process right.
Look — a self-represented litigant doesn't have to just be their own lawyer, they have to be their own law firm.
One of the biggest challenges self-represented litigants face is getting the help they need to complete the forms required to start and keep up with their court process. A legal app means that our help centers can effectively be open 24/7.
Before you started developing legal apps, were you certain it would be helpful? It sounds like a hypothesis that needs testing.
No, we were certain that legal could help because of the success that the California Court System has already had by providing document assembly and "legal apps" for self-represented litigants in family law cases. Over the past 30 years, our court system has finely tuned the self-help resources for family law cases.
The Chief Justice has challenged us to provide the same, and even improved, self-help resources for civil cases as it currently does for family law.
Is building legal apps just for large, well-funded court systems like that of California?
I think that every court needs to think about how they can help people with forms online. Because, while they might think it's an expensive investment, you have to account for the cost of that difficulty elsewhere.
We have to look holistically at where we're paying for these difficult forms.
How do you characterize the way the JCC is using Afterpattern?
Afterpattern is allowing us to prototype legal apps in a low-cost way.
The hardest part about product development, especially in government, is testing assumptions. The App Builder lets us test assumptions cheap. This is especially important when we're building legal apps for areas of law that haven't been touched by this kind of technology before.
If you were talking to someone who does not have a tech product background but is playing a role in a court system where they could be prototyping new solutions — where would you point them as a relatively easy place to get started?
Agile iteration, data-driven decision making, user centered design ... all that really just boils down to is one thing: take a little bit of time to build something small that will teach you a lot about what your users actually need.
Unfortunately, in government, we're used to working in a waterfall fashion where product requirements are defined by internal stakeholders. And then, on launch day, we realize that we missed something obvious that our users could have told us early on, but we don't have the space to change the contract at that late stage.
You can fail small, or you can fail big. Letting yourself fail small is the only way to succeed big.