e-Invoice Compliance - Email Distribution

UX Lead
Project Overview
Electronic invoicing (e-invoicing) mandates are used by governments across the the world to close their tax gaps. In countries like Chile and Italy, invoices must be approved in real-time before a purchase can be completed.  

For this project, our goal was to build an app that our internal teams could use to setup accounts for new multi-national customers. We built out workflows for user and org management, setting up integrations and more. In this case study, I will explore the work we did with email templates.
My Contributions
In my role as UX lead, I managed the UX roadmap for this 6-month project with support from teams in the US, Brazil and Ukraine.

For each settings page, we followed a similar design process, which involved exploration and testing with users, iteration with a small, focused team, and refinement with the full scrum team.

The Problem - Email Templates

Sovos implementation consultants create customized email templates for each customer so that invoice information can be distributed to the right teams. For example, the finance team may need to know when an invoice is approved in order to recognize revenue.

Because the emails contain dynamic data pulled from XMLs, setting up these templates can feel complicated, and users often shift between different applications to get the information they need.

Insights from Exploratory Research

Experienced users usually know which xml paths to reference based on experience. Less than 10 are used 80% of the time. For example, invoice number is usually referenced in the subject. Date, invoice, purchase number are referenced in the body.

We discovered that being able to copy these common fields and paste right in the product would be very useful, especially for newer employees.

Here's an early mock up done in Balsamiq showing a condition builder and WYSIWYG text editor with a drop down for common XML paths.

Final Design & Specs

We selected DraftJS as rich text editor, and built in the ability to edit using rich text or mark up. This ensured we were supporting both experienced and novice users. Instead of entering XML path info inline, we created a short directory of common paths to copy and paste.

During usability testing we realized that conditions were rarely used, so instead of implementing a conditions builder we pivoted to allowing users to add conditions using HTML.