Fintech Dello Banking App - New Way to Empower Life

Fintech Dello Banking App - New Way to Empower Life

Fintech Dello Banking App - New Way to Empower Life

Project overview

Project overview

Project overview

Lighthouse was an AtkinsRéalis web application, a project management tool built for design managers, project managers, and engineers. The product offered functionalities like gantt view, network view and predictive optimisation of project path. When entering the project, that was still scope for the first 6 months, until the discovery phase and guild lead meetings led to the final decision of re-building and starting Lighthouse from scratch. A complete re-build took place over a timeframe of 2 years and that was the birth of Production Manager.

Project solution

Project solution

Project solution

Production Manager is now part of a product suite called DPM with three web-applications. Now the users have greater visibility of their schedules that are easier to digest as it's user access driven, alerts are thoroughly explained in details using project controls best practices, and the progress tracking feature enables the team to track progress and collaborate on the desired WBS level and more. As being part of the DPM suite, Production Manager now has a well-defined vision, targeted goals and a plan already in motion, but now led by product owner.

My role

Supporting the cross-functional team with user centred approach through research, analysis, design, wireframing and strategy.



Team

  • 2 UX Designer

  • 4 Software Engineers

  • 2 Data Scientists

  • 1 Product Owner

  • 1 Product Manager

  • 1 Scrum Master

  • 1 QA Tester

Tools

  • Figma

  • Mural

  • Figjam

  • AzureDevOps

Timeline

  • Aug 2022- Feb 2025

  • Working in 2-week sprints

  • Aug 2022- Feb 2025

  • Working in two-week sprints

Indicators of success

Indicators of success

Indicators of success

  • Re-built web-application with new information architecture, introducing two-level global and local navigation

  • Progress tracking: replacing uncontrolled clunky excel spreadsheet with user access driven progress tracking enabling users to export changes easily without having to cross-check every cell and compare two excel spreadsheets next to each other to identify progress updates by team members. In-app communication on WBS items.

  • Alerts feature:more intuitive alerts section with plain language and explanations and calculations visible

  • WCAG 2.1. AA standards introduced

  • Self-service application: reducing workload on BASS (support team) and adoption team

  • Improved user experience; through tailored WBS, more tooltips and explanations, more inclusive designs ensuring to follow AA WCAG 2.1 accessibility guidelines, user access enabling users to view only their deliverables instead of large volume of data to digest

  • Increased product adoption; product adoption on Lighthouse was 0% within the business

  • MSP Integration for schedules

  • Reduced loading time of gantt (schedule view)

Main Project Image
Main Project Image
Main Project Image

Research

Research

Research

  • User interviews

  • Stakeholder interviews

  • Usability testing

  • Competitive benchmarking

  • Card sorting

  • Workshops

  • Benefits realisation exercise connected to identified problem statements for each of the personas


Workshops

Workshops

Workshops

User persona: Project manager

Who - User persona

Who - User persona

User persona: Planner

Who - User persona

Who - User persona

Who - User persona

User persona: Planner

Lighthouse was a legacy project management tool designed for project managers, engineers, and design managers with functionalities like gantt chart, network view, user management, and predictive optimisation of project path. Through usability testing, stakeholder interviews and user-interviews, it became clear that the product was not adopted due to lack of confidence in the data outputs from the app, the lack of clarity on the alerts functionality and usefulness for design managers, gantt loading time, and not offering a MSP project (MSP) integration for schedule import.

User quotes

User quotes

User quotes

"I just think the alerts could be easier to engage with. I feel at the moment it doesn't give a complete picture of what we have as a problem because it wraps up alerts over multiple schedule lines". - Design Manager



"The description of the alerts needs to be in more plain english". - Design Manager


"There is no indication of what is the difference between the primary and secondary alert types and that is a nightmare. If I knew it, that would be fine, but there's lots of other people going on here and they wouldn't know as well". - Design Manager


The discovery revealed that 90% of the business uses Microsoft project (MSP) for their project schedules, and as a result, the Lighthouse were only including 10% of their targeted user base by not offering the MSP integration. One could challenge the users suggesting them to convert the MSP file to Primavera P6, however due to high license costs and client contracts mandating Microsoft Projects, that was not an realistic option. User interviews also revealed that Lighthouse did not incorporate enough user-research on the persona handling the project schedules, the planner. Further discovery with the new identified persona, the planner, revealed a lack of willingness to change ways of working. Each had their own processes in place and Lighthouse was in some scenarios seen as a threat to their job, instead of a way to reduce workload through features like progress tracking which were currently led by Planners through numerous meetings with Design managers and excel spreadsheets which had loads of challenges associated with it.


