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 expanding features in the future and to support a variety of different services (integrations like Windows and SAML services).
Lead design and be 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 reorganised into clear sections, to help the user create a mental model of all the different areas to manage. Cross-links simplified access to related views.
Layouts needed to scale as the team added new features. By using a card-based layout, I was able to mix different elements adhoc while maintaining the hierarchical structure of a page. This had the added benefit of reusable components for reuse on other screens.
Admin privileges grouped to enforce a role-based access model, allowing for easier setup and management.
Service setup caused a lot of confusion and complaints for users. So we developed a widget with a stepped flow and restricted input to only collect critical information for the type of integration.
Transactional audits didn’t provide a clear understanding of events. So the tabular display was simplified to give a clear status, with expandable metadata offering details in plain English. Search querying and the ability to compare transactions side-by-side was also introduced.
Services can potentially trigger many types of authentication requests. By adding a new section for configuring them, the input was aligned to the protocol (e.g. SAML). Additionally, transactions could now specify tiered authentication methods in a decision tree flow.
Authentications are typically managed by rules and policies that our research revealed can take weeks to amend. So we decided to add a policies section, with controls that abstracted away the complexity, making it easy to setup powerful rules. After many iterations, I decided to group the rules by channel (eg. mobile app), offering control over the device, its location and user’s behaviour on 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.
The card-style components have proved 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 application utilised the Dashboard's planned modular query system to build out its new interface.