From new joiner to designing for a complex ESG product in one month

Image showing a team collaborating around a futuristic ESG reporting surface.

How structured onboarding, product mapping, documentation, and collaboration helped me become productive quickly in a complex ESG reporting product. 📈

Three months ago, I joined KINTO Join as a Senior UX/UI Designer, working on ZERO by KINTO.

Like any new role, there was a lot to learn: new people, new processes, new terminology, new ways of working, and most importantly, a new product.

But this was not just any product.

ZERO by KINTO operates in the world of ESG reporting, a space that combines carbon emissions, reporting frameworks, business processes, data collection, governance, and multiple user roles.

This is not a product you understand through casual clicking alone. It needs structured exploration, domain context, and a clear understanding of how workflows connect.

How do you become useful quickly in a product that takes time to understand properly? 🎯

Image showing a designer working between design tickets and a design tool.

For me, the answer was structure.

I did not try to learn everything at once. I focused on mapping the product, completing realistic user tasks, asking better questions, and learning from the people who already held the context.

The complexity behind ESG

B2B SaaS products are already challenging to onboard into because they often come with specialised users, business-specific workflows, and technical terminology. ESG reporting adds another layer.

At first, the goal sounds simple:

Help organisations measure and report their carbon emissions.

Image showing a complex carbon reporting dashboard connected to multiple ESG data sources.

But behind that simple goal sits a lot of complexity.

Carbon reporting involves different scopes, categories, methodologies, data requirements, calculation logic, and reporting responsibilities. A simple example is transport-related emissions.

Scope 1 Mobile Combustion and some Scope 3 categories can all involve vehicles, fuel, travel, or transport activity. To someone new to the space, they can sound almost the same, but they are not.

• Scope 1 Mobile Combustion usually relates to company-controlled vehicles, such as company-owned, leased, or company-issued vehicles.
• Scope 3 transport-related categories may involve employee-owned vehicles, contractors, suppliers, or third-party transport providers.

That difference matters because it can change the user journey, the data required, the evidence needed, and the calculation pathway.

Image showing two similar dashboards with different reporting logic.

That is the design challenge.

You are not just designing screens. You are helping users make the right reporting decisions in a complex environment.

AI adds another layer

When I joined, ZERO by KINTO was actively building a carbon calculation tool. In some ways, this helped. The product goal was clear.

Help organisations calculate, understand, and report their carbon emissions.

But a clear goal does not always mean a simple product.

A carbon calculator still needs to support different user roles, different data inputs, different reporting paths, and different levels of user knowledge.

On top of that, the product is also exploring how AI and automation can reduce repetitive admin and make carbon reporting less manual.

For a designer, that means asking two questions at once:

1. How does this process work today?
2. How could it become simpler tomorrow?

Image showing an AI-assisted workflow helping a user organise information across multiple tools.

What helped me move fast

The biggest reason I was able to start contributing within my first month was the onboarding.

Previous experience helped me recognise the type of complexity I was dealing with, but it was the onboarding process, documentation, product mapping, realistic user tasks, and collaboration that turned that foundation into contribution.

Good onboarding does not remove the complexity of a product. It reduces the friction around learning it.

I had access to documentation, product walkthroughs, internal knowledge, and colleagues who were willing to explain the context behind decisions.

That combination helped me move faster from:

“I am learning the product.”

to:

“I can start contributing to it.”

Screenshot showing design tickets assigned to me in Jira.

Mapping the product

One exercise helped me more than anything else.

→ Mapping the product journeys end-to-end.

I explored the platform with structure, taking screenshots of key pages, workflows, and states, then placing them into a large visual canvas.

The goal was not just to click around. ❌

The goal was to build a mental model. ✅

I wanted to understand:

1. how different areas of the product connect
2. where information flows
3. which workflows depend on each other
4. where complexity starts to appear

By turning the product into a visual map, I could understand it faster and refer back to it when new design tasks came in.

Screenshot showing the end-to-end mapping exercise.

Learning through real tasks

After mapping the product, I wanted to go one level deeper. ZERO by KINTO supports different user roles and permissions, so I wanted to understand the product through realistic user behaviour.

I asked two colleagues to give me real tasks:

• three from the Product Designer I work with
• three from the Product Owner

That changed the exercise. I was no longer asking:

What does this screen do?

I was asking:

What is the user trying to achieve, and where might they struggle?

This helped me understand real workflows faster and made the platform feel less like a collection of screens and more like a set of responsibilities, decisions, and user goals.

Screenshot showing the realistic scenarios exercise.

Docs helped. People helped more.

The design wiki and internal documentation were extremely useful. They gave me access to product knowledge, design decisions, terminology, and explanations I could return to whenever I needed them.

Screenshot showing our onboarding wiki.

But in a complex domain like ESG reporting, documentation alone is not enough. Some knowledge lives in conversations.

Sometimes you need someone to explain:

• why a decision was made
• how a customer thinks about a workflow
• where the edge cases are
• what the documentation does not fully capture

That is where collaboration became the real shortcut. 🤝

Having access to people across Product, Design, Engineering, and ESG helped me connect the dots faster.

Good onboarding is not just about giving someone information. It is about giving them access to the people who hold the context.

Screenshot showing the ZERO product flows.

What I’d tell other designers

Picking up design tickets within one month was not the result of one thing. It was the result of strong onboarding, useful documentation, structured product exploration, realistic user tasks, and good collaboration.

For any Product Designer joining a complex B2B SaaS product, my advice would be simple:

1. Don’t just read about the product.
2. Explore it with structure.
3. Map it visually.
4. Complete real user tasks.
5. Ask questions constantly.
6. Learn from the people behind it.

Because the fastest way to understand a product is not only to learn how it works. It is to understand why it exists, who it serves, and who builds it.