Callsign

Mobile apps for secure, AI-driven authentication

Callsign is a platform for contextually aware, multi-factor authentication. It provides access to online and proprietary services based on assessed risk and policies, via multiple authentication channels including its mobile apps.

These iOS and Android apps were initially developed as a unified self-identity store, for users to manage and share access to their data with other people and services.

I joined the team back in 2015 as their first inhouse designer, looking at user experience across all products.

My first task was to reevaluate the mobile apps and consolidate their diverging screen flows. They also needed a refresh on both platforms due to their retro (iOS 6-style) look and behaviour that was putting users off the apps.

Security was paramount in every decision that had been already taken and as I dug further into user flows like registration, it became apparent how these had informed technical restrictions and usability compromises, both in the app’s interface and on the platform, that now made further change incredibly hard.

Starting with an audit, I first identified the key components and flows. There were two clear jobs a user could do with the app—approve authentication requests and share data with their contacts.

Working with the mobile team, we first stripped back the faux iOS interface, replacing them with native components to align with the user’s preferred OS experience. This refactoring offered the added advantage of adaptive layouts for varying screen sizes, better app stability and full accessibility support.

Next we tackled the core flows for registration/sign in, authentication and data sharing. Around this time we decided to double down on authentication, so I eliminated everything extraneous like ways to manage contacts and share personal data.

The core focus on authentication meant elevating it to a global function, so users would easily access the approval process when a push came through to the app. So I reworked the authentication flow for complete flexibility, to string together authentication methods in any way the policies request.

Policies are based on contextual information gathered by the app, as a means of removing or adding resistance to the approval steps. If something suspicious is detected, the user is stepped up to a more secure form of authentication. Some of these required a balance between business requirements and usability compromise.

For example, we borrowed Tinder’s swipe mechanism as a means of approval. This required trial and error, to capture fluid motion of the card being swiped offscreen while constraining motion capture in particular ways to help capture a diverse dataset for behaviour modelling through machine learning. Attempts at offering onscreen user guidance had similar issues as it reinforced certain motions that reduced data (since removed to a modal triggered by a discrete tooltip).

As we aligned the Android and iOS apps to their respective OS experiences, it was also a good time to revisit decisions to align internal behaviour between them for a consistent experience and feature parity.

Sometimes these decisions become opportunities to resolve outstanding engineering challenges while reinforcing paradigms and simplifying user behaviour.

As changes to account details are a sensitive operation, the apps had complex rules for how a user would edit and save changes. These rules and the handling of various edge cases (network error, incoming call, etc) differed between the two platforms. I explored various options with the engineers but to no avail.

Then while I was reworking the authentication flow, it became obvious that asking for a user’s Pin shouldn’t just be for enhanced authentication – we should also use it for confirming sensitive operations. The added friction was just the right amount to make a user act deliberately and error handling could be radically simplified.

The process of reworking the apps has been a lengthy and detailed affair with some crucial usability tasks still remaining. These have been held back due to some technical decisions and the reduced speed that comes with the complexity of securing the code.

The apps have now morphed into multiple instances with a core SDK. This is an area of ongoing work for theming and enabling additional functionality for client apps, including support for PSD2 banking requirements.

DELIVERABLES

  • User Flows
  • Wireframes
  • Prototype
  • Functional specifications
  • Usability testing