Overview
KONSENS Grundsteuer is the federal IT programme delivering Germany's property-tax administration. The platform serves taxpayers, case workers, and compliance teams across federal and state authorities - five connected products operating under a single regulated workflow, with audit obligations that cross multiple legal jurisdictions.
As Design Lead I set design direction across the platform and lead a team of 5 designers. The work is less about producing screens and more about building the operating model - Discovery cadences, persona research, design reviews, system governance - so design doesn't depend on me being in every room.
Every design decision has to hold up to compliance review, survive an audit trail, and stay durable across multiple delivery squads. Polish in this context isn't a UI concern - it's whether a case worker can complete a cross-jurisdictional review without re-entering data three times, and whether a compliance specialist can trace the audit path of a single declaration end-to-end.
Discovery & multi-persona research
The platform serves five user populations with entirely different mental models, technical contexts, and regulatory exposures. Discovery has to run deep enough that by the time a screen is drawn, stakeholder questions are already answered in the persona library. The persona who owns the binding workflow decision is rarely the loudest - often a downstream case worker or compliance specialist whose sign-off authority only surfaces when you trace the workflow back to where it breaks.
Personas served
P01
Property taxpayer
Millions of property owners filing federal property-tax declarations. Wide range of digital literacy and language proficiency.
P02
Tax authority case worker
Daily operational tool across federal and state authorities. Where most product friction surfaces in practice.
P03
Federal / state compliance specialist
Cross-jurisdictional audit and regulatory oversight; sign-off authority on binding workflow decisions.
P04
Internal admin & configuration
Platform configuration, rule maintenance, and inter-authority coordination across federal/state systems.
P05
Developers & product owners across squads
The internal "users" of the design system itself - multiple squads consuming components, tokens, and patterns from one shared library.
Discovery methods I run
Sample JTBD card - representative structure
The format the persona research produces. Below: the shape of a real JTBD card, with the situation and forces abstracted. Actual job statements, personas, and field data are under NDA.
P03 - Compliance Specialist
When a federal-state audit lands in my queue, I want to defend each declaration with a single, traceable source of record - so I can clear the audit without manually reconciling spreadsheets.
Push - current pain
Spreadsheet reconciliation eats hours per audit; evidence lives in three different tools.
Pull - toward new behaviour
One audit trail per declaration, queryable by case ID, accessible to federal and state staff alike.
Anxiety
Fear of missing a regulatory deadline; second-guessing whether the tool will be sign-off ready.
Habit / loyalty
Long-standing trust in existing case-management tooling; resistance to changing what already passes inspection.
Each persona carries 3-5 cards like this. Referenced in design reviews and sprint planning.
The operating model - design that scales past me
A small design function in a regulated, multi-product programme doesn't survive on heroics. It survives on rituals - recurring Discovery, persona artifacts the team actually references, design reviews that don't depend on one reviewer. The operating model is the part of design leadership that doesn't show up in any single screen - and it's where most design functions quietly fail.
01
Discovery cadence
Recurring stakeholder interviews and assistive-tech sessions on a regular rhythm - Discovery is not a phase but a continuous input to the roadmap.
02
Persona research the team actually uses
Persona artifacts referenced weekly by PMs, engineers, and compliance - not just by designers. Decisions get changed at the research stage, not after engineering investment.
03
Design reviews
Recurring critique and design-quality reviews across the team of 5 designers - quality scales without depending on me being in every room.
04
System governance
Component, token, and pattern governance across the 5 products - accessibility and audit-readiness embedded into the system, not retrofitted at QA.
Multi-product workflow
The five products are surfaces of a single regulated workflow, not independent apps. One property declaration moves through taxpayer intake, case-worker review, compliance audit, and inter-authority coordination - and an audit failure at any point invalidates the chain. Designing them in isolation fragments the user experience and opens audit gaps. Designing them as one workflow requires shared personas, shared tokens, and a governance layer that holds across squads.
01
Taxpayer
intake
02
Case
review
03
Compliance
audit
04
Inter-authority
coordination
05
Internal
configuration
Product surfaces shown above are representative; specific product names and screens under federal NDA.
What I'm shipping
The engagement is ongoing. What's visible at this stage:
Other deliverables in flight
- Persona library referenced by PMs, engineers, and compliance as shared vocabulary
- Operating-model rituals running on a recurring rhythm
- Component-level accessibility remediation with assistive-tech audit protocols
This engagement is ongoing and operates under German federal-tax confidentiality. Specific product names, screens, internal documentation, and persona artifacts are under NDA. Methodology, role, and operating-model decisions described here are accurate to my practice; the persona library shown is representative of the multi-persona regulated workflow.