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.
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
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)
User interviews
Stakeholder interviews
Usability testing
Competitive benchmarking
Card sorting
Workshops
Benefits realisation exercise connected to identified problem statements for each of the personas


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.
"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
User personas
Affinity diagram sessions with cross-functional team consisting of dev team, stakeholders, product owners
Problem statements
User stories
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.
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.