The interviews with design managers revealed several pain points regarding their project schedule and their context. They first of all didn't understand the schedule they were sent by the project manager, it was difficult to locate their responsibilities in the schedule due to large amount of data in a clunky PDF.

Furthermore, the work breakdown structure were defined by the Planner and not the design managers who were executing the work, so a need to be able to restructure the WBS were added to scope of the new development, as well as being used as a unique selling point to the business later on.


The benchmarking of direct and indirect competitors also revealed a need to be able to add several work breakdown structure levels, the former Lighthouse solution only offered the users a maximum of three levels in the WBS, which also was an issue as some large-scale project with clients had more than three. That decision of introducing additional customisable levels only led to more inclusive design for our users as they then would be able to adopt the tool and tailor their own WBS to fully understand the work they were undertaking.


With low adoption, extensive user feedback and stakeholder feedback, my final recommendation as part of a UX guild team, was the Lighthouse did not serve the business goals it intended to due to;

  • Users lack of confidence in data

  • Lack of must have functionalities

  • Downtime and bugs

  • Poor interaction designs

  • No design system or style guide for the app

  • Poor navigation and structure as information hierarchy did not account for a two level which was needed


As a result of guild meetings with enterprise and solution architects, developers, and business stakeholders, the final decision were to rebuild the application. That was the birth of Production Manager.

The discovery revealed that 90% of the business uses Microsoft project (MSP) for their project schedules, and as a result, the Lighthouse were only including 10% of their targeted user base by not offering the MSP integration. One could challenge the users suggesting them to convert the MSP file to Primavera P6, however due to high license costs and client contracts mandating Microsoft Projects, that was not an realistic option. User interviews also revealed that Lighthouse did not incorporate enough user-research on the persona handling the project schedules, the planner. Further discovery with the new identified persona, the planner, revealed a lack of willingness to change ways of working. Each had their own processes in place and Lighthouse was in some scenarios seen as a threat to their job, instead of a way to reduce workload through features like progress tracking which were currently led by Planners through numerous meetings with Design managers and excel spreadsheets which had loads of challenges associated with it.


The interviews with design managers revealed several pain points regarding their project schedule and their context. They first of all didn't understand the schedule they were sent by the project manager, it was difficult to locate their responsibilities in the schedule due to large amount of data in a clunky PDF. Furthermore, the work breakdown structure were defined by the Planner and not the design managers who were executing the work, so a need to be able to restructure the WBS were added to scope of the new development, as well as being used as a unique selling point to the business later on.

The benchmarking of direct and indirect competitors also revealed a need to be able to add several work breakdown structure levels, the former Lighthouse solution only offered the users a maximum of three levels in the WBS, which also was an issue as some large-scale project with clients had more than three. That decision of introducing additional customisable levels only led to more inclusive design for our users as they then would be able to adopt the tool and tailor their own WBS to fully understand the work they were undertaking.


With low adoption, extensive user feedback and stakeholder feedback, my final recommendation as part of a UX guild team, was the Lighthouse did not serve the business goals it intended to due to;

  • Users lack of confidence in data

  • Lack of must have functionalities

  • Downtime and bugs

  • Poor interaction designs

  • No design system or style guide for the app

  • Poor navigation and structure as information hierarchy did not account for a two level which was needed


As a result of guild meetings with enterprise and solution architects, developers, and business stakeholders, the final decision were to rebuild the application. That was the birth of Production Manager.

Analysis

Analysis

Analysis

  • User personas

  • Affinity diagram sessions with cross-functional team consisting of dev team, stakeholders, product owners

  • Problem statements

  • User stories

Who - User persona

Who - User persona

Who - User persona

User persona: Project manager
User persona: Project manager

Who - User persona

User persona: Planner
User persona: Planner

The team introduced two categories of targeted end-persona, primary and secondary;

  • Primary personas:

    • Design Manager - responsible for project delivery, understanding and making decisions from outputs to mitigate risks of delay/cost overruns


  • Secondary personas:

    • Project manager - responsible for making sure that the project delivers the right outcomes to the client and the business so that the market shares continued to grow

    • Planner - responsible for scheduling the design stages of work with guidance from discipline teams and tracking progress to ensure delivery milestones would be met

    • Project director - responsible and interested in project performance and reporting upwards, ensuring high risk items are mitigated effectively

    • Discipline leads - responsible for a specific discipline/set of disciplines design delivery

    • Engineers - responsible for design delivery of specific aspects


