Category
UI/UX Design, Banking, FinTech
Responsibility
UI/UX, Flow Design, Prototyping, Design System
Designing an End-to-End Mitra Kerja Sama Workflow
Designing an End-to-End Mitra Kerja Sama Workflow
Designing an End-to-End Mitra Kerja Sama Workflow
Mitra Kerja Sama Workflow is an enterprise system within BRISPOT used to manage the entire collaboration process with external partners, from registration and multi-level approval to agreement document management. The workflow supports three distinct roles like Maker, Checker, and Signer across multiple partner segments, including Notaris, KJPP, and Akuntan Publik.
Mitra Kerja Sama Workflow is an enterprise system within BRISPOT used to manage the entire collaboration process with external partners, from registration and multi-level approval to agreement document management. The workflow supports three distinct roles like Maker, Checker, and Signer across multiple partner segments, including Notaris, KJPP, and Akuntan Publik.
Key design challenges
Key design challenges
Key design challenges
One workflow multiple roles and different requirements
One workflow multiple roles and different requirements
Mitra Kerja Sama process involves multiple users with different responsibilities and decision making authority.
The Maker is responsible for preparing and submitting the application, while the Checker reviews and verifies the submitted information before the Signer provides the final approval.
At the same time, each partner segment requires different information and documentation throughout the registration process. This created a complex workflow that needed to balance:
• Different responsibilities across Maker, Checker, and Signer
• Different registration requirements for each partner type
• Multi-level approval based on the submission unit
• Large amounts of partner and legal information
• Document processing through the TDR/PKS stage
Mitra Kerja Sama process involves multiple users with different responsibilities and decision making authority.
The Maker is responsible for preparing and submitting the application, while the Checker reviews and verifies the submitted information before the Signer provides the final approval.
At the same time, each partner segment requires different information and documentation throughout the registration process. This created a complex workflow that needed to balance:
• Different responsibilities across Maker, Checker, and Signer
• Different registration requirements for each partner type
• Multi-level approval based on the submission unit
• Large amounts of partner and legal information
• Document processing through the TDR/PKS stage
Approach
Approach
Approach
Mapping roles and approval hierarchies
Mapping roles and approval hierarchies
First step was mapping out who does what at each unit level. Checker and Signer structures differ depending on whether the application comes from Kanca, Kanwil, or Kanpus. An application from a branch, for instance, goes through the branch Checker, then a Kanwil Checker, then the Kanwil cRO as Signer.
Kanpus applications follow their own path all the way up to CRO. This mapping became the foundation for how a Maker selects a Checker and Signer at the end of registration, and how application status shifts at each approval stage.
First step was mapping out who does what at each unit level. Checker and Signer structures differ depending on whether the application comes from Kanca, Kanwil, or Kanpus. An application from a branch, for instance, goes through the branch Checker, then a Kanwil Checker, then the Kanwil cRO as Signer.
Kanpus applications follow their own path all the way up to CRO. This mapping became the foundation for how a Maker selects a Checker and Signer at the end of registration, and how application status shifts at each approval stage.
An application list and status system every role can track
An application list and status system every role can track
Maker, Checker, and Signer all open the same Cooperation Application List, but each needs something different from it. So I designed the page around two main tabs Proses Registrasi dan Proses TDR/PKS with clear statuses at every stage (Draft, Terkirim, Dikembalikan, Pending Checker, Pending Signer, Ditolak). The goal is each role can immediately spot the applications that need their attention, without opening every record one by one.
Maker, Checker, and Signer all open the same Cooperation Application List, but each needs something different from it. So I designed the page around two main tabs Proses Registrasi dan Proses TDR/PKS with clear statuses at every stage (Draft, Terkirim, Dikembalikan, Pending Checker, Pending Signer, Ditolak). The goal is each role can immediately spot the applications that need their attention, without opening every record one by one.
Making a long registration form easy to navigate
Making a long registration form easy to navigate
Registration form isn't short, there is informasi umum, PIC mitra, CIF, profil mitra & informasi kerja sama, informasi rekanan, informasi perizinan dan legalitas, and kelengkapan dokumen. I designed step navigation that clearly shows fill in progress, letting the Maker jump back to any completed step without losing data.
Registration form isn't short, there is informasi umum, PIC mitra, CIF, profil mitra & informasi kerja sama, informasi rekanan, informasi perizinan dan legalitas, and kelengkapan dokumen. I designed step navigation that clearly shows fill in progress, letting the Maker jump back to any completed step without losing data.
Designing the handoff between Maker, Checker, and Signer
Designing the handoff between Maker, Checker, and Signer
Before submitting, the Maker has to name the specific Checker and Signer who'll process the application (by name/employee ID), and once it's sent, the status automatically switches to "Pending Checker".
Checker and Signer then get access to the exact same review page with the data the Maker entered, with three clear actions (Ditolak, Dikembalikan, and Setujui).
Before submitting, the Maker has to name the specific Checker and Signer who'll process the application (by name/employee ID), and once it's sent, the status automatically switches to "Pending Checker".
Checker and Signer then get access to the exact same review page with the data the Maker entered, with three clear actions (Ditolak, Dikembalikan, and Setujui).
Issuing TDR/PKS documents
Issuing TDR/PKS documents
The experience does not end when the Signer approves the registration. Approved partners continue into the TDR/PKS stage, where the system manages the agreement document process. After approval, the Checker can assign a Maker responsible for uploading the agreement document. The selected Maker can then download the appropriate template, upload the signed document, and submit it for verification.
The document requirements also vary by partner type:
• Notaris / Notaris & PPAT: TDR
• KJPP: PKS
• Akuntan Publik: PKS
Once the document is verified and approved, the partner status moves to “Terdaftar”.
The experience does not end when the Signer approves the registration. Approved partners continue into the TDR/PKS stage, where the system manages the agreement document process. After approval, the Checker can assign a Maker responsible for uploading the agreement document. The selected Maker can then download the appropriate template, upload the signed document, and submit it for verification.
The document requirements also vary by partner type:
• Notaris / Notaris & PPAT: TDR
• KJPP: PKS
• Akuntan Publik: PKS
Once the document is verified and approved, the partner status moves to “Terdaftar”.
Prototyping and cross role validation
Prototyping and cross role validation
I built an interactive Figma prototype simulating the full flow from all three roles at once, Maker filling out and submitting, Checker and Signer approving, and the final TDR/PKS process to validate that the handoffs and status transitions were clear and consistent before this went into development.
I built an interactive Figma prototype simulating the full flow from all three roles at once, Maker filling out and submitting, Checker and Signer approving, and the final TDR/PKS process to validate that the handoffs and status transitions were clear and consistent before this went into development.
Feeding into the design system
Feeding into the design system
Patterns like the application status card, status badges the multi-step form, and approval components have clear reuse potential across other BRISPOT modules. I documented them into the design system, including state variations and usage guidelines, to keep other teams consistent.
Patterns like the application status card, status badges the multi-step form, and approval components have clear reuse potential across other BRISPOT modules. I documented them into the design system, including state variations and usage guidelines, to keep other teams consistent.
Project impact
Project impact
Project impact
• Every role always knows what's expected of them, with clearly defined status indicators at each stage.
• Tiered approval structures (Kanca/Kanwil/Kanpus) were folded into a single flow.
• The long registration form stays easy to navigate.
• Different document requirements per partner segment are handled automatically at the flow level.
• Key components are now documented in the design system.
• Every role always knows what's expected of them, with clearly defined status indicators at each stage.
• Tiered approval structures (Kanca/Kanwil/Kanpus) were folded into a single flow.
• The long registration form stays easy to navigate.
• Different document requirements per partner segment are handled automatically at the flow level.
• Key components are now documented in the design system.
Category
UI/UX Design, Banking, FinTech
Responsibility
UI/UX, Flow Design, Prototyping, Design System
