Emissions target management

Making a complex emissions management process understandable and operable.

Conceptual illustration of emissions data and administrative review software

Background

Korea assigns annual emission-reduction targets to companies that emit above a certain threshold and then tracks whether they meet them. This project sits on the administrator's side of that programme rather than the company's. The administrator distributes activity-data survey forms to companies, receives what comes back, reviews it, requests corrections, confirms the result, and passes a compiled file to the national energy agency. Those steps are spread today across separate spreadsheets, documents and inboxes. This system holds them in one administrator-facing site. This local web application uses example records to review the workflow; the operating scope and agency sharing format remain subject to agreement. Internal receipt and confirmation do not replace statutory submission or third-party verification.

Role: Project Manager / Service Designer
Team: Worked with frontend and backend engineers
Organisation: Korea Institute of Green Climate Technology
Timeline: October 2025–January 2026 · 4 months
Tools: Figma · AI-Figma MCP · Working local web application

Outcomes

Unified pre-designation monitoring, designation and appeal into a single administrator-facing site
Five tabs per survey case, with receipt, correction and confirmation reduced to one shared procedure
Absorbed the handoff to the national energy agency into the system as file generation, delivery and receipt records

An example survey in correction-requested status, with five survey tabs and a submit-corrections control — The five survey types keep their own review fields while sharing one receipt, correction and confirmation procedure. The company and survey data shown are examples.

The problem

The difficulty here was not the number of steps. It was that each step follows a different rule. Watching a company before it is designated, designating it, and handling an appeal against that designation all happen at different moments on different grounds. Which fields matter changes with the type of survey.

So the process joined up in the administrator's head and nowhere else. The data sat in spreadsheets, the justification sat in documents, and the current state of any given case sat in someone's memory. When the person changed, the thread broke.

How I approached it

I began by reviewing the legal framework of the emissions target-management programme and mapping the duties of the operations administrator and the programme administrator. I distinguished each role’s tasks, the information it needed to review and the grounds for its decisions, then used that structure to shape the workflow and screens from predesignation monitoring through designation and appeal.

The three screens below are that flow from the operator's side: a registration list that shows every case at its current stage, a designation created on the basis of a confirmed survey and linked back to it, and an appeal received against that designation on a connected record. Every company and record shown is example data used to check the workflow.

Survey registration list of ten example companies, showing each case's stage from draft to confirmed and a share checkbox enabled only on confirmed rows — Candidate and already-managed companies sit in one list, each at its own stage, and only confirmed cases can be selected for the agency handoff. The companies and statuses are example records.

Detail screen of an example designation in gazetted status, with its review basis, a link to the confirmed survey and the snapshot version — A designation records which confirmed survey, at which version, it was based on, so the grounds stay attached to the case. The designation shown is an example.

Receipt details of an example appeal: filing date, deadline, a link to the designation under appeal, the stated reason and a start-review control — An appeal is received as a record linked to the designation it contests, so its deadline and grounds are kept with that designation rather than in a separate file. The appeal shown is an example.

Each survey kept the content it needed, while receipt, correction requests and confirmation followed a shared procedure. Separating what was reviewed from how it was handled let different information fit a familiar workflow.

Review starts from what the company submitted: activity volumes, preliminary emissions, calculation method and evidence, year by year in one table. From there the case enters the same receipt, review, correction and confirmation procedure whatever its survey type.

Submitted activity table of an example survey in received status: three years of activity volume, preliminary emissions, calculation method and evidence rows, with a start-review control — Submitted activity data arrives as year-by-year volumes, preliminary emissions and their basis, and review starts from there; the screen does not decide statutory designation on its own. The values are example data.

I included delivery and receipt confirmation in the flow after review. Connecting the review outcome with the handoff record made it possible for the next person to see which material had been passed on and which decisions were already settled.

An example file marked as received, with generation details, delivery and receipt dates, and supporting records — File generation, delivery and receipt confirmation become part of the work record. This example uses fictional data and does not represent an actual transmission to, or receipt by, the energy agency.

The outcome

Survey material, review decisions, correction history and handoff records can be followed within one workflow. As an operator works through the sequence, the grounds for each decision remain attached to the relevant survey case.

Keeping a record from survey review to file handoff

Process

Map each role’s duties from the legal framework
I began by reviewing the legal framework of the emissions target-management programme and mapping the duties of the operations administrator and the programme administrator. I distinguished each role’s tasks, the information it needed to review and the grounds for its decisions, then used that structure to shape the workflow and screens from predesignation monitoring through designation and appeal.
Give different surveys a consistent review process
Each survey kept the content it needed, while receipt, correction requests and confirmation followed a shared procedure. Separating what was reviewed from how it was handled let different information fit a familiar workflow.
Treat the handoff as part of the work
I included delivery and receipt confirmation in the flow after review. Connecting the review outcome with the handoff record made it possible for the next person to see which material had been passed on and which decisions were already settled.

Result

Survey decisions, correction history and file generation, delivery and receipt records can now be followed within one workflow. Data and attachments are saved to the local server's disk, keeping the grounds for each decision attached to the survey as the operator works through it.

What I took from this work

This work sharpened my view that an operational workflow needs to preserve both the order of work and the reasoning behind decisions. Survey types may require different information, but the criteria for review need to remain consistent from receipt to confirmation. Including the handoff in that flow lets the next person follow the decisions already made.

Read the shared design perspective

G-SEED and emissions target management: a shared design approach

The two programs keep their own procedures. Both designs make the sequence visible, define what allows work to move forward, and attach decisions and records to the case they belong to.

G-SEED green building certification

Sequence of work: Application
Receipt
Self-assessment
Fee
Document correction
Site inspection
Evaluation result
Certificate issuance
Conditions for moving forward: Each stage becomes available when its data exists. Document correction returns to self-assessment so the review can continue.
Records that remain: Stage information, attachment metadata and correction records stay with the application, alongside its certification progress.

Read the G-SEED case