Before payment
Verify eligibility per student
Update system statuses
Ensure all suspensions were properly recorded
Validate payment against the monthly budget
Led the redesign of a monthly grants payment module, surfacing errors before execution and replacing a manual review screen with automated eligibility logic.
Role: Lead Product Designer
Team: PM, 3 system analysts, 8 developers
Status: In acceptance testing
Kohelet is a sub-system within the governmental Talmud platform, designed to manage monthly financial support grants for underprivileged Torah students.
The system is responsible for data collection, eligibility calculations, and managing a complex payment process that includes recurring monthly payments, handling payment failures, and managing debts accumulated from previous months.
Payment instructions are generated in Talmud–Kohelet and sent to the Sigma (Merkava) system, where payments are executed in practice.
At the start of the project, users expressed resistance to change, stating that the existing system fully met their needs. However, a deeper examination of workflows and screens revealed a more complex challenge.
Many screens were structured around the database schema rather than users’ workflows. Recurrent failures in the payment process were identified, along with critical information that was only available through external reports and a lack of hierarchy that caused overload in critical screens.
Above all, the system lacked information that would provide clarity and confidence when performing high-stakes actions such as payments.
The primary users of the payments module are two employees in the Department for Torah Institutions at the Ministry of Education, responsible for managing and executing support payments. Both have relatively low digital proficiency but a very high dependency on the system for their daily work.
They developed deep trust in the existing tool and repeatedly emphasized during interviews that payments are perceived as high-risk actions with zero tolerance for errors.
As a result, any system change triggered concern about disrupting process stability. The resistance to change did not stem from unwillingness to improve, but from a strong need for safety, control, and certainty in a critical workflow.
In the initial mapping, I identified five types of payment-related screens:
Although recurring payments occur only once a month, they act as a central trigger for all other payment flows. Improving this screen could significantly reduce pending and exceptional payments, so I chose to start there.
Throughout the process, I kept three notes pinned next to my workspace:
Recurring payments are executed once a month but involve a lengthy preparatory process across multiple stakeholders. In practice, the moment of truth is a single click – but before that, several critical conditions must be verified:
Only then is the payment request sent to Sigma, and the payment is executed a few hours later.
As part of the process, I created a table mapping users’ core needs at each stage of the payment flow:
Verify eligibility per student
Update system statuses
Ensure all suspensions were properly recorded
Validate payment against the monthly budget
Confirm that data was successfully transferred to Sigma
Verify execution
Identify failures returned to the system
This mapping informed the content definition for the new screen and guided a focused, user-centered design.
The existing screen was presented as a static 12 month table – a structure based on system data architecture rather than users’ mental models and workflows. Based on the mapped needs and content definition, I designed a new screen inspired by payroll and monthly payment systems.
The goal was to support users throughout the entire payment lifecycle – before, during, and after execution – by clearly communicating what will happen, current status, and outcomes.
Through a broad sketching process (6-up), I narrowed down to three concepts, and from them selected one that best reflected user needs across the full flow.
Early testing revealed friction. Conversations with users uncovered that the recurring payments screen also served as a yearly tracking tool, allowing them to review payments and cumulative totals across months. The 12-month table supported this need, which was not otherwise addressed in the system. This insight led to a key decision: separating action-oriented screens from a dedicated historical data view.
At this stage, it became clear that the challenge went beyond a single screen and required a broader system-level approach. To maintain long-term user confidence and control, two complementary solutions were needed: a dedicated screen for historical payments and a clear navigation mechanism that centralized all payment-related screens.
After studying user behavior, I identified the need for a clear cognitive separation between action screens and historical views, and led a system-level decision to organize the interface using top navigation tabs.
This solution clearly distinguished active payment actions from historical data, enabled immediate visibility into pending tasks per screen, and maintained a clean, focused interface without information overload.
Retroactive payments emerged as one of the most sensitive areas in the system. Unlike recurring payments, they represent retroactive fund transfers – debts owed by the department to students – making users especially cautious and skeptical.
Interviews revealed low trust in the data presented on the screen. Despite the system providing payment records, users performed additional manual checks – sometimes outside the system – before approving payments. As one user put it:
Mapping retro payment sources revealed four distinct entry points, each perceived with a different level of reliability:
While some records were automatically streamed into the retro payments screen, others required manual judgment and external validation. A key insight was that not all records were perceived as equally trustworthy; their source directly affected user confidence.
To understand this gap, I mapped pain points and validation steps per retro type – many occurring outside the system (see table).
From this mapping, a clear goal was defined for the retro payments screen:
Present only verified data, enabling users to approve payments with confidence – without external checks or fear of errors.
At this stage, I focused on the “Retro Recommendation” screen. Initially, users described it as a critical review layer: a safeguard before approving sensitive retroactive payments.
However, interviews revealed that in practice, only students with retroactively updated attendance reached this screen. The user’s sole action was to verify eligibility in Kohelet and then forward the record to the retro payments screen.
This exposed a consistent logic that the system itself could perform. I identified an opportunity to replace manual checks with automated logic based on clear rules – without compromising control.
Working with system analysts, we defined an alternative: when attendance in Talmud changes retroactively from negative to positive and eligibility exists in Kohelet for the same month, the record is automatically transferred to the retro payments screen.
This eliminated an unnecessary step, reduced cognitive load, and strengthened user trust – while maintaining the same level of control at significantly lower operational cost.
After defining requirements and content, I moved into UX sketching. A key challenge emerged: representing retro payments for a single student eligible for multiple months. In the existing system, each month appeared as a separate record, causing duplication, visual clutter, and difficulty understanding overall eligibility.
Research showed that although payments are executed monthly, users think and decide primarily at the student level, and only then review individual months. The interface needed to support both mental models simultaneously.
I explored multiple representations and selected a unified row per student with an expandable detail view. This allowed quick scanning of students while enabling focused review of all eligible months within a single context. Checkboxes inside the expansion enabled full or partial payment selection per month.
This approach consolidated fragmented data into a coherent structure, reduced visual noise, and minimized potential errors – while aligning precisely with how users scan, reason, and make decisions in a sensitive workflow.
Kohelet is currently in acceptance testing. Impact on payment errors will be measured after launch.
What changed
Retro Recommendation screen removed
Replaced by an automated rule defined with the system analysts. When attendance changes retroactively from negative to positive and eligibility exists for the same month, the record moves to Retro Payments automatically.
Errors flagged before transfer
Payments that previously failed only mid-transfer are now flagged before the payment is sent, giving users the chance to fix them and include them in the same transfer.
Action separated from history
Payment actions and the yearly tracking view now live in separate tabs.
Building trust through involvement
Users who initially rejected any change took part in research, process mapping and sketching. After testing an interactive prototype, they approved the new screens and expressed high satisfaction with them.
This project reinforced a key insight: user resistance to change often stems from the effort required to adapt to a new interface – especially when users are accustomed to systems that speak a different “language” than their own. In the existing system, users had undergone a long and difficult adaptation process, which created fear of making new mistakes.
I learned to treat resistance as valuable input rather than an obstacle. By listening to users’ concerns and designing solutions that reduce risk and uncertainty, I helped them move from complete resistance to approving the new screens after testing them in a prototype.