VoteReady
Personal Project | Synaptic Weave
Claude API | Elasticsearch | OOUX/ORCA | HTML/CSS/JS
The Problem
In 2026, the SAVE America Act introduced new federal voter registration requirements — stricter ID rules, in-person verification mandates, and multi-document citizenship chains that vary by state and county. For most people, navigating these requirements means cross-referencing government websites, managing deadlines, and tracking down documents across multiple agencies. For someone with ADHD, anxiety, executive function challenges, or limited bandwidth — this process becomes a serious barrier to civic participation. Existing tools treat voter registration as a checklist problem. The real problem is cognitive.
Design Approach: Cognitive Infrastructure, Not Content
The standard approach to accessible design adds accommodations after the fact. I took the opposite approach: designing for cognitive processing requirements from the ground up, so the features that help neurodivergent users are the features that help everyone. The core insight driving every decision: this is a cognitive infrastructure problem, not a content problem. The information about voter registration exists. What doesn't exist is a system that helps people process and act on it given variable capacity and working memory limitations.
Three Core Design Decisions
- Capacity-aware interface modes — users set their current state to High, Medium, Low, or Crisis, and the interface responds accordingly. Low capacity means one action, direct language, and explicit permission to stop: "This is enough for today." This isn't a stripped-down accessibility mode — it's the primary interaction model
- Shame-free language as a design constraint — every UI string went through a language audit. The system never uses "overdue," "late," "behind," or "urgent." Progress is framed positively, deadlines are surfaced with buffer built in, and partial progress is treated as real progress
- Working memory externalisation — complex requirements are decomposed into micro-tasks with explicit "working memory anchors." If you close the app and return three days later, the system tells you exactly where you were and what the next concrete step is
The ORCA Data Model
The back-end architecture was designed using OOUX methodology, structuring the data model around objects users actually interact with — not technical entities or admin categories. The resulting ORCA table defines nine objects, with cognitive metadata embedded at every level. Micro-tasks carry a calculated cognitive load score based on estimated time, decision requirements, dependencies, and tools needed. Service Options are tagged with both cognitive load and physical energy required, so the system can surface the most accessible path for a user's current capacity — not just the fastest.
Designing for cognitive load extremes produces better design for everyone.
AI Integration
VoteReady includes a Claude-powered conversational assistant whose system prompt was designed as a design artifact — not an afterthought. The prompt defines capacity-mode response rules, persona-specific adaptations, explicit banned language, and compliance logic routing. The assistant doesn't replace the UI — it handles the "why does this apply to me?" and "which path is best for my situation?" questions that a static interface can't fully anticipate.
The system prompt is a UX specification. Not a backend concern.
Nine Objects Power the System
- User Profile — identity state, registration history, and cognitive processing preferences
- Compliance Requirement — federal/state/county rules with trigger conditions
- Document Chain — ordered paths to satisfy requirements with difficulty scores and timeline estimates
- Micro-Task — atomic actions with cognitive load scores, energy requirements, and low-capacity alternatives
- Agency, Service Option, Activity, Milestone, and Document — completing the full guidance loop from requirements through to verified registration
Elasticsearch Integration
- "What do I need?" — resolves applicable compliance requirements based on state, county, registration history, and name-match status
- "Where can I get this?" — finds agencies for a document type with geo-distance filtering, sorted by efficiency and filtered by current cognitive load tolerance
- "What should I do today?" — surfaces micro-tasks matched to the user's capacity state, batching similar tasks and prioritizing by deadline proximity
- Geo-point capability reduces the most friction-heavy moment: figuring out which DMV or vital records office to visit — surfacing the nearest location that can fulfill the needed document via the method appropriate to current capacity
Skills Demonstrated
- Systems thinking through OOUX/ORCA data modeling — 9 interconnected objects with cognitive load metadata at every level
- Inclusive design methodology — cognitive load architecture, capacity-aware UX, shame-free language as a design constraint
- AI integration design — structured system prompt design as UX artifact, persona-adaptive response routing
- Technical UX — Elasticsearch index design with cognitive metadata, geo-query patterns for service discovery, HTML/CSS/JS prototype
What I Learned
- Designing for cognitive processing extremes produces better design for everyone — features built for someone on a crisis day turn out to be what most users want anyway
- The cognitive processing requirements framing removes stigma from the conversation and makes it easier to advocate for those features in a product team context
- Completeness paralysis is a real UX problem in high-stakes compliance contexts — the document chain visualization was designed specifically to make the path visible before the details are required
Note on Visual Design
This project was deliberately focused on the systems and AI architecture — the capacity-aware data model, the Claude API prompt design, and the Elasticsearch query patterns. The visual design is functional but not the point of this work. The live app demonstrates that the logic works. The case study documents how it was built.
The architecture is the artifact.
