Israel Tax Authority: one personal hub for a citizen's taxes, refunds, grants and property

Rotem Elimelech (Rotem E) redesigned the personal tax hub of the Israel Tax Authority as a freelance UX and product designer in 2019 and 2020.

The hub is the personal area every Israeli citizen uses for income tax, VAT, refunds, work grants, property and correspondence with the Authority; its data comes from separate government departments, each with its own system and its own language.

The project ran under Tasc Consulting, which hired Rotem for the UX and the UI: three people, Rotem among them, did the UX, turning the departments’ spreadsheets into a product order; then Rotem alone designed the wireframes and the interface, and the design system that every service area shares.

Parts of the redesign shown in the Israel Tax Authority case study shipped to citizens.

Today Rotem is a freelance product designer (UX/UI) in Tel Aviv, Israel. The Tax Authority is the public-service part of his record: a product for millions of citizens of every age, in Hebrew, right to left, on old government systems, with accessibility rules and legal wording that cannot change. This page tells that story in text; the case study shows the screens.

View the Israel Tax Authority case study · About Rotem · Discuss a project

Relevant experience for your project

• Government and public-service UX. A citizen-facing hub for a national authority, for every citizen and every age, under public-sector accessibility rules and legal wording that could not change.
• One account from many systems. Income tax, VAT, refunds, grants, property and mail, each from a different department’s system, presented as one status with one structure.
• Complex information made readable. Statuses, files and refunds rewritten in the citizen’s words, so a person knows what is owed, due, pending or approved.
• Dashboards, tables and detail panels. An account overview, a status screen, file details, a refunds table, a mailbox, grant requests with a payment schedule, and property records with transactions.
• A design system for a large system. Colors, typography (Rubik), tables, forms, buttons and components, designed once for every service area, in Hebrew and right to left.
• Working inside a consulting engagement. UX defined with two other product people under Tasc Consulting, then the wireframes and the UI designed alone.

The Israel Tax Authority hub at a glance

What Rotem found, and what he built

When Rotem joined in 2019, the personal hub existed and was old: an old design, split by department, in the Authority’s own language. Income tax, VAT, grants, property and mail came from different systems, so no one saw one status. A citizen could not tell what was owed, due, pending or approved, and an inquiry to the Authority was lost between letters, calls and forms.

The redesign turned it into one account. A dashboard with the account status, and a status screen across VAT, income tax and the rest. File details and a refunds table with each request’s details. A mailbox tracking sent inquiries and incoming mail, and a notifications screen listing the Authority’s alerts. A work grants screen with requests and an eligibility panel with the payment schedule. A real-estate screen listing properties and transactions, with a property details panel of area, rooms and ownership. Under all of it, a design system: a color palette, UI elements from buttons up, and typography in Rubik.

Rotem’s role

The project ran under Tasc Consulting, which hired Rotem for the UX and the UI. Three people did the UX, Rotem among them: they took the departments’ spreadsheets and turned them into a product order, what belongs where and what a citizen needs to see first. Then Rotem alone designed the wireframes, the interface and the design system. Four sources fed the definition: the old hub and its data, what citizens did and where they got stuck; sessions with the Authority’s teams that own income tax, VAT, grants and property; research with citizens during the redesign; and other government hubs in Israel and abroad, studied for what to match and what to skip.

The problem, and the constraints

Five problems, one product. The data was split by department, with no single status. The language was the Authority’s, not the citizen’s. A citizen had no way to know the next step. Talking to the Authority lost inquiries between channels. And the design was old, twice over.

Four constraints shaped the design. Every citizen and every age, millions of people, on desktop and phone. Old government systems behind the hub, each with its own data model and limits. Public-sector accessibility rules and legal wording that could not change. And Hebrew, right to left, with numbers, dates and forms on every screen.

Product decisions

Four decisions Rotem made and would defend today.

1. One hub: overview first, detail on demand

The decision: Rotem built one account hub with overview states, drill-down details, correspondence and notifications, and supported the different service areas with one shared design system.

Why: citizens should not need to understand the boundaries between government departments to understand their own status, records or next steps. The account status comes first; a file, a refund, a grant or a property opens as a detail panel in the same structure, whichever department it comes from. The strongest alternative was designing for the desktop only and letting the phone cope: cheaper, and the citizens who only have a phone would have been left with the old hub.

Tradeoff: one structure for five departments means each department’s data has to fit a shared shape. The overview-then-detail pattern absorbs the differences: the overview is the same everywhere, the detail panel carries what that area needs.

Shown in the case study: Main flow (the dashboard, the account status, the file details, the refunds).

2. The citizen’s words, not the Authority’s

The decision: statuses and labels say what a thing means for the person, owed, due, pending, approved, rather than repeating the departments’ terms.

Why: the hub is used by every citizen, of every age and skill, most of them once or twice a year. A status they cannot read is a phone call to the Authority.

Tradeoff: the legal wording behind a status cannot change. The citizen’s word sits first, and the formal term stays available where the law needs it.

Shown in the case study: Main flow, Work grants and payment schedule.

3. Mail and notifications inside the hub

The decision: inquiries, replies and the Authority’s alerts are tracked in a mailbox and a notifications screen next to the account, not in a separate service.

Why: an inquiry is about a file, a refund or a grant the citizen sees in the hub; keeping the conversation beside the thing it concerns ends the loss between letters, calls and forms.

Tradeoff: the hub has to hold correspondence as well as records. The mailbox tracks sent and incoming items in one list, with the same table pattern as the rest.

Shown in the case study: Communications.

4. One design system for every service area

The decision: a color palette, typography in Rubik, tables, forms, buttons and components, designed once and used across taxes, refunds, grants, property and mail.

Why: five service areas from five systems would otherwise have looked like five products. One system is also what makes accessibility and right-to-left layout hold everywhere at once, instead of screen by screen.

Tradeoff: a system is slower to start than a screen; on a government product it pays back on every area that follows and on every rule it has to meet.

Shown in the case study: Design system.

What shipped, and what it did

Parts of the redesign shipped to citizens. This page documents the design work; no measured outcome is published here.

The facts on this page come from Rotem’s own account, the Israel Tax Authority case study and his career timeline. The figures inside the interface screenshots are demo content, not results.

Frequently asked questions

What did Rotem Elimelech design for the Israel Tax Authority?

The redesign of the citizen’s personal tax hub: the account dashboard and status, file details and refunds, the mailbox and notifications, work grants and the payment schedule, property and transactions, and the design system under all of it, as a freelance UX and product designer in 2019 and 2020, hired by Tasc Consulting; the UX with two other product people, the wireframes and the UI alone.

Is this case relevant to a government, public-sector or citizen-service product?

Yes. It is a citizen portal for a national authority: data from separate government departments presented as one account, under accessibility rules and legal wording, in Hebrew and right to left, for every citizen and every age.

Did Rotem design the design system himself?

Yes. The color palette, the typography in Rubik, the tables, forms, buttons and components were his design, made once for every service area; the UX was defined with two other product people.

Is Rotem available to design a similar public-sector or large-system product?

Yes, as a freelance product designer, on a retainer or for a defined project: a citizen or customer portal, an account dashboard over many systems, a design system for a large product, or the full product from research to UI. Availability and rates are on his profile.

Work with Rotem

For a team building a government service, a citizen or customer portal, an account over many back-end systems, or any large product that has to be understood by everyone, Rotem brings the whole product process, research, product definition, UX and UI design, and the experience of turning departmental spreadsheets into one account every citizen can read. Availability, rates and how he works are on his profile.

Discuss a project · All case studies