Background
Arena is a system designed to facilitate public participation processes for government ministries and local authorities seeking to incorporate residents’ insights into their decision-making processes.
The system allows local authorities to choose how to collect insights from the public—through responses to open-ended questions, surveys, or multiple-choice questions.
An equally important aspect of public participation is transparency. Responses are visible to all participants in the process, whether they come from open-ended questions, surveys, or multiple-choice questions.
Additionally, the system enables clients to publish insights at a later stage, allowing the public to see the outcomes of the process and how their participation influenced decision-making.
My Role
This company (inRise) doesn’t have a large team, so I was responsible for the product on several levels:
I was both the product manager and the product designer (of course, research and UI).
I started by doing the research, writing a detailed characterization document and a decision tree to create a common language with development, and I designed the screens, including the design system, according to the logic of atomic design.
Our Objective
Create an easy-to-use system for 2 types of users:
Client (Admin)
Easily create discussions and surveys, manage visibility, and publish insights to the public.
Resident (End-user)
Low-friction participation across different levels of engagement.
Research
To ensure the system meets the needs of both administrators and residents, we conducted two focus groups. The first included potential clients—representatives from collaboration offices in local authorities and government ministries—to understand their needs, challenges, and barriers to adopting public participation systems.
The second group included residents from diverse age groups and socio-economic backgrounds to explore what motivates participation in public engagement processes and what might prevent it.
In parallel, we also conducted a competitive review of public participation platforms in Israel and globally.
Potential
Admins
Focus Group
Potential Residents
Focus Group
Competitive Analysis
Focus Group
Key Assumptions
After analyzing the focus group insights and reviewing competing platforms, we defined six key assumptions that helped shape the system architecture.
Residents are more likely to participate if the system does not require login.
Residents believe their input can influence real municipal decisions.
Publishing insights and decisions after the process closes increases trust and future participation.
A structured step-by-step process creation flow is easier for admins than complex configuration.
Admins Can Easily Choose the Right Engagement Module
Municipal staff want to use participation data and analytics to inform policy decisions.
Information Architecture
Working Process
Specification Document
As mentioned earlier, inRise is a small company where I led the product side of the organization. In this project, I served as both Product Manager and Product Designer.
Before moving into design, I created a comprehensive specification document outlining the system architecture down to the component and interaction level. The goal was to establish a clear, shared understanding between product and development, and to document the system structure for future scalability and iterations.
Design Phase
With the product definition in place, I began the design process by presenting several high-level wireframes to align with key stakeholders (CEO and founding partner) on the overall design direction.
Once a direction was selected, I established a design system based on the Atomic Design methodology, since the platform was built entirely from scratch. In parallel, I designed the complete product interface—including all screens, states, edge cases, modals, and toast notifications—guided by insights from the research phase.
Residents Screens
Admin Dashboard
Rollout Strategy and Validation Plan
The feature was rolled out in three phases to validate engagement and client value while continuously improving the product based on real usage data.
Phase 1 – Pilot (60 Days)
The feature launched with a single high-activity client to test engagement patterns and identify usability issues. Engagement was measured through a funnel:
100%
page visits
~65%
participation start
~40%
completion
Interaction types showed different engagement levels:
~15%
Comments
(high engagement)
~25%
Polls / Surveys
(medium engagement)
~40%
Likes Reactions
(low engagement)
Although engagement was initially lower than expected, we continued the rollout without major changes, assuming the data might be biased due to testing with only one client.
Phase 2 – Scaled Rollout (60 Days)
The feature expanded to 70% of existing clients and all new customers. Success was measured using engagement metrics, heatmaps, and surveys. Results improved and approached expectations:
9%
Comments
21%
Polls / Surveys
32%
Likes Reactions
Phase 3 – Full Rollout
The feature was released to 100% of clients, shifting the focus from validation to optimization through usability testing, behavioral analysis, and continuous client feedback.
