YORINORI
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.
[ Year ]
2021
[ Type ]
Brand Identity
[ Contribution ]
50%
The packaging design is inspired by the landscape of a salt field. The white cube resembles a salt particle. The side patterns and the grids are treated with embossing, white on white, portraiting the rhythmical landscape of the salt field.
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.
Product
SaaS form platform for municipalities
Role
Product Designer (UX)
Owned product positioning, IA, upgrade structure, and UX strategy
Service Name
2 weeks
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
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.
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.
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.
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?