Enterprise Data Self-Service Platform

Challenge

The current enterprise data warehouse aggregates risk and finance data with contracts, balances and positions at the General Ledger level. It acquires data from 100’s of different source systems and sends data to critical downstream applications that use that data to submit reports to regulators and other bodies.

In order to ensure it’s sending the proper data to these downstream applications, users first need to check if the data required exists within the warehouse and if it meets their expectations and criteria.

Currently in order to do this, users must submit a data demand request to a dedicated team and wait several weeks to get a response. This causes problems for downstream application teams who have to wait for an extended period of time to receive and analyse this data which may uncover incorrect or missing data, forcing them to go back and create a new data demand for an updated test file.

Users need to quickly and easily understand what data is available and how that data meets the their needs before they can continue in their process – such as completing various data calculations or submitting reports to regulators.

Process

The new platform aims to facilitate this data analysis within minutes not weeks, giving users the ability to quickly view enterprise data to make informed decisions about the data availability, quality and accuracy that can be used for their initiatives.

After kicking off the project with the members of the wider product team, I began by analysing the current solution, identifying key users of the system and understanding the functionality. This led to defining two primary personas for the system:

  • The Architect – those who are owners and stewards of data, controlling what should and shouldn’t be in the system
  • The Investigator – those who are frequently running queries on multiple databases and carrying our requests submitted by other users

Using this information, I carried out a series of user interviews of both current users and potential new system users to form a solid understanding of the goals and pain points. The analysis of these sessions led to forming ‘How Might We…’ statements, current journey maps and user flows. Using these visualisations, I plotted the key goals and tasks for users at each stage of their journey.

When reviewing all of the current research and speaking with the business stakeholders, I became aware of the need for a third persona:

  • The Curious Explorer – someone who is an infrequent user and simply uses the system to explore what data is available

After identifying this persona, I moved into the design phase of the project. Starting by building on the journey map, I looked at a more research based approach to each users journey, cutting out unnecessary hurdles. using the previously created statement starters, I facilitated an ideation workshop aiming at plotting opportunities on the proposed journey map, highlighting key areas for consideration.

Following this work, I met with the tech and product teams to share findings, discuss scope and assess any constraints that might arise from opportunities in the ideation session.

Having gathered knowledge and research, I began to create lo-fi wireframes for the new platform, allowing them to be continuously tested with users as work progressed. The lo-fi designs, once validated, were moved into hi-fi designs to help illustrate to the engineering team and senior business stakeholders how the product would look and, more importantly, function.

RESULT

  • A highly effective solution, ensuring all users are able to access the data they need in a way that make mos sense to their archetype
  • High fidelity designs that are able to be used by engineering teams to create the new platform
  • Developed a roadmap for the team in a way that will help guide them through the process of making effective insight-driven decisions moving ahead
  • Helped the product team to understand and trust the UX process through ‘doing’
  • Helped to create a more joined up product team – demonstrating ways in which tech, business and UX can collaborate and form more effective solutions
  • Highlighted the value of the UX process to business stakeholders by following it through fully and making the outcomes visible to them through regular stand ups and reviews

Lessons Learned

Provide Visibility – Throughout each stage of the process, ensure there is visibility of the project, whether this be through links to the deliverables, signposting to the files or regular playback sessions. This helps stakeholders to visibly see the progress and it helps the team easily find each others work

Teach by Doing – Sometimes the best way to show the value of a process is simply by doing it. No amount of talking or explaining can help show the benefit of using the full UX process. Walking others through this process as you go, combined with highlighting the deliverables and impact/results at the end will really make a difference for those unfamiliar or skeptical with our process

Communicate and Follow-Up – Throughout the project, make sure to keep lines of communication open constantly. This allows for the right work to be carried out and for effective follow-up to happen. Make sure to continually follow-up on work and progress as you go, this can help to keep the project on track, and more importantly moving in the right direction. Good follow-up is also useful when helping others to up-skill or those who require extra effort, it enables you to encourage them at each stage of the process