What is IDmee?
IDmee provides remote biometric authentication technology for governments, banks, and anyone else. Their product is an SDK that can be embedded in any native iOS or Android app, giving the app new methods for authentication and KYC verification.
I was hired as a UX and UI designer with the goal of bringing UCD design processes to the organisation. I joined a remote team of 6 developers and a product / business owner, and together we worked out a new design and development process.
The IDmee SDK combines several services into one complete ID verification journey, which can be embedded in any iOS or Android app. The SDK works like this:
- The SDK reads the Human Readable Zone (MRZ) on the passport or ID, which gives the SDK access to some basic data contained in the document. It also gives the SDK a one-time digital key to the protected electronic chip.
- The SDK is then able to use the key to scan the chip using the device’s NFC reader, which gives the SDK access to all of the data on the chip, including a high resolution copy of the passport photo.
- The SDK then uses the device’s camera to scan the user’s face. Various anti-spoof techniques are employed, such as flashing a random sequence of colours from the screen onto the user’s face, which is then analysed afterwards.
- The SDK sends the copy of the passport photo and the face scan to the iProov service, which compares the two items and then uses AI to decide whether 1) the scan is real and 2) the person in the scan is the same person as in the passport photo.
- The SDK receives the decision, which is passed on to the host app so that the user may continue on their intended journey.
A few use cases for this SDK are signing up for a new bank account remotely, enrolling in a government program remotely, or even just logging into a website without a password.
- Create a new demo app that hosts the SDK and shows off its verification capabilities
- The demo app will show the how the SDK’s UX integrates with a host app
- The demo app will show how developers and brand managers can white label the SDK by overriding the visual styles
The demo app will be available to anyone on app stores, but would be primarily used in-person as a sales tool.
My design process
The project had been running for a while before I joined, and already there had been several proofs of concept and working prototypes created. These were useful for me because they helped me understand the flow of data and the communication between the various services involved.
The first thing I did was arrange for user testing of one of the existing demo apps, which would provide me with a benchmark. The testing revealed several bottlenecks, and in particular highlighted major usability issues when it came to scanning the passport’s MRZ page and NFC chip.
My analysis contained some suggested solutions to the problems we discovered, however we agreed that we would use the insights to inform a new user journey and UI, rather than to improve the existing one.
Add a pinch of desk research
Not all research needs to be highly structured, and sometimes there are opportunities to learn in places you don’t expect. YouTube comments, for example…
You can learn more about my approach to discovery and testing in my UX-focused case studies.
Journey audit & re-mapping
I created a representation of the user journey, which I then modified based on our newly gathered user insights, as well as a bit of best practise. Essentially I proposed a more focussed and friendly experience by removing superfluous and confusing steps, and adding in a number of explanation and instruction steps that would help with the tricky MRZ and NFC steps.
It was clear from the user testing that a lot of the usability problems stemmed from a lack of awareness of the presence of the NFC chip. And nearly everyone who knew that there was a chip didn’t actually know for sure where it was located.
This isn’t helped by the fact that there is no standard among passport manufacturers, every country seems to have its own placement, and some countries such as the UK have changed the location of the chip in more recent passports.
There was also clearly a lot of uncertainty about why each step was needed. For example, why should I have to scan the MRZ zone and then scan the NFC chip? What does each step actually do exactly? There were further questions about privacy: Where is my data stored and can anyone now access it with this app?
To help solve these issues I created a communication/copy document that specifies carefully-chosen interface copy to carefully explain each step to the user. Not too much, not too little. Not too technical, but not so lay as to be unhelpful.
Piecing the journey together
By now we have the following ingredients:
- Technical understanding of how the authentication services are orchestrated
- An understanding of how people feel about allowing an app to scan their identity documents
- Insights into which steps in the process are difficult to complete and why
Enough to get cracking on the user journey. We start bringing the journey to life using lo-fi wireframes that showing the UI elements for each step:
A bit more detail
Looking good, but I wanted to explore the UI elements in a bit more detail before diving into the final UI phase. In particular I wanted more clarity around the in-app UI customisations and the native iOS elements that would be preset, such as the NFC dialogue.
Finalising the UI
Animations and interactions
As mentioned before, the user testing that I did revealed two steps that users had particular trouble with completing. Apart from carefully crafting the interface copy to be as clear and helpful as possible, I also wanted to give these areas special attention ininteraction and animation design.
I created short, simple animations that showed how to place the phone next to the passport for scanning the chip and for reading the MRZ page. But we know that people tend to gloss over wizards and tooltips and the like, so I wanted to find a way to present the animation to the user firmly, with clear intention. I achieved this by 1) presenting the information in stages and 2) but having each stage triggered by the user and 3) each stage having a transition period where the button was disabled, so that impatient users couldn’t force the app to skip over the instructions.
This might be frustrating for some users, but a lot less frustrating than failing to scan their passports properly.
Leveraging existing design language
Vipps had already published a well-documented styleguide detailing which basic styles should be used to express their brand on digital properties such as this. That made it easy for me to bring in the basic type styles, colours and some other styles. It meant I could spend more time on developing transitions and animations to solve the usability bottlenecks.
The developers got to work on implementing the new designs and as soon as we had a end-to-end draft I arranged for a second round of user testing. Because I had done the benchmark testing at the start it meant that it should be possible to see quite plainly whether the new designs out-performed the old ones… and they did. Users were able to complete the tricky MRZ and NFC steps a lot more easily. Although the success rate was still not 100%, this was starting to look like an app that would perform well in the wild, which I think is an accomplishment given the unusual physical tasks that it demands.
There’s still work to do. The new app is currently in the final stages of QA, with the project having been put on hold for most of the year because of the pandemic. I look forward to helping the team move the deisgn forward again after launching.