Government / Civic Tech
A digital front door for a local municipality, designed for citizens with no prior experience filing anything online.
Sajilo Palika — "Easy Municipality" — is a digital front door for a local ward office, letting citizens request recommendation letters, register complaints, and check application status online instead of visiting in person.
The problem: Most citizens dealing with the ward office had never filled out a government form online before. Routine services often required two or three in-person visits: one to submit, one to follow up, one to collect. Staff managed paper case files with no shared record of status.
Business goals: Reduce in-person visits for routine services; give citizens visibility into their application status without a phone call or a trip; give ward staff a shared, trackable system for processing requests.
I conducted field interviews at the ward office with eight citizens waiting in line, three ward staff, and the ward secretary, and mapped the existing paper-based workflow end to end, from form submission to stamped approval.
Limited smartphone experience; needs simple, guided, Nepali-first steps.
Comfortable with apps; wants to submit and track a request without visiting at all.
Processes 30–50 applications a week; needs a queue view, not a phone.
I looked at Nepal's national-level e-services portals (broad scope, generic UI not tailored to ward-level services) and a few municipality Facebook pages used informally for announcements, with no transactional capability at all. The gap: no ward-level system designed specifically around the small set of services this office actually handles.
User flow: A guided, single-service-at-a-time flow: a citizen picks one service — a recommendation letter, for example — sees exactly which documents are required before starting, then fills a short form with plain-language field labels.
Information architecture: Organized around citizen-facing services first — "what do you need today" — rather than internal department structure, the opposite of how the paper system was organized.
Wireframes: Tested paper prototypes in Nepali directly at the ward office with five citizens in line, including two with limited digital literacy, before any visual design began.
A plain, high-contrast, minimal-jargon interface with Nepali as the default language, large clearly-labeled buttons, and no icon-only navigation, since icon literacy couldn't be assumed for this audience.
Design system: A restrained set of components — service card, document checklist, status tracker, plain-language form field — reused across all six launch services, so the experience stayed predictable no matter which form a citizen was filling out.
Typography: Space Grotesk for headings and status labels, used sparingly for clarity at a glance; Inter for body copy and form content; both checked for legibility alongside Devanagari-script content.
Key components: Service picker card, document checklist with a "you'll need" preview, a visual (not just text) status tracker, and a staff-facing request queue with a flag for missing documents.
Prototype: Tested the clickable prototype with six citizens and two ward staff members across two rounds, in person at the ward office.
Accessibility: WCAG AA contrast, full keyboard navigation on the staff-facing admin panel, plain-language content reviewed for a lower digital-literacy audience, and a visible "get help" fallback on every screen rather than tucked into a footer.
Kept a visible option to complete any service in person, since removing that entirely would have excluded citizens without reliable internet access. Used an official-feeling but approachable visual language — formal enough to read as legitimate, not so formal it felt intimidating to a first-time digital user — and tested two visual directions with real citizens rather than settling it by internal preference.
Challenges: Designing for a user who had never used a government website before, without assuming any baseline digital literacy, while also serving staff who needed an efficient processing queue, not a simplified one. Balancing official formality against approachability ran through nearly every decision.
Solutions: Splitting the guided, one-question-at-a-time approach for citizens from a denser, queue-based interface for staff let each audience get what it actually needed from the same underlying data. On the formality question, real citizen reactions during testing, not internal stakeholder preference, settled the visual direction.
Reduced foot traffic and queue pressure at the ward office, gave leadership a clearer picture of processing bottlenecks, and built citizen trust that made later service additions easier to introduce.
Delivered a documented Figma file with a bilingual content structure (Nepali primary, English secondary), explicit component states for each step of the status tracker, and a written note flagging the in-person fallback as a requirement, not a legacy option to be quietly dropped during build.
Lessons learned: Designing for digital inclusion has to shape the earliest structural decisions — organizing by citizen need instead of department, or keeping an in-person fallback visible — it can't be a checklist item added at the end. Plain-language form copy also needed several rounds of simplification before it made sense to a first-time user, even after it already made sense to office staff.
Next improvements: SMS-based status updates for citizens without consistent data access, an offline-capable version for ward staff during outages, and extending the guided-flow pattern to the rest of the service catalogue.
This was the project that most tested my belief that good design removes friction from someone's life rather than adding polish to a screen. Every decision had to survive one question: would this make sense to someone filling out their first online form, standing in a line, unsure if it would even work? When the answer was no, the decision changed.