by Ron Dolin, reposted from his site Radical Concepts
I co-ran a design workshop last week focusing on navigating the Canadian patent system. It took place in Toronto, sponsored by Giuseppina D’Agostino at Osgoode Law School at York University. The organization and prep had mainly been worked out with Michelle Li of Osgoode and Margaret Hagan of Stanford (Fellow from the d.school and the law school’s Center on the Legal Profession). Margaret had to cancel last minute, but brought in Maya Shino (Stanford LLM), currently with eBay legal. Their excellent prep work made my job much easier. I think it’s safe to say that everyone involved walked away feeling that we had far exceeded expectations.
In terms of prep, we brought in inventors, patent agents, examiners, and other stakeholders, and then formed interdisciplinary teams. The goal was specifically not to address the substantive law. Changes in substantive law not only are difficult to achieve, but also are usually simply unnecessary. As is common in design, we look at how we can make the legal system more “user friendly”: approachable, understandable, transparent, efficient, and navigable. We also look at how we can design something that we can implement in the real world. Thus, we tend to approach the legal system from the perspective of a user trying to meet a need. Our work has included estate planning, immigration, plea bargaining, general court access, and any number of other legal tasks (for an overview of the range and outcomes of prior design workshops led by Margaret, check out legaltechdesign.com).
After discussing problems experienced by one inventor, one team told me that they had to make changes to the patent system. I asked them to give me more details. They said that the inventor was frustrated by how many years the process took. The day before, however, I’d heard a patent examiner discussing over lunch how most of the time required for patent prosecution was not caused by the patent office, which would generally turn around feedback within a few weeks. The issue of end-user frustration and a feeling of lack of control resonated with me, as I’d heard similar stories regarding the visa application process.
When I asked a few questions of the group, in terms of identifying the root causes of the inventor’s frustration, we agreed that a lot of it had to do with his not knowing what was happening or how to push the process forward. This is a problem of transparency and notification — there is no statute that requires that the process be slow and obfuscated. It would be difficult to assign the root cause of a slowdown without first knowing who was waiting on what document, for example. We agreed that we could help resolve the inventor’s frustration by better informing him about the process and what steps had occurred, and what steps were pending. I then discussed various “roadmap” design elements, such as the use of a labeled process map that we developed for immigration applications. In that case, though, an application might involve several paths simultaneously, while for a patent application, there’s more of a linear path. The group decided that something like a linear Gantt chart, with various links and associated notifications, would solve the inventor’s problems and empower him to follow and influence the process. Hence they came up with a “Patent Tracker” design:
Each of the four groups came up with a straightforward yet elegant solution to the problems they uncovered through interviewing various inventors. While the example above was for helping with a more experienced inventor, some of the groups found that less experienced inventors didn’t understand IP protection very well and needed much more of an introduction to IP. One group’s solution was a tab-based overview web site that provided an introduction to the various types of protection (copyright, trade marks, patents, trade secrets, etc.) and which one might apply to what types of IP. That group got stuck in trying to get an inventor to walk through the introductory material before jumping ahead to how to file a patent. The trick was how to accommodate various backgrounds and encourage a walk-through while allowing for a discovery-based exploration of IP protection:
Another team, also dealing with the more novice inventor, came up with a 5-minute video explaining what types of inventions are patentable. I encourage readers to view it because, mainly, it’s just really fun to watch. But the point is that it’s very simple and solves the problem. The team’s goal was to produce several of these videos and then just monitor feedback and likes to see where more might be helpful.
There are several lessons from this workshop, similar to what we see from other design workshops. First, it’s crucial to get the main stakeholders working together in a design process and to speak directly with users of the system. The patent examiners on the teams lent invaluable expertise, but they also had not generally worked directly with inventors to understand their frustrations and needs. One examiner said that the Canadian patent office’s new website was worse than the prior version and that she herself couldn’t find information on it. All of them said that they could do much more to help inventors with the designs coming out of this process and wanted to encourage the patent office to work more closely with inventors in designing their information systems.
Second, these designs came out of just two days of structured design work. It’s notable (and usual), that the differences in designs between the first and second day were extreme. This growth is also normal for the interview process. After one or two tries, it just clicks for people. The teams become unified, they focus on user needs, they understand how to test a design, revamp it, polish it, and come up with something that solves a problem. Here, though, I want to highlight the difference between general unstructured brainstorming and structured design work. I had presented at two conferences just prior to this workshop: COLPM’s Futures Conference and Thomson Reuters’ Financial Metrics Forum. In both cases, I’d run and/or participated in short working group sessions. And while they had been interesting and worthwhile, they did not yield the same feasible, tangible work product that I saw from the structured design process. Of course one might expect more from two days than from two hours, but I find that the learning curve for the participants is much faster when there is enough structure to help get participants to ideas that are both outside-the-bar creative and also feasible.
Third, it can be a challenge to get people to think outside their current experience. For example, we heard from a seasoned corporate immigration attorney in one workshop say that after 17 years, he continually told employees that there was little he could do to help them with the process. However, after spending a couple of days in the design workshop, he said that he now could think of hundreds of things he could do to help. This is no more true there than it was for the participants at our patent workshop. I saw one team struggle the first day to bring ideas forward. They had become so attuned to the current processes that they were simply hesitant to throw out crazy ideas. But it is exactly that full range of crazy that ultimately lets them find a couple of ideas that really help people with their problems and are, in fact, quite feasible. I remember just coaching them, encouraging them by explaining the “yes and” philosophy — your idea is actually great, and, in fact, if we added this or that to it, you can see how far it can go to solving the problem. Slowly, smiles emerge, creative confidence emerges, and the team is off and running.
In the end, a common d.school debriefing is to ask participants to share any “I liked, I wish” feedback. I was surprised that more than half the participants had something to say, and that it was overwhelmingly positive. The most common “I wish” was to have more design workshops. The patent examiners expressed a desire to run some at the patent office. Maya and I had not previously worked together, and I was also surprised at how smoothly it went and how much of a team we were able to form so quickly. Overall, this experience strongly reinforces my belief that as we work toward making the legal system more usable and user-friendly and as we move toward putting an increasing number of legal functions online, we stand to vastly improve the experience of all stakeholders. The use of technology in implementing the legal system forces us to compare new systems with old systems, which forces us to evaluate how things went on before. For most users of the legal system, I don’t think they’re surprised to find that we can do much better than we’ve been doing. By focusing on the user’s needs, we inevitably figure out how to solve them.
