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
SaaS form platform for municipalities
Role
Product Designer (UX)
Owned product positioning, IA, upgrade structure, and UX strategy
Service Name
2 weeks
Duration
2 months
Role
Product Designer (End-to-End Ownership)
Publishing, Payment logic, System architecture
Cross-functional collaboration with PM & Engineering
Product
Govstack SaaS form platform for municipalities
My Role
Product Designer
(End-to-end ownership)
-
Framed ambiguous requirements into actionable UX problems
-
Designed user flows, IA, and interaction patterns across the lifecycle
-
Built high-fidelity prototypes to validate behavior and edge cases
-
Partnered closely with PM and engineering to align on system states and constraints
-
Drove decisions through design reviews focused on failure modes and governance
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.
Options considered
Option A — Ship locked templates as a finished product
Fastest revenue path, but high long-term trust risk and no upgrade narrative.
Protect UX integrity, but no short-term revenue and no market learning.
Option B — Block the initiative entirely
Position templates as a safe starting point rather than a complete solution.
Design a clear upgrade path to Form Studio.
Align structurally with the future architecture.
Option C — Reframe as a Lite Entry Model
We chose Option C.
System foundation
This citizen request lifecycle became the structural lens for every design decision.
Key Design Decisions
Decision 1
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.
Publishing as Governance
-
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
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.
Publish States
Pre-publish: Content → Settings → Publish
Post-publish: Content → Settings → Share → Results
Navigation to Reflect Operational Sequence
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
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.
Payment as Controlled Calculation
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.
Hypothesis
If system state becomes explicit and logic complexity is separated by purpose,
staff confidence and operational reliability will increase.
Instead of simplifying the system, the goal was to make it predictable.
Publish
Resolve
Assign
Triage
Pay
Submit
Analyze
System overview
This citizen request lifecycle became the foundation for every design decision.
Why this problem mattered
Municipalities process thousands of citizen requests every month, many of which involve payments, deadlines, and irreversible administrative actions. Yet most form tools still treat submissions as static inputs rather than operational workflows. As a result, staff struggle to see what is delayed, payment failures lack clear recovery paths, and leadership has limited visibility into accountability and performance. The real problem was not form creation. It was the lack of visibility into what happens after submission.
Hypothesis
If forms are designed as operational workflows, not static inputs, cities can reduce operational risk and make accountability visible. To test this, I redesigned Form Studio as one connected system across:
Publishing
Payments
Results & Analytics
Research & Insights
What I observed
Publishing was treated as a simple on/off event. In reality, it involved multiple operational states — including draft, scheduled, active, expired, archived, and capacity-limited. However, these distinct backend states were collapsed into a single toggle, oversimplifying what was actually a nuanced governance process.
The risk
Hidden transitions increased the chance of misconfiguration and misinterpretation.
The decision
I separated:
-
Publish status (Draft / Published / Archived)
-
Runtime availability (Live / Pending / Expired / At Capacity)
And introduced:
-
visible ownership
-
scheduling previews
-
pre-publish validation
DECISION 1
Publishing as state management, not an action
What I observed
Publishing was treated as a simple on/off event. In reality, it involved multiple operational states — including draft, scheduled, active, expired, archived, and capacity-limited. However, these distinct backend states were collapsed into a single toggle, oversimplifying what was actually a nuanced governance process.
The risk
Hidden transitions increased the chance of misconfiguration and misinterpretation.
The decision
I separated:
-
Publish status (Draft / Published / Archived)
-
Runtime availability (Live / Pending / Expired / At Capacity)
And introduced:
-
visible ownership
-
scheduling previews
-
pre-publish validation
Trade-off
The flow became more structured.
But it eliminated ambiguity around irreversible actions.
DECISION 2
Separating logic to reduce cognitive overload
What I observed
The system already used Survey JS for conditional logic in form building. Technically payment calculation could live there. The quest wasn't "can it?" It was "should it?"
The risk
Mixing question branching, payment calculations, tax logic, deposits, refund rules into a single configuration layer would create a logic-heavy form that non-technical users couldn’t safely manage.
The decision
I intentionally separated responsibility:
-
SurveyJS = question logic
-
Form Studio Payments = fee calculation logic
I designed a Fee Item model that supported fixed, conditional, calculated, and lookup-based pricing within a single structured system. This approach enabled flexible fee configurations without requiring deeply nested logic trees, reducing complexity while maintaining operational accuracy.
Trade-off
Functionality was distributed across layers. But cognitive load was reduced and ownership became clearer.
DECISION 3
Turning submissions into operational signals
What I observed
Data already existed. What didn't exist was clarity.
Staff need to know what requires attention now? Where is SLA risk emerging? Where are issues recurring geographically?
Principle
Metrics must answer operational questions, not decorate dashboards.
The decision
I designed analytics around:
-
status visibility
-
SLA monitoring
-
location-based heatmaps
and removed vanity metrics that didn't support decisions.
Trade-off
Functionality was distributed across layers. But cognitive load was reduced and ownership became clearer.
Validation & iteration
The product is still in the design and implementation process. So far, I have validated the redesign through:
Although the product did not fully launch, I validated the redesign through:
-
workflow simulations
-
internal configuration testing
-
cross-functional scenario walkthroughs
Observable Improvements
During walkthrough discussions, confusion around publish states consistently decreased, as users were better able to understand where a form stood and what would happen next. Payment setup required fewer deeply nested conditional rules, and teams aligned more quickly on where specific logic should live. Importantly, the system became easier to reason about overall—without reducing capability.
Impact signals
The redesign shifted Form Studio from a collection of disconnected features into a cohesive operational system. It reduced hidden state transitions, logic-layer confusion, and ambiguity around ownership, while increasing predictability, decision clarity, and confidence in high-risk workflows.
Reflection
This project reinforced a core belief: complex systems do not require fewer capabilities—they require clearer mental models. Designing for government meant prioritizing predictability over speed, clarity over control density, and accountability over feature breadth.
Why this case matterss
This work demonstrates my ability to identify hidden operational risk, intentionally separate complexity across system layers, design for high-stakes environments, and make trade-offs that protect long-term reliability.