SKIZI
SKIZI (Green Instruments Usage Coordination System) is a system for accounting green certificates and rights. It allows rights to be transferred between owners and redeemed, meaning marked as used when a company needs to confirm its green energy consumption. I was the sole designer on the project and led it from scratch to launch over one and a half years.

About the Project
This project is compelling because of a complex domain and an extended role model with cross-system flows. It also involved a public-sector client and a lot of specialized terminology. My task was to design the system so users wouldn’t drown in its layers and could operate their green instruments with confidence.
A Bit of Context
When a solar or wind plant generates energy, it is considered “green” because it comes from a renewable source. A company that wants to prove it consumes this kind of energy buys the rights in the form of a green certificate or a green contract. In SKIZI, these rights are issued, transferred between owners, and redeemed. Every operation involves a chain of participants: the producer, the buyer, the operator, and the guaranteed supplier. Each has a distinct role and set of actions in the system.
Tender
The project began with a tender: in three days, we had to design several system screens and explain how the product would work. I prepared these mockups for the tender (and we won 😎):
Role Model
Then the real product work began: we incorporated all functional requirements and built the role model. We ended up with seven roles, each with different permissions:
- •Unregistered user
- •User without a personal account
- •Client
- •Generation Facility Owner
- •Guaranteed Supplier/TSO
- •Operator
- •Administrator/Super Administrator.
Each role has its own feature set and information access level. These permissions can be changed by a super administrator on the Role Management page.

Green Certificates
This is the core object in the system (alongside green contracts). Every certificate has its own nominal value, unique number, energy type, generation facility, and more. Once you open a certificate, there are many available actions, but the key ones are split and redemption. Both can be done manually or automatically, and in both scenarios we reduce friction with prefilled fields, alerts, and auto-calculation (“Split equally”).
If there are many certificates, the same actions can be applied to a group at once, without opening each one individually.
Bulk redemption (1-4) and split (5-6)
Green Contracts
Unlike a certificate, a contract is not static: every month it receives a new volume of green energy that must be paid for. Visually, I kept it close to the certificate pattern for consistency, but moved the new volume into a separate orange block so it immediately gets attention.
Inside, there is an Attribute Realization (AG) block and the ability to pay for it. Several entries can accumulate if payment is delayed. All actions are stored in Operation History.
Green Contracts Under the Hood
Each contract follows a chain: the operator submits monthly data for the new volume, the Guaranteed Supplier verifies and signs with an e-signature, and then the data is delivered to the Client and the Generation Facility Owner. I designed all sides of this flow so each role clearly sees what it needs to do and understands the current payment/submission status.
Generation Facility Owner and Facilities
For the Generation Facility Owner, the main flow is working with generation facilities. Fuel and commercial metering submissions are handled at section level, so data can be submitted for all facilities at once (including via file upload). Inside each card: production chart, free and blocked generation attributes, and all actions in one place - issue a certificate, configure auto-issuance, and check why something was blocked. If something needs attention (for example, activation payment), we surface it with an alert and a clear status.
Facility Registry
The generation facility registry is available to everyone, including unregistered users. I proposed two views: a Russia map with regional heat coloring and a filtered list. The map gives a fast visual overview, while the list supports precise search. Data export is available from both views, and filters persist when switching between them.
User Profile
The profile is organized into tabs, and each role has its own set. Three base tabs are shared by all users: general info with documents and e-signature, payment account (funds, top-up details, payment history), and personal accounts (green instruments and energy operations). Money and generation attributes are separated as two different asset types. The Generation Facility Owner gets an additional analytics tab.
Audit
Every action in the system is logged, so the super admin has a dedicated Audit section. Each record includes detailed operation data with links to related objects, and both the request and signature can be downloaded directly from there.
Outcome
The project is live in production. It was a complex and genuinely interesting case: a domain I had to learn from scratch, public-sector constraints, technical and legal limitations, and even a leadership change in the company in the middle of development. I also attached extra mockups below so this project stays memorable, for you and for me.
Other Projects
All Projects
Glacis Labs dApp
A dApp for tracking cross-chain transactions and analytics. UX, UI, brand identity.

Glacis Labs site
Corporate website for Glacis Labs. A multi-page site with complex diagrams and widgets.

xSwap
AMM on CrossFi network. Swap, pools, and veToken voting – design and launch in 1 month.



















