The affinity diagram sessions conducted aligned the team and produced new items for the roadmap in shape of user stories connected to a story three (epic, feature, user story). The user stories were crafted along the way and iterated continuously through context and roadmap sessions with the dev team to ensure feasibility of what we were going to build 2-3 sprints ahead. Moving forward, for every feature introduced, we tested the designed solutions with out the targeted personas for that specific feature and each of them went through numerous iterations before being built.

The team introduced two categories of targeted end-persona, primary and secondary;

  • Primary personas:

    • Design Manager - responsible for project delivery, understanding and making decisions from outputs to mitigate risks of delay/cost overruns


  • Secondary personas:

    • Project manager - responsible for making sure that the project delivers the right outcomes to the client and the business so that the market shares continued to grow

    • Planner - responsible for scheduling the design stages of work with guidance from discipline teams and tracking progress to ensure delivery milestones would be met

    • Project director - responsible and interested in project performance and reporting upwards, ensuring high risk items are mitigated effectively

    • Discipline leads - responsible for a specific discipline/set of disciplines design delivery

    • Engineers - responsible for design delivery of specific aspects


The affinity diagram sessions conducted aligned the team and produced new items for the roadmap in shape of user stories connected to a story three (epic, feature, user story). The user stories were crafted along the way and iterated continuously through context and roadmap sessions with the dev team to ensure feasibility of what we were going to build 2-3 sprints ahead. Moving forward, for every feature introduced, we tested the designed solutions with out the targeted personas for that specific feature and each of them went through numerous iterations before being built.

The team introduced two categories of targeted end-persona, primary and secondary;

  • Primary personas:

    • Design Manager - responsible for project delivery, understanding and making decisions from outputs to mitigate risks of delay/cost overruns


  • Secondary personas:

    • Project manager - responsible for making sure that the project delivers the right outcomes to the client and the business so that the market shares continued to grow

    • Planner - responsible for scheduling the design stages of work with guidance from discipline teams and tracking progress to ensure delivery milestones would be met

    • Project director - responsible and interested in project performance and reporting upwards, ensuring high risk items are mitigated effectively

    • Discipline leads - responsible for a specific discipline/set of disciplines design delivery

    • Engineers - responsible for design delivery of specific aspects


The affinity diagram sessions conducted aligned the team and produced new items for the roadmap in shape of user stories connected to a story three (epic, feature, user story). The user stories were crafted along the way and iterated continuously through context and roadmap sessions with the dev team to ensure feasibility of what we were going to build 2-3 sprints ahead. Moving forward, for every feature introduced, we tested the designed solutions with out the targeted personas for that specific feature and each of them went through numerous iterations before being built.

Through workshops with the team, we completed a benefits realisation exercise where we mapped out all identified problems within the business and connected it to the user personas, and then further mapped out which functionality inside the tool that was solving this problem for the persona. This enabled marketing team, adoption team, the product owner and the product manager of the suite to align on what is being communicated to the business through demo's and marketing material.

Large Project Gallery Image #3
Large Project Gallery Image #3
Large Project Gallery Image #3

Through workshops with the team, we completed a benefits realisation exercise where we mapped out all identified problems within the business and connected it to the user personas, and then further mapped out which functionality inside the tool that was solving this problem for the persona. This enabled marketing team, adoption team, the product owner and the product manager of the suite to align on what is being communicated to the business through demo's and marketing material.

Design

Design

Design

  • Flow diagrams

  • Use cases/edge cases

  • Sketching

  • High-fidelity prototyping

  • Wireframing




After the user stories were approved by product owner, UI and UX as illustrated below, the user story were uploaded to Azure DevOps with the focus link so that the developers and the QA testers could easily inspect the new designs before the build went from DEV to UAT and from UAT to PROD.

Outcomes - What I've learned

Outcomes - What I've learned

Outcomes - What I've learned

A re-build of an existing web-application requires a lot more than just a intuitive and useful interface. This was my first experience as a guild lead in UX. The guild leads, experts within their fields (data scientist, solution architect, enterprise architect, engineer, UX Design) initiated the process with discovery which was on-going for a 3 months before making the final call, that is probably one of the best decisions as it aligned everyone.


The most challenging aspects of the re-build was first of all that this was the second attempt. People's belief and goodwill had drastically decreased, and as a result, it was challenging to get people to participate in research activities like user interviews and usability testing. In addition, there was no budget or productive code allocated to usability testing and because the engineers and design managers had really hectic schedule, this was a constant battle.


What I am most proud of and that I will continue to bring wherever I go to next are the scheduled weekly UX roadmap sessions with the product and development team. These sessions drastically increased the quality of the outputs in PROD, they reduced bugs on the board, and it more importantly created a more collaborative and social environment within the global cross-functional team.

Create a free website with Framer, the website builder loved by startups, designers and agencies.