FORM STUDIO
[ Year ]
2026
[ Type ]
Product Design
[ Contribution ]
100%
OVERVIEW
I created a structured civic workflow platform that reduced ambiguity in publishing and payment logic.
Product
Govstack SaaS form platform for municipalities
Role
Product Designer (End-to-End Ownership)
Publishing, Payment logic, System architecture
Cross-functional collaboration with PM & Engineering
Duration
4 Weeks
Context
Form Studio is a municipal SaaS platform used to manage publishing workflows, payment logic, and service configurations. Over time, tightly coupled states and nested rules made system behavior unpredictable and difficult to maintain. I redesigned the workflow architecture by introducing explicit state models and structured payment logic to improve clarity, scalability, and trust.
Problem
The legacy product supported only simple form creation. Its UI/UX was not user-friendly, resulting in low sales performance and making it difficult to position the product as a core digital tool. To support meaningful digital transformation within government organizations, the product needed to be rebuilt as a practical, operational tool that could fully realize its potential.
Target Users
The primary target users were small to mid-size municipalities, with the strongest product-market fit in mid-size cities serving approximately 100,000 to 500,000 residents. Existing customers such as Waterloo, Ann Arbor, and Corpus Christi reflected this profile.
These environments typically operate with multiple administrators managing shared forms across departments, requiring clear ownership visibility and role-based coordination. They are highly compliance-driven, with legal, financial, and transparency obligations shaping daily operations.
At the same time, municipal institutions tend to be risk-averse and less tech-forward. Adoption rates for new systems are often slow, and many staff members are not digitally native. This made cognitive simplicity, structural clarity, and governance safeguards essential to successful implementation.
System foundation
This citizen request lifecycle became the structural lens for every design decision.
Key Design Decisions
Decision 1
Publishing as Governance
The existing system treated publishing as a lightweight toggle. However, in multi-stakeholder, compliance-driven environments, that model introduced operational risk:
In government environments, publishing is not a simple on/off action.
It represents accountability, compliance, and public trust.
-
No clear visibility into approval states
-
Ambiguity around ownership
-
Limited audit traceability
-
High risk of accidental exposure
Government teams operate in risk-sensitive contexts where actions must be defensible, reversible, and clearly documented. Unlike commercial tools optimized for speed and experimentation, public-sector systems must prioritize predictability and governance.
Why This Redesign Mattered
Design Strategy
The goal was to reduce cognitive load while increasing structural clarity. The publishing system was redesigned to make states explicit and continuously visible, clearly distinguishing between draft, scheduled, published, archived, and disabled conditions. Approval-aware workflows were introduced to reflect real operational processes, and audit traceability was embedded into the structure to support accountability requirements. By minimizing accidental state transitions and aligning the interface with government operational logic, the product evolved from a basic form builder into an accountable workflow system.
Old
New
Publish States
To address this, I introduced explicit lifecycle states (Draft, Published, and Archived) and clearly separated structural status from runtime availability conditions such as Live, Pending, Expired, and At Capacity.
Navigation to Reflect Operational Sequence
Pre-publish: Content → Settings → Publish
Post-publish: Content → Settings → Share → Results
Trade Off
Publishing became slightly more structured.
But operational ambiguity was significantly reduced.
Outcome
Publishing decisions became predictable.
Shared ownership became visible.
Backend state logic and UI mental model were aligned.
Increased confidence for non-technical staff
Prevented accidental public exposure
Decision 2
Payment as Controlled Calculation
The legacy form system supported only basic, linear logic. However, real-world usage revealed that municipalities required multi-layered and conditionally structured payment models. This exposed a structural gap between the existing logic framework and the operational realities of government workflows, making it necessary to introduce a more robust form logic foundation.
The new form builder was built on top of SurveyJS, which offered the option to directly leverage its native logic engine. At this stage, we faced a strategic decision: whether to adopt SurveyJS logic as-is, or design a new solution tailored to our specific governance and payment requirements.
The Risk
Technically, everything could be handled in one place.But technically possible does not mean cognitively manageable.
If question logic and financial calculation logic were mixed together, the form would collapse into a single, fragile condition tree. Non-technical administrators would lose clarity and control over how the system behaved, and even small changes could introduce cascading errors. This would significantly increase the risk of payment mistakes and support overhead. At its core, this was not just a structural issue. It was a cognitive boundary problem.
SurveyJS Conditional Logic System
Design Strategy
Instead of allowing all payment logic to live inside survey rules, I proposed a structural boundary:
-
SurveyJS → question visibility & response logic
-
Form Studio Fee Items → financial calculation logic
This separation reduced mental load and clarified ownership.
For Govstack Form Studio fee architecture, I redesigned payments into structured fee items. Supported types were flat amount, per unit/quantity, tier/option-based, time-based, external lookup, and formula-based. Each fee type had a dedicated configuration pattern.
Early Modelling
Initial exploration revealed that pricing logic quickly expanded into nested conditional trees. Even simple scenarios introduced combinatorial complexity.
Instead of exposing this complexity to administrators, I encapsulated the logic in independent Fee Items, each responsible for a single pricing rule.
Final Design
Instead of requiring users to write multiple nested IF rules, the system enabled administrators to configure structured tiers in a clear and intuitive way.
I examined complex, real-world municipal scenarios and restructured them into a simplified fee framework that could be configured without fragile conditional trees. The goal was to allow realistic but operationally complex cases to be implemented through a controlled and predictable fee structure.
Scenario
Community Hall Rental and Permit Application
-
Event type base fee
-
Private event: $150
-
Commercial: $300
-
Non-profit: $80
-
-
Resident vs Non-resident
-
Resident: No additional cost
-
Non-resident: +20%
-
-
Late booking fee
-
Less than 7 days $50 rush/late fee
-
-
Add-ons
-
AV equipment: $40
-
Cleaning service: $60
-
Security staff: $30 / hr
-
-
Security deposit
-
Deposit $200 (no tax, refundable)
-
Pay only the deposit at the application, rest will be invoiced after the approval
-
-
Tax
-
HST 13%: Base fee + Room rental + Add-ons
-
Deposit - no tax applied
-
Structured Complexity
Each fee item was designed as a modular unit with clear categorization and inclusion rules.
Rather than embedding logic directly into form conditions, fees were structured as independent objects with defined properties:
Token and Report
Fee items were not just calculation units. They became reusable tokens across reporting and communication.
Results
The redesign significantly reduced cognitive load in fee configuration by clearly separating content logic from financial logic. This structural boundary created a scalable foundation for future payment models while ensuring safer configuration for municipal staff.
Outcome
This project resulted in clearer operational boundaries, reduced governance risk, and increased structural integrity across the product. Hidden system states were surfaced, UX issues were reframed as architectural problems, and structural boundaries were intentionally defined to prevent cascading complexity.
By balancing flexibility with clarity, the redesign protected long-term product integrity in a risk-sensitive environment and reduced the likelihood of configuration errors under pressure. This was not a visual refresh. It embedded governance into the core architecture of the product.
Reflection
If extended further, I would validate publish-state comprehension through structured usability testing and measure configuration error rates before and after the redesign to quantify its impact. I would also introduce additional guardrails, such as automated fee conflict detection, to proactively prevent misconfiguration in complex scenarios.