Portfolio

Origin Markets – Legal user friction

Role:
Lead Product Designer

Client:
Origin Markets

Background
Origin Markets is an issuance platform focused on digitising the global debt capital markets handling the entire life cycle of an issuance from pricing of bonds up to generating trade documentation and listing. 

Design Goals

To reduce the friction of adoption from our legal users who are responsible for preparing documents on Origin.

Current Landscape

The problem stemmed from feedback from our dealer users as well as legal counsel where the flow of preparing a document felt clunky. This came to the point where legal counsel were hesitant to adopt our platform as a way to prepare documents often downloading from Origin, editing on word then re-uploading the changes to the platform essentially doubling the work that they do. This is detrimental to our product adoption as they often provide feedback to our issuer and dealer users that preparing on Origin takes longer and is effectively more expensive. With Origin the idea was that the documents being templates would be prepared correctly prior to using it on the platform but in reality many changes in language often happens during the trade especially for non-standard complicated financial instruments.

Target User Personas

Dealer

Goals and responsibilities:

  • Maintain clear communication with issuers and legal counsel regarding documentation requirements and issues.
  • Reviewing and providing input on term sheets and offering memoranda.
  • Coordinating with internal teams to gather necessary information for document preparation.
  • Ensure accurate and compliant preparation of all trade-related documents.
  • Facilitate a seamless documentation process to expedite trade execution.

Pain Points:

  • Coordinating inputs and approvals from various internal and external stakeholders.
  • Relevant parties are not notified in a timely manner when required to action on the documents, often needing to email them separately.
  • Being the sole penholder at the beginning of the trade, they have no leniency of being away from their desk.

Issuer

Goals and responsibilities:

  • Ensure documents have been prepared correctly and contain the correct terms of the trade ready for mandate.
  • During the final terms stage, ensure that documents are passed through internal legal teams to ensure the correct and most up to date language is used.
  • Reduce administration costs of whilst making sure documents are still compliant is the main goal

Pain Points:

  • Relying on the dealer team to make all changes necessary on the initial term sheet stages even for small changes makes it a time consuming process. Used to using word documents where if changes are required they can make it themselves and notify the dealer.
  • Passing the document around to their internal team for review and managing who needs approval prior to proceeding with the trade.
  • Growing cost of legal teams in reviewing trade documents.

Legal Counsel

Goals and responsibilities:

  • Ensure all legal documents related to debt issuance are thorough, accurate, and compliant.
  • Facilitate effective communication and coordination between the issuer and dealers during the documentation process.
  • Protect the issuer from potential legal risks through meticulous document preparation.
  • Stay updated on legal and regulatory changes impacting documentation.

Pain Points:

  • Managing the complexity and volume of documentation within tight deadlines.
  • Ensuring all documents comply with current legal and regulatory standards.
  • Coordinating and consolidating input from multiple parties to finalise documents.
  • Balancing thorough legal review with the need for expedient document preparation

What we know

From various post trade debrief calls with our users we arrived at a few key takeaways that all play a part in the collaboration process:

  • Penholder concept:
    Due to the fixed nature of our templates we allow only one editor at any one time who we classify as the penholder. The issue with this is that our users are well aware of and often use collaborative tools like google docs which are true real time collaboration. While having a single editor isn’t an issue as our users often leave the editing of documents to one person or team, the concept of penholder is not clear. Further to that, due to an assumption that the dealer is responsible for the document until post trade, swapping of pens is only available at the post trade stage of document generation where our users just want to take the pen themselves and edit minor parts of the document.
  • Reviews:
    The format of the workflow was fixed to Document preparation > reviews > share with issuer > mandate > trade completion. This meant that the assumption is that the preparation of the document and reviews is done internally for the dealer then when the document is ready for mandate it is sent to the Issuer. Once a review is done by one person, they cannot be requested for a review again. In reality our users work in a more fluid way than this with many back and forth communication internally as well as with the issuer and reviews to be done multiple times. Further to this the way reviews are shown on the timeline makes it seem that pending reviews means the trade cannot progress, even when the tree does progress the pending reviews remain in view making it seem like the documents were never reviewed. Another common feedback we received was around the drafting parties not being sure when a user has completed the review. We currently have a “Mark review as compeleted” action however because of the way we have set up commenting to be real time as opposed to changes, users will receive comments or suggestions as they are posted so at times someone will write a comment and continue reviewing , the editor will see the comment, make the change and resolve the comment but with no indication of the actions the initial commenter thinks they have lost their comment.
  • Notifications:
    With many of our earlier clients having strong security requirements regarding communication and actions on the platform, the notification system was built accordingly sending an email notification for every action done as well as when action is required. This meant that users were receiving about 50 separate emails per trade. Not only is the volume too high that our clients were complaining but they were unsure of when an email is actually valuable often missing notification to perform actions on the platform. According to our email open rate there is a <10% open rate often at the beginning stages of the trade which seems to mean users often open the first few realising the information is not important so they assume following emails are the same.

