Callsign is a platform for contextually aware, multi-factor authentication (MFA). It provides access to online and proprietary services based on assessed risk and policies, via multiple authentication channels such as tokens and mobile apps.
To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study.
The pre-existing Dashboard developed organically as the startup worked out its product direction. This needed a reorganisation, with a scalable structure for adding new features and to support various integrations (e.g. Windows, SAML)
Lead design and was responsible for the experiential strategy, producing all UX deliverables from 2016–2018.
There were a number of engineering issues that hampered the project:
After evaluating the functionality and understanding the feature gaps with the product team, I undertook the following:
Navigation structure was reorganised into clear sections, to help the user create a mental model of and manage the different aspects of our service. To simplify access flows for common tasks, I added cross-linking between related sections.
Layouts needed to scale as the team added new features. By using a card-based layout, I was able to mix different elements as required while maintaining a hierarchical structure on the page. This gave us the added benefit of standardised components that could be reused on other screens.
Admin privileges were grouped together to enforce a role-based access model, allowing for easier setup and management of admins.
Setting up new services was a particular pain point for customers and the technical sales team, causing confusion and frequent complaints. So I defined a new multi-step setup widget that would walk you through the process, restricting input to only the relevant fields for the type of integration.
Audit logs for authentication requests didn’t provide a clear understanding of what had happened. So I revised the table with clear visual status of the outcome and added an expandable section to each record to view its details and to compare with other records. A revised search with inline querying was also added to make the process faster for power users.
Services can potentially trigger many types of authentication requests. As these are the most modified section of a service configuration, I separated them into a new section to avoid confusion with other fields. Input fields were revisited and expanded to capture all possible implementations for a protocol (e.g. SAML). We also rolled out chained authentication methods in the platform and these were embedded in the request panel with preconfigured flows for easy selection and provided visual feedback to users in the form of decision trees.
Authentications are typically managed by rules and policies that our research revealed can take weeks to amend. So we decided to build a separate policies section, with visual controls that removed the complexity in making changes, making it easy to setup powerful rules for authentication requests. After testing many variations with anti-fraud specialists, we decided to group the rules by channel (e.g. mobile app), allowing customers to set conditions for the end-user's device, its location and their behaviour while using it.
Work on the Dashboard is ongoing, and thanks to the revised layouts, much easier to implement. But many planned features have still not been implemented due to speed of development – such as adding insights to supplement the analytics – which is unfortunate as it dampens the experience of the product.
The card-style components, however, have proven to be a flexible system for adding features, device types and other service requirements, fulfilling a critical need as the platform evolves.
Due to a strategic shift last year, the Policies section was deemed too simple for some clients. Deciding to build a separate solution for executing more granular policies, the new Policy Manager web app used the Dashboard's text-based query system to build out its new interface.