ClearGlass Analytics is an independent data analytics company that enables asset owners, investment advisors, and asset managers to evaluate the Value for Money (VfM) of their investments through transparent cost and performance data.
As part of the product team, I contributed to the development of a SaaS platform designed to serve all sides of the asset management market, delivering structured cost transparency and advanced analytics across the UK and European investment ecosystem. The platform integrates industry frameworks such as the Cost Transparency Initiative (CTI) and the Cost Transparency Standard (CTS), enabling consistent data collection, benchmarking, and more informed investment decision-making.
Designing for this product presented unique challenges due to the highly cyclical nature of the industry. The platform operates around critical annual reporting cycles that determine when new features, improvements, and data submissions can be tested and adopted by users. These overlapping cycles created a distinctive product development rhythm and required careful prioritisation to ensure the platform evolved without missing key market opportunities. As one of the first platforms of its kind, the product played a pioneering role in bringing transparency and benchmarking capabilities to the asset management industry.
The organisation operated with a strong product-led mindset, with well-informed stakeholders actively collaborating across teams. Continuous experimentation, research, and rapid shifts in focus were embedded in the company culture, creating a fast-paced environment where multiple teams ran parallel initiatives to validate ideas and improve the product.
Conducting UX research in this domain presented additional complexity. Many users interacted with the platform only periodically during reporting cycles rather than daily, which made recruitment and engagement more difficult. To overcome this, we conducted regular user interviews (approximately every two weeks) and supplemented qualitative insights with internal data analysis and feedback from customer-facing teams. Asset owners were generally more open to participation than asset managers, which influenced our research strategy.
We triangulated insights from multiple sources to inform design decisions, combining user feedback with behavioural data from analytics tools such as Google Analytics, Hotjar, and Mixpanel. These insights were shared across the organisation on an ongoing basis, ensuring that product development remained aligned with real user needs and market dynamics.
Queries / Comments Tab
Designing a communication hub for asset owners, asset managers, and internal teams.
The Project
One of the most transformative initiatives within the platform was the development of the Queries / Comments Tab, designed as a structured communication hub connecting three key stakeholders in the ecosystem: asset owners, asset managers, and ClearGlass’ internal data team. Through internal discovery we identified that communication around data submissions represented a major operational bottleneck. Questions, clarifications, and data discrepancies were being managed through fragmented channels, creating delays, reducing transparency, and significantly slowing the overall data collection and validation process. The base for this project was previous product - the Internal Validation Tool for the teams.
The goal of the project was to introduce a centralised communication layer within the platform, enabling all parties involved in the data submission process to collaborate more efficiently while maintaining a clear audit trail of conversations and decisions.
Methodology
To better understand the problem space, the product team conducted a series of collaborative workshops and stakeholder interviews over few weeks. These sessions involved internal teams responsible for managing submissions and client communications, allowing us to capture operational challenges and identify opportunities for improvement. We began with card sorting exercises to better understand how users conceptualised communication categories and message types. This helped us define the underlying information structure before moving into deeper discovery work. From there, we developed detailed journey maps and interaction flows to visualise the communication process across the three user groups. These artefacts helped clarify the complexity of the interactions and informed the structure of the proposed solution.
MVP Definition
The Queries Hub originated from comments functionality embedded within the Internal Validation Tool. Initially, comments were introduced as a lightweight way for internal teams to flag issues, request clarification, and communicate around specific data submissions during the validation process. However, as the product ecosystem evolved, it became increasingly clear that communication itself had become one of the major operational bottlenecks across the reporting lifecycle.
Conversations between internal teams, asset managers, and asset owners were often happening outside the platform through fragmented email threads and disconnected workflows. This created delays, duplicated effort, lack of visibility, and loss of historical context across the reporting cycle. Because the Internal Validation Tool sat at the centre of operational workflows, it naturally exposed the scale of these communication gaps and became the catalyst for developing a more integrated solution.
The MVP definition for the Queries Hub therefore focused on transforming basic comments into a structured communication layer embedded directly within the platform ecosystem. The initial goal was not to build a fully-featured messaging system, but rather to create a centralised workflow where stakeholders could raise queries, respond within context, track issue status, and maintain visibility across ongoing submission and validation processes.
A key part of the MVP strategy was ensuring the feature remained tightly connected to the wider operational workflows already existing within the platform. Queries needed to reflect submission statuses, validation stages, ownership, and reporting dependencies without introducing unnecessary complexity into already demanding reporting cycles.
Design & Prototyping
Once the core interaction model was defined, I moved into the prototyping phase, translating the conceptual workflows into interactive prototypes that demonstrated how communication could be embedded directly within the platform experience. The prototypes allowed us to test the proposed workflow with users and validate whether the system supported their real communication needs during data submission and validation cycles. Following successful validation, the designs were refined into high-fidelity interfaces, which were then prepared for development.
Cross-Functional Collaboration
Engineering collaboration was embedded throughout the entire process. At least one developer participated in each discovery and design stage, which proved invaluable when exploring technically complex interactions. Having engineering expertise within arm’s reach allowed us to quickly evaluate feasibility, refine ideas in real time, and significantly accelerate the design process for this multi-stakeholder feature.
Working directly within Miro also enabled close collaboration across product, operational, and engineering teams. Flows, edge cases, dependencies, and communication states could be explored collectively in real time, helping to align stakeholders around complex workflows before moving into higher-fidelity prototypes.
This approach proved particularly valuable because the Queries Hub touched multiple interconnected systems across the platform. Rapid low-fidelity exploration allowed us to test assumptions early, uncover operational gaps quickly, and continuously refine the structure of the communication experience without slowing delivery momentum.
Lo-fi Wireframing
Given the operational complexity and interconnected nature of the Queries Hub, early exploration relied heavily on rapid low-fidelity wireframing directly within collaborative Miro boards. Rather than creating polished prototypes upfront, the focus was on quickly mapping workflows, testing communication logic, and validating how queries would behave across different user roles, operational states, and reporting scenarios.
The wireframes were intentionally lightweight and highly iterative, allowing the product team to move rapidly between ideas, workshop outcomes, and stakeholder feedback sessions. Due to the fast-paced reporting environment and evolving understanding of operational needs, designs often went through multiple iterations within very short cycles.
The high-fidelity design phase focused heavily on defining information hierarchy, communication states, status visibility, ownership indicators, and contextual actions across all parts of the ecosystem. Particular attention was given to ensuring that communication remained embedded within operational workflows rather than becoming detached messaging threads. Queries, statuses, validation stages, and reporting progress all needed to remain tightly interconnected and accurately reflected across the platform.
The final high-fidelity designs established a much more connected and transparent operational experience, helping transform fragmented communication processes into a centralised collaboration layer integrated directly within the ClearGlass platform.
Hi-Fidelity Designs Across Three Sides of the Market
Designing the high-fidelity experience for the Queries Hub required careful consideration of the three interconnected sides of the market interacting within the platform - asset managers, asset owners, and internal operational teams. While the core communication framework remained consistent, each side of the ecosystem had different operational goals, levels of visibility, permissions, and context requirements within the reporting lifecycle.
One of the key challenges was creating a unified communication experience that could remain coherent across the platform while still adapting to the specific needs of each user group. Internal teams required detailed operational visibility and workflow management capabilities, asset managers needed clear guidance around submission issues and requested actions, while asset owners required transparency into progress and reporting readiness without unnecessary operational complexity.
