Why a canton portal is not a marketing site
The Kanton Thurgau Digital Switch is a working counter for citizens: school enrolment, traffic fines, permits, and dozens of other processes that used to mean a queue at a desk. Our team integrated AEM Forms into that portal so each process could ship as a digital form without rebuilding the whole site for every change.
The work case study lists stack and outcomes. This post is the engineer's view: what surprised me, what slowed us down, and what I would repeat on the next canton project.
Accordion forms instead of one long scroll
Many Thurgau flows used accordion layouts in AEM Forms: sections expand one at a time, validations stay scoped, and long PDF-style questionnaires become navigable on a phone. That pattern fits public admin well. Users often arrive with one document in hand and need to know where they are in a multi-step obligation, not scroll through twenty fields they cannot yet fill.
Building those accordions meant more than dragging panels in the form editor:
- Rules per section: opening step two only when step one is valid, without hiding errors the clerk would need to see on paper.
- Shared fragments: the same address block or identity fields reused across processes, with canton-specific labels.
- Test data that respects reality: a school form and a traffic form do not share the same edge cases; Insomnia and staged submissions caught mismatches early.
Compared to embedding adaptive forms inside an Angular shell (as I did later on Swisscom Sign), Thurgau stayed closer to native AEM delivery. The integration problem was less about dual runtimes and more about fitting many independent forms into one portal shell with consistent chrome.
Storybook, Figma, and canton design fidelity
Thurgau shipped with a Storybook and Figma sources the canton design team owned. Our job was to match those components in AEM (Less, Sling components, form themes) so embedded forms did not look like a vendor skin on a government site.
That sounds cosmetic until a stakeholder opens the portal beside the design file in a review. Public-sector releases often fail on visual trust before they fail on code: spacing, label hierarchy, error states, and focus order must match what legal and communications already approved.
Practical habits that saved time:
- Treat Storybook stories as acceptance references, not inspiration.
- Snapshot difficult states (empty, error, disabled, mobile width) before sign-off.
- Keep form CSS variables aligned with portal tokens so iframe embeds do not drift.
Domain knowledge as a delivery risk
The hardest bugs were not JavaScript typos. They were wrong assumptions about Swiss canton life: how school years are labelled, when a traffic case references another authority, or how one digital process must not block another back-office workflow.
Requirements arrived as functional specs plus domain experts on calls. I learned to budget time for translation from admin language to field logic: what is mandatory, what is conditional, what must never be pre-filled for privacy reasons. Skipping that conversation produces forms that validate beautifully and still get rejected in UAT because a clerk would never ask that question in that order.
That lesson generalises beyond Thurgau. Any government or regulated form project pays a domain tax. Plan for it in estimates the same way you plan for accessibility or mobile layout.
Embedding forms in a PWA via iframe
Several experiences mounted inside the canton PWA through iframes, with responsive height and messaging so the outer shell and inner form stayed usable on small screens. iframe integration is unfashionable, but it was the pragmatic seam between portal navigation (owned by the canton platform) and form runtime (owned by AEM).
What we had to get right:
- Resize and scroll: the parent must not clip validation messages at the bottom of a long accordion step.
- Deep links: citizens bookmark a process; the shell and form must agree on entry URL and language.
- Failure isolation: a broken form must not white-screen the whole portal; error boundaries on both sides.
None of that is glamorous work. It is what makes a multi-process portal feel like one product instead of a folder of links.
What I took away
1. Canton digitisation is a portfolio of forms, not a single app rewrite. Accordion AEM Forms plus reuse beats one-off pages per process.
2. Design-system fidelity is part of compliance culture, not polish you add at the end.
3. Domain experts belong in the same loop as developers; specs alone do not encode Swiss process law.
4. iframe + PWA can be the right boundary when platform and form lifecycles differ.
The portal is live today on schalter.tg.ch. I still think of this project when someone says "just put a form on the website."
Next in this career series: Ajila and the path into Swisscom (bridge to the Swisscom Sign UX post). Questions on AEM Forms in public portals: LinkedIn.