Background

Kantox had an outdated on-boarding process which required lots of manual work from internal teams. The process was slow, inefficient and apt to human errors both from Kantox employees and clients, therefore leaving both sides frustrated.

Process

As the owner of this project I had the privilege of deciding which framework to use. This was a good opportunity to “lead by example” and introduce the whole Product team to the benefits of adopting design processes early on when developing a new feature or a new product.

The process I’m referring to is Design Council’s “Double Diamond” consisting of four stages: Discover, Define, Develop, Deliver.

Discover

The problem

After interviewing several stakeholders I found out that the current on-boarding had several flaws:‍

1. The UI design of the screens was still looking like the first version (V1) of the software, therefore giving a perception of unprofessionalism. (see photo below)
2. Save feature not working, hence users would need to restart the process if they don’t complete in one sitting (for example if they forgot one document).
3. Users would submit empty applications and send all the documents at a later stage via email to the support team.
   
4. Some of these documents contain sensitive information and clients had security concerns over sharing them via email.
5. Even when users completed the form in full, most of the attachment fields only allowed for single file uploads, but most documentation comprised of more files, therefore still making necessary further communications between support team and client.
6. The documents necessary to on-board a client will differ depending on a series of factors which need to be identified (country where business is registered, purposes of payments, etc…)

I documented every step of the process using design thinking methodologies, and as you can see below it’s pretty clear that the main problem is the need for every side involved /Sales, CSM, client) to retrieve necessary documents, share information and align on next steps.

This process would take on average 2-3 weeks and require up to 10 hours of work from the Compliance department for each application. If in the end the prospect wasn’t a good fit to become a client, the team would have spent roughly 5 hours of time on a useless application. Those numbers were a good starting point for creating metrics and track the success of the project.

Define

The solution

When the problem and pain points of the different parties were clear, I went ahead by writing scenarios, use cases, and requirements for the ideal solution into a Confluence page and getting the document reviewed by the developers that will need to work on the project.

Each problem had a pretty straight forward solution, and this were the main key features for the new on-boarding:

• Place the risk assessment questionnaire as initial step, so that users would be re-directed to a form specific to their Risk Level, only needing to send relevant documents and therefore avoiding the overload of our compliance team.
  
• Make sure users can save the progress of the application and come back to it later if needed.
  
• Make some of the required fields mandatory so that users can’t submit empty applications. This would also make the process more secure, by not having to rely on emails anymore.
  
• Change the upload components to allow multiple files upload.
  
• Adapt the UI to the most recent version of our design system.
  
  

Develop

Wireframes and Prototypes

I grouped the different requirements by category to split the form in sections that would be more easily manageable to fill by the user, the Risk Assessment being the first step as that would re-direct users to different forms.

At this stage we worked on mid-fidelity wireframes, iterating interactions and applying our design system library.

Deliver

Engineer handoff

At this stage when everything is defined and our work is “finished” the only thing left to do is making sure that it gets developed the right way, to do so I think it’s important to review projects early on with QA, Back End and Front End teams so that they could spot inconsistencies. It’s also our responsibility to make it as easy as possible for them to develop as close as possible to the wireframes provided, in order to achieve that I usually:

‍Share a clickable prototype
‍This is a good way even for you to test if you missed some key interaction elements or screens

‍Share code specifications and wireframes
‍Make sure you include all the necessary details alongside your wireframes: HEX colour codes, margin sizes in px, padding and border-radius, etc…

‍Share knowledge and insights
Whenever possible, try to explain the reason behind your choices, what to share and how deep you need to go with the explanation depends on the case, just try to make sure developers don’t have any doubt about why they’re building this in this way, and what’s the value of the whole project/feature.