Civic OS
2025
Civic OS
Designing a schema editor for Civic OS, an open-source platform that lets city staff manage their own data without writing SQL. Currently in development.
Overview
A schema editor city staff can’t break
Civic OS is an open-source platform that helps local governments run permits, inspections, and records on one system instead of a patchwork of disconnected tools. Its foundation is the database, and the people who need to change it are usually not engineers.
I was the sole designer on the schema editor, the screen where staff define tables, fields, and how they relate. I worked directly with the lead developer, Dan Kurin, across ten working sessions from February to April 2025, moving from research to a tested prototype and a handoff in Figma and Penpot.
Problem
Database tools assume you think like a database
Entity relationship diagrams are the standard way to show a database, but every tool built around them assumes you already know the vocabulary: primary keys, foreign keys, crow’s foot notation, cardinality.
For a city clerk adding a field to a permit record, that vocabulary is the barrier. The editor had three jobs:
Show the real structure of a live database, loaded automatically
Let non-technical staff add and edit tables and fields with confidence
Make relationships understandable without learning notation
And because it writes straight to a production database, one wrong click could destroy real records.
Research
Five tools, two principles
I compared five diagramming tools: Lucidchart, Draw.io, Eraser, Creately, and SmartDraw. For each, I looked at how you add an entity, edit a field, define a relationship, and move around the canvas.
Lucidchart had the most direct manipulation: click to edit, drag to connect, cardinality right on the line
Eraser’s code view next to the diagram made the structure easy to verify
Creately’s zoom felt clunky and its relationship labels were hard to read
Most tools made people switch between select, pan, and draw modes, which adds friction for occasional users
Two principles came out of it: structure matters more than diagram aesthetics, and a click should always do the same thing.
Decisions
Plain language over notation
The editor lays entities out automatically and sizes them to their fields, so nobody spends time arranging boxes. There are no tool modes. Zoom works with familiar shortcuts, plus visible zoom buttons and a reset view for anyone who doesn’t know them.
Relationships took the most iteration. My first prototype used drag-to-connect handles and a crow’s foot picker. In review, Dan pointed out it was too abstract for the people who would actually use it. I moved relationship editing into a contextual side panel where cardinality reads as two sentences, one from each side: “Each permit is on one parcel. Each parcel can have many permits.”
The same panel holds an Entity tab and a Code tab, so technical users can check the generated schema without leaving the editor.
Guardrails
Making destructive changes visible
Schema changes are destructive, so I designed the editor to make risk visible instead of hiding it.
Every new entity gets a primary key automatically, and foreign keys come from relationships, never typed by hand
A field’s data type is set when the field is created and locks once it holds data, so existing records can’t be corrupted
Changes save manually, through a review screen that lists every addition, rename, and deletion
Deletions show how many records they affect and need an explicit confirmation
Visually I built on daisyUI’s Light theme and components, the same kit the developers use, with Civic OS navy from their deck as the primary color. The audience is municipal staff, so contrast and clarity came before personality.
Handoff
Handed off and in development
I delivered wireframes, an interactive prototype, and a component library in both Figma and Penpot, so the open-source team could keep working in an open tool. Dan shared the files with the project on GitHub.
Civic OS is in development now. The next phase is a design system with UI standards that future contributors can build on.
What I’m carrying forward: when users don’t speak the system’s language, translate the interface, not the user.
