Led and contributed to projects in delivery of a proof-of-concept for a Magic Circle firm based in Singapore. This particular project was born from the inception of the user need uncovered during user interviews, designed and developed collaboratively with a cross-functional team.
.svg){kind=small}
This requires them to read through and find the provision that has been modified, going down to the timeline history of the piece of law and compare the different versions. We set ourselves to think about how can we minimise the hassle and the fuss needed for this transitional check so that the lawyer can progress to referencing the work product. We drew out the flows and here are the initial steps that will lead them to check the legislations:
I start by identifying the key components and connections of the interface. Starting with a fat-marker approach, I tease out the key elements that are going to help indicate the "state" of a legislation section the user is looking out for:
By speaking to the users, we uncovered the statuses that the lawyer is trying to get an indication from: Superseded, Removed/Deleted, Amended. We then also looked at the legislative website to ensure that we are able to tap on this information.
By following the lawyer's experience, we'd have to create a new tab, go to the legislation website and then match the dates by going down the timeline history and create another new tab to see the latest positioning. We had to work out what's the greatest impact we can alleviate from this series of actions. We came up with a rough idea of connecting the user straight to view the provision that opens a new tab straight in the browser based on the date of the memo and, also offering a link to view the current version of the legislation.
By comparing date of when the memo was written and today's date, we can then establish what are the legislation sections that are outdated or still in force. This means that correctly identifying the dates are critical. We developed an extractor in our processing pipeline but we're also aware that there may be times where dates can be wrongly identified, or nothing could be found at all. We want to make sure this value can be easily edited by the user to tap on the value of this solution.
With a 6-week appetite, the workings behind this was kept deliberately lean. We devised a dictionary that contains the timeline and legislation sections are extracted when document is processed. This means that we can display the list of sections instantaneously with no wait.
Adequate priming is needed as user needed to absorb that the content was deduced from the main content. Hence, we designed a 'fake' loading state to mimic the analysis phase so the intent was carefully communicated without a heavy cognitive load at the start.
.jpg)
It is important that we test our connections to the legislative website thoroughly with the interface and the copywriting. "Memo version" was coined, but users were confused by what it means. We iterated and wanted to tie-in the date extracted earlier with this link so that the user understands the basis of what the status and links were calculated upon.
Working closely with data, legal engineering made this feature possible. We sat down with the current architecture and pipeline ideas in mind and worked out the data flow within the first week.
There were many ideas that could potentially complement our solution: higher accuracy on the extractors end, more legislation scoped, sorting the sections, indicating information about the section. The team scrutinised the scope every week to make sure that we are rigorously focused on our baseline scenarios.
