I am a UX practitioner and Information Architect who puts people before technology and seeks out data-driven answers so I can discover how best to create usable, efficient, and pleasing experiences.
Thank you for your interest.
Financial clients, such banks or other transaction focused institutions, face two challenges: they must scan an exponential amount of data to detect fraud while complying with federal regulations to also search for bad actors who appear on criminal watch lists.
To do so, they rely on SaaS products like FCM, which leverage algorithms to help analysts and investigators sift and organize vast quantities of data. When I joined the FCM’s product team as a UX/UI Designer and Developer, two iterations of the software had already been released.
I began work on the Business Unit Hierarchy, a platform module feature which allows users to create a model of their organization within the software. This allows users to then restrict access to the sensitive data as well as to run specific reports to meet investigatory and audit needs.
I began with an extensive document review to learn about the current state of FCM. In addition, I began to familiarize myself with the domain by engaging with FIS subject matter experts and members of the product team.
Then, I began to review a broad set of business requirements. Developed by our SMEs and product managers, these requirements provided a basis for our initial design discussions. I determined that the business hierarchy was a crtical feature, but rarely interacted with. As such, helping users avoid error was crucial and the interface should ensure clear feedback and communication of the ramifications of user actions
I began to produce basic screens flows and wireframes that leveraged the current design assets in FCM to ensure a continuity of the user experience throughout the application. They included confirmation messaging, field validation, and other design mechanisms that ensured a user could not construct a faulty hierarchy.
Eventually, the construction of the hierarchy was removed from the user's hands. Instead, a data file uploaded by the implementation team would help us ensure that greater accuracy.
However, an unanticipated development limitation occurred after the overall software processing speeds were tested. This required a rapid redesign of various modules, including the business hierarchy. This required a culling of features that would have to be reserved for later iterations. And it meant a rapid redesign and redrafting of artifacts.
I then compiled a UI functional design requirements document, which provided highly detailed design and interactivity descriptions. It included screen flows as well as our finalized wireframes. The document would not only be used for development, but also for unit testing.Conclusion
A living document, the UI requirements will serve as a platform for the design and development of future releases. It will be appended with future features as well as critical feedback from user groups who will be working with the next release of FCM.