Gonzalo Vásquez - Portfolio

UI FACIAL VERIFICATION

In 2016 a project on identity verification was born, which should help client's business to trust in the person to process his application and facilitate to the user his path to acquire the company's services.

01. MY ROLE

I work in the Santiago Development Center (SDC) in Santiago, Chile; which is part of the Core Software Engineer (CSE). And as part of the UX team I had the responsibility of the interaction design of the web app, both desktop and mobile, developing most of the derivable and also the front-end code of the application. I was also in charge of support the integration of the front-end with the back-end code developed by a team of engineers in Atlanta, USA.

Additionally, during the whole project I had the help and support of my team (Paula, Roberto and Anita), at visual and technical stuff.

02. A RESPONSIVE AND EASY TO USE SERVICE

So, to understand the context, we were commissioned to design a responsive web app, this app should validate the user identity trough pictures of himself or using his documents. For which we needed to use the camera's device to take pictures and also to be able to upload pictures already taken and saved in the device, a phone, tablet or desktop PC.

Before we began it was show it to us an app that was already doing those things, but it was build using flash and it had serious usability and interaction issues. My work started from the flow analysis and design of this application.

Some images of the old application.

03. LOT TO DO AND LOT TO LEARN

The first thing that we took in consideration was the responsive component of the application, a thing that didn’t look hard to accomplish at the first time, but we were asked to think in a mobile first approach, and it was still missing the technical component because we needed to find out how to open the device’s camera and upload images from the storage to be analyzed, then send it to validate it and obtain a response.

The technical challenge of validate the images wasn’t a little thing for the development team that would be working in the back-end because they should had to integrate a third party, Jumio.

Our first ideas about flow in the board.

It was decided that the first thing to do would be to create a POC (prove of concept) that could at least prove how to use the camera and to upload images from the device, and if that were not enough, this should run in a smartphone and desktop.

So with this in mind I started the development stage about what and how to use it. From the design point of view, there were 2 paths for the user. Take a picture of the ID (Identity card, Driver License or Passport) or upload a picture previously saved, both paths would be equivalent no matter the step of the validation. I had very clear that this two options should be available in any time, minimizing the errors and the possibility of to go back to re-do a step, for an error or change of option.

Sketching the flow and the behaviour of the app.

The first idea was to have a viewport for the camera to the left and a box that would show the picture taken to the right, and even this idea seemed logic and it was already used in the old application, I wasn't completely satisfied. It was then that I took my phone and took a picture, and bump! (or maybe you could say “daaaahh”). I realized about the obvious; I didn’t need one space for the viewport and another for the picture taken, in a smartphone camera, everything works into the same space and through a flow. With that in mind, I redesign my first idea and I put in the left side a space to use the camera and in the right side a box to upload images, both would have the option to accept or decline the image and in that way move on in the flow.

Sketches about the idea behind the two paths, take a snapshot or upload an image.

I decided to use Foundation for the responsive design because, it is simpler that Bootstrap, less classes and more straight forward building components. Reading the documentation and some comments in forums about its use I founded myself with an application used to test webs in real time called BrowserSync, this allow to work your web in a local host and access to it through any device connected to the same Wifi, this way I could see the behavior of my application in real time in my desktop and my phone, at the same time, any change would be deployed simultaneously. Also, I decided to build the CSS files with SASS and I configured everything in a Gulp file that was in charge of all the tasks like compile the CSS and update BrowserSync for any change detected in the HTML, JS or CSS code. Thus, I could build a POC that was working in desktop and a smartphone doing the exactly same thing.

Basically, there were 2 Javascript codes handling the camera and the upload system, but when I tried the Twitter page, not the app, in my phone to take a picture I realized that the device ask you if you want to use the camera or upload something from your library, this happen both in Android and iOS. This made me realize that the code used to open the camera in desktop mode would work to show the option in mobile, so I only had to use that for mobile and hide the rest.

I record a video (demo) in order to show it in the sprint review to the dev team and stakeholders in the USA.

Videos recorded for the demo to the stakeholders and the dev team in USA. I was working at home that day :P

It is worth mentioning that this was the first time working with browserSync and gulp, and the first time using the camera of a device in HTML5.

Thankfully the POC had a great response from the people in USA, the developers loved what I build in such a short amount of time (less than a week) so they started reusing my code for the first release, decision that gave us some problems, but I will explain that later.

04. WIREFRAMING THE INTERACTION

Generally my team works directly with the development stage, we tend not to make so much documentation because it is hard to maintain in with less documentation you can go faster, it allow us iterate quicker and deliver more and better code.

With the flow clear, in the next sprint I started to work in the wireframe for the desktop version, in fact I did the mobile version too, but just because I already had the idea of how it could be done. I include error and success messages with emojis and icons to make the process friendlier, I thought in big zones for the click/touch actions with information to prevent errors, and also I add a wizard component to inform the rest of the steps.

Different states from the first wireframe.

05. TESTING ASSUMPTIONS

Together with my partner Roberto Cordella and I using the wireframe we decided to make the first user test, this first session was made with 3 users over a prototype built in Marvel app. With this we had a valuable feedback about what was missing and what was unused. We made some changes in the information when the image was being analyzed, and in the necessaries steps to start the process. With these changes we did a new user test with 3 participants, this time we had less comments about the past problems and a better understanding of the process. It was time to move on.

Images of the user testing with a prototype made into Marvel app.

06. DESIGNING AND IMPLEMENTING

My partner Roberto was in charge of the visual design and he did a great job with the improvements to the original design of the wireframe and adding illustrations to support the messages that helped the user to take the right actions and paths.

Images from the mockup designed by Roberto Cordella.

Taking Roberto's design I began the static front-end design and thinking in an agile way it was decided that the development team in the US, leaded by my friend Apek, would work in parallel. They built the platform as a Spring Boot application using Java and Angular, by mi side I refactored the demo code and kept working with Sass (Foundation), BrowserSync and gulp and I added Tweenmax for the animations. I had the idea of add transitions and animations to a better explanation of the interactions. Sadly some of this weren’t considered for the first release, but the base code is ready to use.

07. A COMMUNICATION PROBLEM

Everything was going fine until the first review of the application, it wasn’t finished, but there was a serious problem with the integrated code because the back-end team decided to move on with the POC code and eventually this was merged with the new code, which there were many unused classes and a lot of HTML that wasn’t making anything, some Javascript and CSS conflicts, etc. I never thought that this could happen, because for me, it was really obvious that the POC code wasn’t a final and clean code, and neither was thought for the whole application. So I asked some story point to my manager to review the integrated code and help with the new that would come, clean code and libraries, just left last things.

08. OUTCOMES AND WHAT WE LEARNED

Our first release was just in-house, because some troubles with the company that assigned the project, and for now is working only the desktop version, we need to review some programing elements and methods for the whole responsive version but we already started the wireframing for different devices. In addition we had problems integrating Tweenmax with Angular; the code has to be written as an isolated directive that could be used by any view. For now we readapted the animations of the help section using ng-hide and CSS transform.

Wireframe for the responsive approach.

Mockup for mobile design.

The applications does what it promise, we are going in the right direction and what we have learned indicates, a good future to finish and fix what’s left.

I’m very happy with the comments by the people from the USA, the product owner and the teach lead. My team received the acknowledgment and congratulations for our job.

Images from the final application.

Thanks for reading.

LET'S WORK TOGETHER

Thanks for your message.

I'll answer you as soon as I can ;)