ARTIFICIAL LABS
Context
Artificial Labs is a tech company that facilitates the daily work of brokers and underwriters in the Lloyd's of London Insurance Market by providing SaaS products that help them automate repetitive processes, digitalize manual tasks, scrap data from documents and make better decisions thanks to it.
My work
As a product designer at Artificial Labs, I had the privilege of contributing to groundbreaking projects that redefine the intersection of insurance and technology. Our team's relentless pursuit of excellence has not only earned accolades within the industry but has also positioned Artificial Labs as a leader in harnessing the power of artificial intelligence, data analytics, and user-centric design to create solutions that transcend conventional boundaries.
I joined the design team in March 2022 until October 2023. During those 18 months I got to curate some pre-existing products, improve their user experience and interface, break down all my designs into phases and specifications for the dev team and proceed with iterations when needed, create new components and keep the design system updated, play with variables, propose and design whole new features, do research and create from scratch the name and bran identity of their virtual assistant as well as define and design all its functionalities, user journeys, wireframes, prototypes...etc. These were only some examples.
The project
Due to the fact that a big part of my work hasn't been developed or released yet it stays confidential so I can only publicly share a little bit of a project I participated in which is the MRC Builder. An MRC is a type of official document in the insurance field that brokers use to organize and structure data from a client who wants to get something insured so they can present this file to an underwriter and see if this one is interested in signing (covering) the risk. There are some complexities to it.
Note the content in the following link is CONFIDENTIAL and exclusive for non-competitors which means non Insurance related companies. After clicking in the link I will get an email and decide if it's safe to share the folder or not. The content is for private view. It is absolutely forbidden to download, screenshot, copy or distribute in any kind or form any of the screens that are in the folder.
Objectives
My job was to do research on how brokers collect the data, what type of files they tend to receive, what are the most common words used for referring to the same concept so we could develop an e-learning tool, how to prevent and solve issue regarding data scrapping (specially from scanned pictures or documents with poor quality), maximize the amount of successful matches between the uploaded data and the scrapped data, create a template following the new rules imposed by Lloyd's of London and the same time leaving enough room to create exceptional blocks of informations, edit text, add links, create repositories for highly used components and also be able to collaborate between colleagues on the same file.
Challenges
There were quite a lot of journeys to follow and all of them pretty complex to solve from a usability and a technical point of view. Here are some of the main challenges I found:
Data scrapping process
Note that brokers would receive the client's information in many different formats, some physical (papers, pictures or scans of papers, hand writing) and some digital (plain text in an email or word, PDF, excel). They could also chose to fill in a form manually. All these data must be processed and matched with the information that was being "looked for" (as per pre-configured). Some times images would have a poor quality, others the word used to refer to a data point might be correct but not the one registered (e.g.: inception date and start date), others there would be a massive excel but only some of the information might be required and the user would have to confirm the exact columns, rows and cells that are useful and others there would be clauses that match on a % with the registered clause in the library but have some differences so we need to identify them.
Roles, permits and structure
Trying to create a semi-customizable template with permits so only the admin could change anything anywhere but not the regular brokers led to a bunch of discussions on "what was worth of allowing changing and what was not". Also there was a new structure to follow for the MRC that was going to be implemented soon across all companies with the intention to estandarise these documents and make things easier for everyone. This was tricky because we needed to make sure we were applying the instructions properly.
Editing the document
Inline, floating component, full screen modal, google doc style, notion style? do we allow cursive? and bold? changing size and color in general? A sea of options, styles and functionalities that needed to be discussed and agreed on specially with the dev team since there were some limitations and complexities.
Data points
One of those complexities was the fact that among the document some data points would repeat. These data points would have a value (e.g.: inception date = 1 Feb 2024). So if the original value was changed it would apply everywhere it appears (pretty handy). But then we needed to think how to edit the value, add or remove data points among plain text. Also we would need to indicate if a data point was filled in or pending to fill it in and if the value was correct or not.
Real size in real time
Apparently for brokers it was highly important knowing that whatever they were seeing while editing, it was going to look exactly the same when exporting to PDF and sending it. From a phrase in a page to the next one, a coma, a title more up or down, these details were relevant. That's why options like inline editing didn't work for us because they would "alter" the length of the text and so it would distort how the file would really look like in the end.
Color codes and symbols
Considering a document could be edited by several colleagues, there was a side bar with a section for comments, versions and activity. There was also a notifications component and a toggle to see or hide the color markers that indicate things like: data point filled in correctly (green and check), data point filled in correctly and locked value (grey and lock), data point filled in incorrectly (red and alert), data point pending to be filled in (orange and info), comment (blue and chat bubble)...etc. The tricky thing was trying to keep it nice and neat so it doesn't look like a party and also make it accessible for color blind people.
Proposal