Penholder concept

Potential solutions:

  • Clarify the idea of a single editor
  • Open up editing to everyone on all stages

Rebuilding the document generator to be a real time collaborative workflow isn’t a viable option so the main goal of this redesign is to clarify the workflow of a single editor as well as expand the feature to the term sheet stages. When it came to the initial designs, it revolved mainly around the language used. The product team initially thought the term Penholder wasn’t a universally used term so a couple of options were shown to our users for example using the term of lead editor but there was pushback from our users who actually understand and often refer to editing as taking the pen confirming that the confusion mainly comes from the consequences of taking the pen which is that there is only a single holder and that taking will strip the current penholder of unsaved changes. This brought on a second aspect of the designs which was to address just that with a warning when the current penholder has unsaved changes.

Timeline page changes:

Document page changes:

Overall the final design was adding indicators for the penholder, adding warnings of the consequences of taking the pen being potentially destructive and supporting changes to ensure taking the pen was available at the Termsheet stages.

Reviews

Potential solutions:

  • Allow reviews to be done at any time and multiple times
  • Separate adding to working group and requesting a review actions
  • Make it clear that reviews requested aren’t blockers for a trade and remove pending when progressing trade stages.
  • Allow users to write all their review changes, suggestions and comments altogether before marking review as complete 

Share modal changes:

Enabling users to request reviews at any time meant a change in functionality from sharing automatically requesting a review as well as adding a user to the working group to sharing having the option to request a review at the same time.

Reviews panel changes:

A supporting feature for the idea of having a less linear review process is to add the ability to request, resend (nudge) and cancel requests for review, giving the user flexibility in their workflow.

Draft commenting and comment component changes:

Finally another source of confusion is regarding the ability to send comments in realtime, while it makes sense to have this feature in real time collaboration tools like word online or google docs, the reality is we do not have a similar ability to truly collaborate in real time and the reality is that the reviewers, often lawyers would much rather draft all their comments at once before sending their review. The common workflow is sending versions of a document via email so real time collaboration is usually not the ideal case after all. 

Email changes:

A supporting change was to clarify the messaging when reviews are requested. Because we have previously used a generic email for all our communication, the messaging seemed out of order and unclear. With the new changes meaning you can potentially be requested a review more often in a trade, the language needed to be clear.

Notifications

Potential solutions:

  • Create a new email methodology
  • Only send emails when user is required to action
  • Allow targeted notifications
  • Provide a solution to satisfy security requirements of some of our users through a daily digest email. 

Rather than understand and modify the current implementation of notifications, it made more sense to start from the beginning with an email methodology and build on from that. This ensures that whenever we add a feature, we know when to add a notification and that it doesn’t end up to the same state that we have now. Before scrapping the notifications we created a daily digest emails to satisfy some organisation’s security and audit requirements and then began on the key aspect of friction which was the amount of emails and not knowing when an email was important to the user. This made us decide to create a methodology for both when the email notifications are sent and what they contain. 

With both of these methodologies agreed on by the wider team, we went ahead to map out the standard user flow to identify key action points and which users are required to be notified. A small issue we ran into was that key roles in a trade doesn’t always correlate to the actions required, especially in the post trade stages where document collaboration is fluid. This made us decide to create new over arching fluid roles based on actions taken on the trade. These were: 

  1. The Creators and Editors – who are often the lead in editing the documents therefore most likely are the key action takers in the trade meaning they won’t need confirmation notifications of their own actions.
  2. Approvers – who are key users in a trade to progress however won’t require updates unless summoned to review and approve a document.
  3. Viewers – are passive users who are required to have oversight in the trade however mainly care about the high level progress through key trade stages.

Once mapped out this simplified the view of notification events on the key workflows.

Due to the collaborative nature of preparing documents and allowing internal or external comments you always had to send a general notification so it made sense to rebuild communications within the platform to support targeted comments through private commenting, replacing internal, which allows users to specify exactly who the comment is sent to. On top of this we added the ability to mention specific users to again be even more pointed with the notifications. 

Finally the last aspect of improvements required was in the email contents themselves. This involved providing key information on certain email notifications, while stage changes was clear or requests for review, feedback given emails were not informative often requiring the user to log in to see the feedback. Our solution was to create a hierarchy of comment importance and present the most important feedback at the top of the email. 

All in all, the improvements has not just reduced the amount of emails from about 50 to less than 10 for editors, creators and approvers and less than 5 for viewers depending on trade type, but the main benefit was through clarity on actions required to progress a trade making it quicker to complete and list on stock exchanges.

These changes have been delivered and with feedback being mostly positive, we have received some pushback with some users wanting more updates but we are approaching this as V2 which will be focused on personalisation of emails as a way to truly cover all differing requirements.