Comet 1.0
Comet is a standalone web platform designed to forward-model rock mineralogy from geochemical assay data using thermodynamic modelling and domain-specific scientific logic.
Exploration companies already collect vast amounts of geochemical data through drilling campaigns and laboratory analysis. However, translating this chemical data into meaningful mineralogical understanding remains a complex, time-consuming, and often subjective process. In many cases, interpretation relies on a combination of manual logging, specialist laboratory techniques, and the experience of a small number of domain experts.
Comet was conceived as a way to operationalise that expertise. Working alongside Dr Scott Halley, I helped design a product that enables users to derive quantitative mineralogical insight directly from assay data in a way that is fast, repeatable, and scalable across large datasets. The challenge was not simply computational. It required turning a highly specialised scientific process into a usable product without losing the nuance and control that technical users expect.
Why this product needed to exist
Section titled “Why this product needed to exist”Geochemical assays are one of the most widely collected datasets in exploration. Every drilling program produces large volumes of chemical measurements, often across multiple projects and timeframes. Despite this, the ability to consistently interpret that data into mineralogical context remains limited.
Traditional approaches rely heavily on subjective interpretation or expensive laboratory techniques such as hyperspectral scanning. While effective in specific contexts, these methods do not scale easily and often introduce variability between teams, projects, and interpretations. As a result, geochemical data is frequently underutilised, with valuable signals remaining difficult to extract in a consistent and timely way.
Comet explored whether thermodynamic modelling could provide a more systematic pathway from chemistry to mineralogy. Rather than replacing geological expertise, the intention was to support it by introducing a consistent analytical layer that could be applied across datasets, enabling faster and more comparable interpretation.
My role
Section titled “My role”My role focused on translating a complex scientific workflow into a coherent product experience. This involved defining the structure of the workflow, designing the interaction model for configuring and running calculations, and ensuring that outputs could be understood and validated by users with varying levels of technical expertise.
The work extended beyond interface design into product definition, as many of the core decisions related to how the scientific model would be exposed, constrained, and operationalised within a commercial tool.
Product constraints
Section titled “Product constraints”Comet was intentionally scoped as a focused, high-value release designed for rapid market entry. This introduced several constraints that significantly shaped the design.
The system required users to upload data in a strict CSV format, with no column mapping flexibility in the initial version. Processing was asynchronous, with calculation times ranging from seconds to potentially hours depending on dataset size. The product did not include in-app visualisation, instead relying on users to export results into their existing tools such as Leapfrog or ioGAS. Billing was handled through a manual credit allocation system rather than integrated payments, and enterprise considerations around data privacy and intellectual property added additional complexity.
These constraints meant the design could not rely on flexibility or feature breadth to create usability. Instead, the focus was on making a constrained system feel predictable, reliable, and easy to reason about.
Defining a new workflow
Section titled “Defining a new workflow”Unlike many of Fleet’s other products, Comet did not have an existing workflow to refine. The product required defining a new operational model for mineralogical modelling from first principles.
At a high level, the workflow followed a simple structure: data is uploaded, validated, configured, processed, and then downloaded. However, within that structure, users needed to make a series of important decisions about how the modelling should be performed.
This included selecting an appropriate mineral system, configuring parameters such as temperature and mineral inclusion, and understanding how those choices would influence the resulting outputs. The system needed to support both rapid execution for common use cases and deeper configuration for expert users, without becoming fragmented or difficult to navigate.
A significant part of the design effort focused on ensuring that this workflow felt coherent, with clear relationships between each step and minimal ambiguity about what the system was doing at any point in time.
Translating scientific modelling into UX
Section titled “Translating scientific modelling into UX”Comet operates at the intersection of geochemistry, thermodynamics, and data modelling. The core challenge was not only to execute the calculation correctly, but to help users understand how modelling assumptions influenced the results.
The interface needed to support concepts such as mineral system selection, temperature-dependent stability, and configurable modelling assumptions, all of which have a direct impact on the calculated mineralogy. Presenting these concepts required careful balance. Too much abstraction would reduce trust, while too much detail would overwhelm users and slow down workflows.
Particular attention was given to how parameter changes affect outputs. For example, temperature selection can significantly alter predicted mineral assemblages, and this relationship needed to be communicated clearly without requiring users to have deep thermodynamic knowledge. The goal was to provide enough visibility for users to reason about the model, while keeping the workflow operationally efficient.
Designing for trust
Section titled “Designing for trust”Trust was a central concern throughout the design process. In exploration and mining contexts, interpretation errors can have significant financial and operational consequences, and users are understandably cautious of systems that obscure how results are generated.
For this reason, Comet was deliberately designed to avoid a black-box experience. Users are able to see and modify the assumptions that drive the model, review the conditions under which calculations are performed, and export results for independent validation.
The workflow emphasises transparency through parameter visibility, editable configurations, and clear outputs that can be compared and interrogated outside the system.
Workflow architecture
Section titled “Workflow architecture”The product needed to support iterative scientific reasoning rather than a simple linear task flow. Users often move back and forth between data preparation, configuration, and interpretation as they refine their understanding of the dataset.
To support this, the workflow was designed to maintain clear relationships between inputs, assumptions, and outputs. Decisions made during configuration are reflected in the resulting data, allowing users to trace how changes in parameters affect outcomes.
This structure helps maintain coherence across the workflow and reduces the cognitive load associated with managing multiple modelling scenarios.
Designing for multiple expertise levels
Section titled “Designing for multiple expertise levels”Comet needed to accommodate users with a wide range of technical backgrounds. Some users required quick, repeatable results with minimal configuration, while others needed deeper control over modelling parameters.
This was addressed through progressive disclosure. Preset mineral systems and default configurations provide a starting point for most workflows, while additional controls allow more experienced users to refine assumptions as needed.
The intention was to support both speed and depth without forcing users into a single mode of interaction.
Visualising uncertainty
Section titled “Visualising uncertainty”Scientific modelling inherently involves uncertainty, and the design needed to reflect this without undermining confidence in the system.
Rather than presenting outputs as definitive answers, the product supports interpretation through structured outputs that can be compared, validated, and analysed further. This allows users to assess results within the broader context of their geological understanding and other available data.
What we didn’t build
Section titled “What we didn’t build”Several features were intentionally excluded from the initial release, including in-app visualisation, automated payments, flexible column mapping, and email notifications.
These omissions were not oversights, but deliberate decisions to reduce complexity and focus on validating the core value of the product. By narrowing the scope, the team was able to deliver a focused, high-value tool that could be brought to market quickly and iterated upon based on real usage.
Outcomes
Section titled “Outcomes”Comet established a usable and scalable workflow for mineralogical modelling from geochemical assay data. It enabled faster interpretation, improved consistency across datasets, and provided a foundation for integrating geochemical insights into broader exploration workflows.
More broadly, the project demonstrated that a highly specialised scientific process could be translated into a product without losing the rigour required by technical users.
Reflection
Section titled “Reflection”This project highlighted the challenge of designing for domains where complexity cannot simply be removed. Instead, the role of design is to structure that complexity in a way that remains usable, transparent, and reliable.
The success of the product was not defined by how much complexity was hidden, but by how effectively it was organised.