KKL
KKL’s teams define each call - its requirements, documents, budget rules and evaluation process. Applicants use the same system to understand what’s required and submit their proposal.
I designed both experiences as one connected process, making a complex workflow easier to manage and easier to follow.
KKL-JNF manages public calls that support environmental and community projects. Each call brings together applicants, internal teams, reviewers and committees through a structured process- from defining the requirements and receiving proposals to evaluation, approval and contract.
I designed the UX/UI for the full platform as part of a team at Comrax, connecting the different users and stages into one clear process.
Before the new platform, much of the ‘call for proposals’ process relied on manual work across documents, emails and separate workflows. Information had to move between teams and applicants, making it harder to keep requirements, submissions and reviews aligned.
Setting up and managing each call required repeated work across different stages and teams.
KKL’s requirements had to match exactly what applicants submitted.
With many stages, users and decisions involved, it was difficult to maintain a clear view of status, progress and history.
Create one connected process where the rules defined by KKL guide everything that follows. From what applicants see and submit to how each proposal is reviewed and evaluated.
The call is built once by KKL’s team. From there, the system uses those definitions to create the relevant submission process. Including fields, documents, eligibility rules, budgets and evaluation criteria.
Build the submission flow in stages, define the fields applicants need to complete, and decide what is required for each call.
Applicants move through a guided form based on the structure and requirements defined specifically for that call.
Define who can apply, from municipalities and NGOs to companies, and the requirements they need to meet.
Applicants see the relevant threshold conditions and requirements before moving through the submission process.
Set the funding model, limits and participation percentage, including different rules for different types of calls and applicants.
Funding amounts are validated against the call’s limits and funding percentage, helping identify issues before submission.
Define the documents each type of organization needs to provide, so requirements can change according to who is applying.
The required-document list adapts to the applicant’s legal entity type and other choices made during the submission.
Build the evaluation model in advance, including criteria, sub-criteria, weights and the data used for scoring.
The information submitted by applicants is structured around the same rules and criteria KKL uses later in the process.
Before designing the platform, I needed to understand how KKL’s calls actually work. The rules, users, documents, budgets and decisions that shape the process.
Key insights
Each call can have different fields, documents, budgets and scoring criteria, but they all follow the same overall lifecycle.
The applicant’s entity type affects the documents and requirements they see throughout the submission.
With multiple stages, requirements and deadlines, the experience needed to make it clear what is required, what has been completed and what comes next.
The project involved a large amount of documentation, requirements and complex business logic. I used AI throughout the process to organize information, explore directions and speed up repetitive work, while keeping the UX decisions, priorities and final design choices in my hands.
The platform serves two very different users. Applicants need a clear, guided experience that makes a complex submission easier to complete. KKL teams need information-rich screens that help them manage calls, submissions and decisions efficiently.
Both sides share the same system and logic, but each interface is designed around the work its users need to do.
The platform uses one shared component library across the KKL team and applicant experiences. Forms, tables, steppers, statuses and actions follow the same patterns, while adapting to the different needs of each side.
Every component was designed for RTL and includes the states needed for a complex system. From validation and errors to disabled and read only states.
Digital submission flow - from registration and drafts to final submission.
Definition drives both sides - what KKL defines becomes what applicants see and submit.
Legal entity types supported through one adaptive submission flow.
Change is tracked, creating a clear history of updates, actions and statuses throughout the process.
The platform brings a complex process into one structured system. Applicants get clearer guidance and immediate feedback, while KKL teams can create and manage new calls through configurable rules rather than rebuilding the process each time.
Understanding the process in depth before designing. The different entity types, documents, budget rules and dependencies helped me make better UX decisions and build flows that could support different types of calls without redesigning them each time.
I would expand user testing with real applicants across different entity types, using their feedback to further refine the language, guidance and more complex submission scenarios.
