WHT Platform · KESt · Withholding tax reporting
Beabstracto was hired to lead UX; I led the UX work and coordinated another designer from my company, inside an engineering-led organization with developers, the PO, and the CEO. The engagement covered a new KESt reporting module for German income-related tax reporting to the BZSt and UX direction for evolving the established WHT Platform platform.
"Wait… this is just a prototype? I thought it was a real product." — Stakeholder @ Tier 1 Bank, New York
Why this case matters
Tax reporting at scale means SLA pressure, institutional trust, and compliance risk. The work had to make operational behavior explicit and actionable — not only screens.
Personas, processes, glossary, error mapping, and design principles became a decision framework the team could reuse for product direction.
UX architecture for German income-related tax reporting to the BZSt — a new layer in the WHT Platform ecosystem with validation-heavy, SLA-driven operational workflows.
UX modernization of a mature product with established users, legacy patterns, and workflows that must evolve without losing domain trust.
Shared language and prioritization rules from Sphere 1 later shaped Manage Reports and broader platform evolution — not a one-off discovery pack.
Tier-1 prospects needed to experience the direction, not imagine it. I built Manage Reports in TypeScript with realistic data and interactions so demos with institutions including Goldman Sachs and S&P Global felt like production software.
Main users were expert operational users — not casual consumers. They work with regulated workflows, deadlines, validation logic, audit trails, and technical evidence. The goal was not to hide complexity, but to make it manageable, inspectable, and safe.
Personas, processes, RACI, IA, glossary, error mapping, principles, and success indicators — the reusable logic before high-fidelity UI.
Jump to strategy layer →02Designing the operational core of KESt: the journey that became the TypeScript prototype for tier-1 stakeholders — find, validate, fix, approve, and trace thousands of reports under SLA pressure.
Jump to Manage Reports →I was brought in to make domain knowledge actionable — not to decorate screens. I built a decision framework through artefacts, aligned stakeholders on regulated trade-offs, and delivered a Manage Reports prototype that became the sales and MVP reference for KESt.
Glossary, taxonomy, and regulatory mapping (BZSt, ELMA, KESt, SLAs) so engineering, PO, C-level, and UX aligned on product behavior.
Personas, RACI, business processes, clusters, critical moments, UX tensions, and design principles — tacit domain knowledge made explicit and usable for product calls.
Information architecture and main journeys validated with stakeholders before high-fidelity UI.
High-fidelity Manage Reports experience — tier-1 stakeholders treated it as real product; it supported pitches and MVP direction.
I worked in three modes — facilitator, translator, and maker.
Structured working sessions with engineering, PO, and C-level to extract domain knowledge, surface trade-offs, and prioritize risks.
Turned regulatory and technical complexity into UX artefacts and product decisions the team could use daily.
Built the first high-fidelity TypeScript prototype for KESt so the team and prospects could experience the product instead of imagining it. The prototype helped validate the vision with tier-1 banking stakeholders and led to a longer Beabstracto engagement — continuing UX leadership from groundwork through product direction and MVP definition, while also contributing to the broader WHT Platform platform modernization with a reconstructed UX direction for the mature product.
Sphere 1
Before designing screens, I needed to understand what the product should optimize for: speed, safety, guidance, flexibility, automation, transparency, SLA visibility, operational throughput, or compliance confidence. In a regulated finance environment, these are not visual preferences — they are business decisions.
The problem was not missing domain expertise. The UX logic behind the product was not yet explicit, reusable, or tied to business and product decisions.
I used UX artefacts as decision tools. Personas clarified prioritization. Business processes showed where value and SLA risk live. Error mapping named failure points. UX tensions became principles. Information architecture linked roles, tasks, and product areas into reusable logic.
Strategic questions
Questions that guided the foundations work with engineering, PO, and leadership.
Each question connected to artefacts that made decisions traceable — reusable logic instead of reinventing rules per screen.
Who are we designing for?
Which workflows create value?
Where the system can't fail
Which trade-offs should the product optimize for?
What needs to be visible to prevent SLA risk?
How do we make decisions reusable across the product?
The strategy work followed a deliberate chain: each step created input for the next product decision, for both the new reporting module and platform modernization.
Without common language, UX, PO, engineering, and C-level could not align on product behavior.
To prioritize operational users, supervisors, and supporting roles based on frequency, impact, and business risk.
To stop discussing isolated screens and understand end-to-end workflows where value is delivered.
In tax/compliance workflows, failures can create SLA, legal, financial, and trust risks.
To turn business priorities into reusable rules such as safety over speed, transparency over abstraction, guidance over free exploration, and contextual visibility over minimalism.
To make strategy visible in the interface.
To connect UX quality with the value banks are willing to pay for.
Outputs that informed product direction — decision tools, not a checklist that stopped when discovery ended.
The artefacts were not independent deliverables. Each one created input for the next decision. Shared language made it possible to define personas. Personas clarified which business processes mattered most. Business processes revealed critical journeys and failure points. Failure points shaped UX tensions. UX tensions became design principles. Design principles then informed interface behavior — filters, validation states, role-based actions, audit trails, dashboards, and SLA visibility.
Aligned terms so product, engineering, and leadership could discuss the same behaviors.
Clarified whose workflows and risks should drive prioritization.
Showed where operational value and SLA pressure actually live.
Named failure points with legal, financial, or trust impact.
Made trade-offs explicit before UI debates.
Turned priorities into reusable rules for both product fronts.
Made strategy visible in filters, validation, roles, and SLA signals.
Connected UX quality to what banks evaluate when buying finance SaaS.
In a company with strong engineering and finance expertise, UX was not yet fully established as a business decision layer. Part of my role was to show how UX artefacts connect product decisions to business outcomes: why a persona changes prioritization, why a business process is more useful than a screen list, why a design principle can prevent inconsistent decisions, and why pragmatic quality matters when banks evaluate the value of a SaaS product.
Used to prioritize whose workflow mattered most when trade-offs appeared.
Connected product areas to SLA pressure and operational value — not feature lists.
Translated business goals into explicit trade-offs before UI debates.
Gave the team reusable rules for regulated-workflow decisions.
Connected UX outcomes to what banks pay for: confidence, throughput, and fewer costly mistakes.
Linked roles, permissions, and product areas into a structure that could scale with the product.
Selected outputs in detail
Synthesized examples of how the decision framework became concrete direction.
Without shared language, engineering, PO, C-level, and UX could not align on product behavior.
| Term / Abbreviation | Definition / Meaning | Context in WHT Platform |
|---|---|---|
| Application | The document we submit — the application itself | Core entity in refund and reporting workflows |
| Claim | The possibility / reclaim case | Case container before an application is filed |
| Income | The dividend payment event | Payment chain data in report detail and validation |
| ADR | American Depositary Receipt | Asset type that may appear in imported bank data |
| Approver | User role in KESt | Can approve reports before submission (four-eyes flows) |
| Audit Trail | Action history log | Tracks actions taken inside a report — History tab |
| BZSt | German Federal Tax Office | Receives KESt income-related tax reports |
| Client Receipt | Report summary after submission | Sent to the client as proof of reporting |
Full glossary spans dozens of terms across WHT Platform and KESt — sample above.
Users, influencers, and client types were clustered and prioritized by daily usage and business impact. Assistant Clerk and Team Lead / Supervisors became primary design anchors for KESt and shared WHT Platform patterns.
Prioritization path: user groups → usage × impact matrix → needs and pain points per priority persona.
Operational user · high usage & high impact
More rights than assistant · end-to-end cases
Reporting manager · SLA & risk visibility
Configuration & governance
End-to-end processes (imports, SLAs, four-eyes approval, RAS, reporting…) were mapped and clustered into shared product areas — connecting legacy WHT Platform workflows to KESt priorities.
Key product shift from clustering
Stop being passive (“I need to look for tasks”). Be informative: “Do this by date X because SLA Y applies.” — proactive guidance tied to deadlines and SLAs.
1st process: Submit an application
2nd process: Setup the system (users & roles)
Processes: reporting & observation
Comply with RAS
Manage & correct import runs
Each cluster was later mapped by frequency of use and impact if something fails (SLA, risk, money) — informing roadmap and Manage Reports prioritization.
From mapped journeys, the team identified moments where errors have legal, financial, or SLA impact.
In regulated systems, trade-offs must be explicit. Six tensions were prioritized with the team; winners became design principles for both product fronts.
After voting on tensions in critical moments, we turned priorities into explicit rules for a regulated environment.
Errors have legal, financial, and SLA impact — preventing wrong submissions matters more than fast clicks.
Regulated workflows need step-by-step flows, not interpretable screens.
Consistency and compliance beat ad-hoc workarounds.
Users must understand status, deadlines, and blockages.
Rule-based decisions should not depend on human memory.
Expose SLA status, blockages, and missing documents without overloading the UI.
Consistent logic reduces training and errors; customization must be rule-based, not UI-fragmenting.
Block invalid actions early; allow controlled recovery when possible — prevention is safer than correction.
Permissions mapping (RACI-style) clarified which roles can view cases, approve under four-eyes, monitor SLAs, and manage imports — informing role-based entry points and IA without publishing a full matrix in this case.
Examples of how strategic work shaped the Manage Reports experience.
Persona: Operational User under SLA pressure
→ Needs guidance, speed, clear errors
UI: Validation indicators, filtered lists, revalidation actions
Persona: Team Lead / Supervisor
→ Needs risk visibility and SLA overview
UI: SLA progress, dashboards, escalation signals
Process: Validate and approve reports
→ Risk: wrong submission / rework
UI: Validation states, audit trail, approval flow
Principle: Transparency over abstraction
→ Users must inspect what happened
UI: History, logs, XML view, status explanation
In WHT Platform, pragmatic quality is tied to what banks pay for: making employees faster, more confident, and less error-prone when processing regulated tax reports — not just looking modern.
Pragmatic quality was the UX lens I used: can users complete critical workflows efficiently, confidently, and with fewer avoidable mistakes? For finance SaaS sold to banks, that affects onboarding, throughput, SLA confidence, perceived maturity, and willingness to trust the system.
Pragmatic quality
Perceived efficiency, clarity, and confidence for operational users
Time to value
Speed to find, validate, and move reports forward
SLA visibility
Prevent missed deadlines before they become business risk
Error prevention
Fewer wrong submissions, less rework, stronger compliance confidence
Traceability
Audit readiness and stakeholder trust
Operational throughput
Processing thousands of reports per period
Demo credibility
Prospects understand the product vision quickly
Together with stakeholders, I framed pragmatic quality and time-to-value as UX success indicators to connect later with business metrics such as SLA fulfillment, throughput, rework reduction, and client confidence — not as finalized measured outcomes in this phase.
A measurement framework for the next implementation phase — not claimed results from this discovery/prototype phase.
Sphere 2
I focused on the journey where operational value and risk meet: Manage Reports. For bank employees, it had to work as a control surface for thousands of tax reports — finding the right cases, understanding validation problems, acting before SLA deadlines, approving work, and keeping evidence for audit and transmission.
Operational users needed to move large volumes of reports forward without losing confidence. Reporting managers needed visibility into bottlenecks and SLA risk. Institutional clients were indirectly affected because they depend on reports being sent on time and without errors. Even individual clients, as edge personas, depended on the process being accurate although they never directly used the system.
Grounded in Sphere 1: personas, processes, errors, SLAs, and design principles — translated into operational behavior.
Manage Reports had to serve different stakeholders with different definitions of failure — not one generic user story.
“I need to easily find, validate, and submit the right reports, but dealing with thousands of entries and multiple filters makes the process error-prone and time-consuming.”
UX implication: Prioritize findability, validation clarity, bulk action, and recovery.
“I want a clear overview of reporting progress and bottlenecks, but it is hard to track statuses and SLA risks without proper visibility.”
UX implication: Expose progress, SLA indicators, error counters, bottlenecks, and responsibility.
“I expect reports to be sent on time and without errors, but I cannot see where the process is stuck or who is responsible.”
UX implication: Internal traceability, logs, receipts, SLA configuration, and support evidence protect the external client experience.
“I expect my tax report to be accurate and delivered on time, but I have no visibility into the process and rely on the bank to get it right.”
UX implication: Validation checks, opt-in status, certificates, and client-level audit trails protect edge cases.
The goal was not to add more controls to the screen. The goal was to make the operational state of the reporting period understandable and actionable.
Each row connects an operational risk to a concrete product decision — not a feature checklist.
High-volume report handling
Advanced filters by period, client, country, ISIN, status, SLA, and processing state.
Why: Users need to locate specific reports among thousands without losing context.
Validation & error prioritization
Traffic-light validation status, warnings, error counters, and clear action states.
Why: Users need to know what needs attention before deadlines slip.
Operational throughput
Bulk approve, reject, revalidate, and retry flows.
Why: Repetitive work at reporting scale cannot depend on one-by-one actions.
SLA & bottleneck visibility
Progress widgets, status distribution, SLA indicators, and filters by deadline/risk.
Why: Managers need to detect risk early — not after an SLA has already failed.
Audit & accountability
History tab, user actions, timestamps, comments, and status changes.
Why: In regulated workflows, every important action needs to be explainable.
Technical evidence & transmission
Transmission logs, XML view, receipt/status information, and technical details.
Why: Technical users need to inspect what happened, troubleshoot issues, and prove submission.
Compliance data inspection
Structured report detail modal with tabs for overview, ownership, income, payment chain, certificates, holdings, history, transmission, XML, and validation.
Why: One endless form would hide complexity. Tabs organize evidence by concern and support different user intents.
The workflow operational users run during a reporting period — each step has a clear intent, not only a screen name.
Enter Manage Reports
Understand the current reporting period and workload.
Filter reports
Narrow thousands of entries to the actionable subset.
Identify issues
Distinguish valid, warning, and blocking cases.
Inspect report details
Understand financial, ownership, document, validation, and transmission context.
Fix and revalidate
Move blocked reports back into the workflow.
Approve or reject
Complete operational decisions with accountability.
Monitor SLA progress
Confirm whether the reporting period is moving toward fulfillment.
The report detail modal was not designed as a generic details view. It became an inspection model for regulated work — different users need to answer different questions about the same report.
What is this report? Who owns the income? Which payment chain produced it? Is the certificate available? What changed? Was it transmitted? What does the XML say? Which validation rules failed?
Business and status summary
Creditor, trust, beneficiary, and compliance ownership data
Amounts, withholding, treaty benefits, and tax rate context
Transaction history and acquisition/disposal context
Official documentation and certificate availability
Current and historical holding evidence
Audit trail and workflow state changes
ELMA/BZSt communication and technical status
Raw technical evidence for reviewers
Data-quality issues, missing fields, rules applied, and recommended actions
Prototype
I built the Manage Reports experience in TypeScript because Figma alone would not communicate the operational behavior of the product: filters, status changes, bulk actions, report inspection, validation, logs, and modal interactions needed to feel real.
The prototype became a way to test the product direction internally, align engineering and leadership, and make the KESt vision credible in tier-1 bank conversations.
Due to client confidentiality, the prototype is no longer publicly accessible. This case documents the interaction logic and product decisions behind it.
The prototype was not the end of the work. It became a commercial and strategic proof point. After tier-1 banks engaged with the KESt vision, Beabstracto continued in a broader UX/design lead capacity. I kept driving KESt from groundwork through product direction and MVP definition, while also contributing to the reconstruction and modernization of the existing WHT Platform platform. The early foundations became reusable patterns — not isolated discovery artefacts.
Scattered reports
Actionable workload
Unclear errors
Prioritized validation signals
Hidden SLA risk
Visible operational progress
One-by-one work
Bulk operational throughput
Black-box transmission
Inspectable logs and XML
Disconnected evidence
Structured report detail model
Impact across the first discovery, prototype, and follow-up leadership phase.
The TypeScript prototype made the product vision tangible enough for tier-1 banking stakeholders to treat it like real software.
Manage Reports became a concrete reference for KESt MVP scope and expected product behavior.
UI decisions were traceable to persona needs, risk scenarios, process mapping, and design principles.
Developers had a more concrete model for filters, validation, bulk actions, audit trails, and report detail structure.
The same patterns could inform both the new KESt reporting module and WHT Platform modernization.
This case documents the first strategic and prototype phase. Business metrics such as SLA fulfillment improvement, long-term throughput, and pragmatic quality benchmarks are still being shaped with stakeholders as the product moves toward implementation.