Talmud
Flattening a 4-Level Hierarchy
into a Task-First Workspace
Led the information architecture redesign of a funding and eligibility platform
serving over 900 institutions, replacing a navigation tree users relied on but didn’t actually need.
Role: Lead Product Designer
Team: PM, 3 system analysts, 8 developers
Scale: 900+ institutions, ~30 internal users
Overview
Talmud is a Ministry of Education system
for managing eligibility, supervision and funding for religious institutions.
The system has two main types of users:
- Internal users – staff from the Senior Department of Religious Institutions at
the Ministry of Education. - External users – managers and secretaries of the organizations and religious
institutions.
The Organizations module is based on four main entities:
- Organization
- Institution
- Study Type
- Student
Client
The Problem
Users had to navigate multiple layers to access critical information and perform key actions, making the experience slow and the side navigation seemingly essential.
At this stage, my central question was simple:
Is the side navigation truly necessary for users, or could it be removed without impacting their ability to perform core tasks?
It wasn’t yet clear whether this was a navigation issue or a deeper problem, so I began by examining actual user workflows.
Users Research
I conducted qualitative research including:
- Interviews with Ministry of Education stakeholders
- Conversations with managers of large and small organizations using the system daily
- Observing how users completed tasks in the existing system
I focused on the organization user, responsible for the majority of operational tasks and direct reporting. To maintain empathy and guide decisions, I created a “mid-level” persona, representing users with average technical skills, workload, and goals. This persona served as an anchor in shaping the architecture, defining screens, and prioritizing information hierarchy.
Understanding the Existing System
The system relied on a side navigation presenting the organizational hierarchy. I mapped core user actions and observed how they were performed in practice:
Common actions:
Less common actions:
Initial findings:
users relied heavily on the side navigation. It appeared central and necessary for orientation and task completion.
Key Insight
Despite the side navigation being used consistently, something about this conclusion felt incomplete to me. Users did rely on the navigation tree, but almost always out of necessity to reach specific information or perform a particular action, rather than as a deliberate or convenient choice.
I paused and asked myself:
Is the navigation tree truly the solution, or simply the only way to cope with a deeply nested system structure?
At that point, I realized the initial conclusion was superficial:
The fact that a component is frequently used does not necessarily mean it serves users well.
Key insight:
The navigation tree is not the problem. it is a symptom of an information architecture that is too deep, forcing users to “dive” through multiple layers to perform everyday tasks.
Design Strategy
The system is built as a rigid hierarchy:
Each entity contains similar sub-items:
- Entity details
- Support status
- Nested entity lists
For example: To view the support status of a specific study type, the user must “dive” through the organization, the institution, and the study type.
I decided to change direction: Instead of pushing the user deeper into the hierarchy – to flatten it.
Solution
I designed a task-focused, flatter architecture.
Steps included:
This allows users to see a complete picture without navigating multiple layers.
Organization Details Hidden by Default
The organization details are hidden by default to prevent information overload and keep the main screen focused on the most frequently used actions. The information can be easily revealed when needed, without occupying valuable interface space.
Quick Access to All Three Levels
Even without the navigation tree, the layout enables quick access to the third level directly from the main screen, allowing users to reach detailed information without multiple navigation steps.
Challenges
Flattening the architecture created a new challenge: presenting a large amount of information clearly.
One of the most complex pages was Support Status, a core page with critical information across all entities.
I first tried an accordion view to reduce visual load. Users, however, could not get a full overview, and critical issues were missed.
After several iterations, I returned to a table view, which despite its density, allowed quick scanning, comparison, and problem detection, effectively serving users’ needs.
Outcome and Impact
4 → 2 clicks to view an institution’s support status
Viewing support status was one of the most common tasks in the system. Previously, users had to open the organization, go to its institutions list, select an institution, and then open its support status. In the new architecture, support status is a tab within the organization’s details, so users no longer need to drill down through the hierarchy.
When we reviewed the new screens with department staff before development, they said critical actions were clearer and easier to reach.
The flatter, task-focused architecture lets users work in context, so the system follows their goals rather than the underlying data hierarchy.
What I Learned
This case reinforced the importance of framing research questions around user needs, not system assumptions. Initially, I tested if side navigation was necessary. Research confirmed frequent use, but it didn’t address core user pain points.
By reframing the research question to explore which information architecture best supports workflows and decision making, I uncovered deeper friction points and designed an architecture that lets users complete everyday tasks without drilling through the hierarchy.