Apollo
A first-of-its-kind carbon credit platform that connects buyers directly to suppliers
Role: Product Design Lead
Company: Renoster
Example parcel eligible for enrollment in Apollo’s carbon program
Example Apollo carbon project overview
Context + Problem
Carbon markets are both high-stakes and hard to navigate.
For buyers, confidence is everything. They need to understand where their money is going, what science backs the credits, and whether the impact is real.
For landowners, the process is opaque. Many don’t know if their property is eligible, what joining a project entails, or what the financial upside could be.
Designing Apollo meant turning an unfamiliar, technical system into intuitive, trustworthy experiences for two very different user types.
The Product Challenge
How do we connect two product areas while giving non-technical users the power to create complex reports in a way that feels simple, transparent, and seamless across the product?
The design had to:
Connect two siloed product areas into a unified flow
Make complex data transformations approachable for non-technical users
Balance transparency (what’s happening to the data) with simplicity (don’t overwhelm users with SQL)
Scale as Preql added more metrics, dimensions, and integrations
Example risk, forecast, and credit issuance sections
Accordion / Preview interaction prototype
Guided Workflow
We designed a sequential guided flow where users complete one step before advancing. Each choice affects downstream options, simplifying decision-making. This reduced confusion and gave us flexibility to handle technical dependencies behind the scenes.
I explored stepper vs. accordion layouts. We chose an accordion because it neatly displayed all steps in one view, allowing users to orient themselves without losing context.
A live preview table reinforced transparency, letting users see real-time output of their choices.
Placement in the Product
I prototyped three options for housing the flow: side drawer, modal, and full page.
Side drawers were already used for quick edits, not creation.
Full page introduced too much navigation friction.
Modal aligned with existing patterns and kept focus on the task.
We chose the modal, reinforcing that this was a primary workflow that required user attention.
Accordion UI close-up
Modal option for Create Report
Handling SQL Complexity
One of the hardest decisions was how and when to expose SQL logic.
Joining data across applications often resulted in fewer available options.
We debated surfacing SQL warnings in v1, but chose to abstract them to avoid overwhelming users.
This was a deliberate tradeoff: prioritize user momentum now, while leaving space to introduce progressive disclosure for advanced users later.
Example of warnings as a result of SQL logic (for future implementation)
Outcome
The final design connected Definitions and Reports in a single flow that felt approachable yet powerful. By combining a guided accordion, live preview, and focused modal workflow, we gave users confidence in building reports without needing SQL knowledge.
Impact (based on user interviews and qualitative evidence):
Report creation adoption increased
Reduced time manually editing report columns
Internal alignment around a repeatable design framework for future features
Reflections
Looking back, I’m proud of how the design balanced technical depth with usability. If I were to iterate further, I would:
Introduce progressive disclosure of SQL logic for power users
Explore more direct editing of report components post-creation to reduce dependency on the modal flow
Conduct deeper usability testing with larger e-commerce teams to validate scalability under heavy data loads
Final design video
Contributions and team
I designed all information architecture, UI/UX, and interaction aspects of the Create Report modal flow. I collaborated closely with a UI designer to create the final table view in Reports. I also worked closely with a product manager, front-end engineer, and data engineer.