Designed a comprehensive settlement assessment form for Canada's largest newcomer services organization. This logic-driven, accessibility-first system transforms inconsistent paper-based intake into a scalable digital platform supporting 160+ questions with conditional logic across 8+ locations.
Tools
Achēv is one of Canada's largest providers of immigrant settlement services, employment training, language assessment, and youth programs. With nearly 400 staff across 8+ locations in Ontario, the organization serves thousands of newcomers annually—refugees, international students, and ESL learners seeking support to settle, work, and thrive in Canada. In early 2026, Achēv embarked on a digital transformation to standardize how newcomers are assessed for settlement needs and connected to critical services.
I led the UX/UI design of NAARS, a comprehensive client registration system with 160+ questions, complex conditional logic, and an accessibility-first approach. The project ran from February to March 2026, with a tight three-week design window and a hard deadline of March 7 for QA delivery.
Before NAARS, Achēv's settlement intake process was fragmented and paper-heavy. New clients arriving at one of eight locations filled out inconsistent forms, answered overlapping questions, and waited for manual data entry by case workers. When the same client visited a different location, staff had no unified record—assessment data lived in separate systems or filing cabinets. This wasn't just inefficient; it undermined Achēv's mission to create faster pathways to prosperity.
Leadership couldn't see patterns at scale: How many newcomers need emergency housing? What's the relationship between language level and employment support needs? Government funders—Immigration, Refugees and Citizenship Canada (IRCC) and Employment and Social Development Canada (ESDC)—increasingly demanded outcome data that the fragmented system couldn't provide. The bottleneck was clear: assess manually, refer inconsistently, report roughly.
The project had four concrete goals. First, standardize assessment across all locations by creating a unified, logic-driven intake form used consistently at every Achēv office. Second, reduce assessment time from 45–60 minutes (paper + manual data entry) to 15–25 minutes with a digital system. Third, ensure accessibility compliance to WCAG 2.1 Level AA and Ontario's AODA standard, recognizing that many clients have limited digital literacy or are ESL learners. Fourth, deliver developer-ready designs in Figma with complete conditional logic documentation, component system, and responsive layouts for desktop, tablet, and mobile.
Success would be measured by three signals: design delivery on deadline (March 7, 2026) with full QA sign-off; post-launch metrics including >85% form completion rate and <5% data error versus legacy forms; and zero accessibility compliance failures in an independent WCAG audit.
I began by conducting a two-hour domain expert interview with Jose Ricardo Reina, Achēv's NAARS product lead and HEARTS system architect. This single conversation proved invaluable. Jose walked me through the entire client journey—how newcomers arrive, what information assessors need to gather, how decisions about referrals are made, and how HEARTS (the existing language program management system) stores client records. He provided a complete inventory of 160+ questions mapped to service domains: housing, language, employment, family services, mental health, legal aid, disability support, and social networks. Crucially, he explained the conditional logic: asking about dependent children triggers childcare questions; reporting no employment means skipping certain employment training pathways; indicating a disability opens access to specific referral streams.
The research artifact—an Excel spreadsheet with question-by-question metadata, field types, conditional workflows, and lookup tables—became the blueprint. I also reviewed the RFP (Request for Proposal) and contractor agreement to understand hard constraints: timeline (3 weeks design + 2 weeks QA), accessibility requirements (WCAG 2.1 AA non-negotiable), and deployment contexts (must work for staff-conducted interviews and client self-service). Three insights shifted my approach: First, this isn't just a data collection form; it's a critical touchpoint for vulnerable populations (refugees, displaced persons, ESL learners). Design clarity directly affects whether clients feel respected. Second, the conditional logic is extraordinarily complex—70+ questions have branching dependencies. This must be transparent in Figma so developers don't introduce errors. Third, clients span from "comfortable with web browsers" to "first time using a computer," so every interaction must feel obvious and forgiving.
I explored three conceptual directions. Direction One: a single-page accordion form with all 160 questions visible, conditionally hidden with toggles. This felt mobile-friendly but would overwhelm users with varying digital literacy. Direction Two: a linear multi-step questionnaire with section-based navigation, showing one question group per screen, conditionally skipped sections removed from view entirely. This aligned with the RFP's usability requirements and had proven UX patterns. Direction Three: an AI-assisted branching questionnaire that reordered questions based on answers for shortest paths. This was elegant but too high-risk for the three-week timeline and would require custom developer logic beyond scope.
I selected Direction Two—linear multi-step with progressive disclosure—as the balance between UX and implementability. The pivotal iteration came when I stopped thinking section-by-section ("How should Part 1: Client Intake layout?") and started mapping the form as a state machine: Question 1 → If answer = X, go to Q5; if answer = Y, skip to Q8. This reframed the entire problem from "layout" to "logic." Once the conditional graph was mapped visually, the UI (buttons, progress indicators, section groupings) fell into place naturally.
Domain expert feedback shaped every iteration. Jose emphasized that the Support Services section (asking about accessibility needs: childcare, translation, disability support) should come early—assessors need to know what accommodations to provide before asking demographic questions. Charles Curl (IT PM) stressed that the form must be completable via phone interview (staff reads questions, enters answers), printable for offline reference, and saveable mid-session for multi-visit clients. This led me to reject JavaScript-heavy interactions; vanilla form behavior ensures maximum accessibility and implementability.
User testing with actual newcomers didn't happen during design (timeline constraint), but would have been ideal. Instead, I validated assumptions through accessibility checklist review, close collaboration with Jose, and iteration on responsive layouts to ensure usability on iPhone, Android, tablet, and desktop.
I built the design system entirely in Figma, creating reusable components for every form element: text inputs, checkboxes, radio groups, dropdowns, buttons, error states, success states, and progress indicators. Each component has variants for enabled, disabled, error, and focus states—critical for accessibility testing and developer implementation. I documented conditional logic in three ways: visual flow diagrams (Figma artboards showing every branching decision), a "logic key" mapping (CSV format with parent questions, answer conditions, and dependent questions), and inline annotations within wireframes.
The key technical tradeoff: custom branching questionnaire versus standard form structure. I chose the standard form because it has better accessibility baseline support in browsers, faster developer implementation, and fewer dependencies. Progressive disclosure—removing conditionally hidden questions from the DOM rather than hiding with CSS—required careful state management but prevents screen readers from announcing irrelevant fields.
Another decision: responsive design from the start, not as an afterthought. I designed desktop (1024px+), tablet (768px), and mobile (375px) simultaneously, ensuring touch targets hit the 48px WCAG minimum, inputs stack cleanly on narrow screens, and the progress indicator remains visible at all breakpoints. No overlapping form layers or modals—everything linear and scrollable for accessibility and predictability.
The handoff to engineering included: (1) organized Figma file with clear layer naming; (2) design tokens document (colors, typography, spacing, breakpoints); (3) conditional logic spreadsheet in JSON format; (4) Figma components exported as a design system; (5) Accessibility checklist (WCAG 2.1 AA requirements mapped to specific design elements); (6) QA test cases provided by Achēv IT team.
The design was delivered on schedule, March 7, 2026, and passed QA review with Achēv IT team. The Figma file contains 23 core components, 3 form sections with complete wireframes for desktop and mobile, conditional logic flows documenting every branching path, and accessibility annotations for WCAG 2.1 AA compliance. Expected post-launch outcomes (Q2-Q3 2026) include >85% form completion rate, 15–25 minute average completion time, and <5% data error versus legacy paper forms. Achēv estimates saving 10–15 minutes per client through automation of data entry, translating to ~100–150 staff hours saved monthly across 8 locations.
Beyond metrics, the project shifted organizational perception of design. Achēv leadership recognized UX as strategic, unlocking resources for follow-on projects (employment screening form redesign, housing intake, youth assessment system). Government funders will gain visibility into settlement patterns at scale—data to justify funding and measure social impact. The design system in Figma serves as a template for future assessment forms, accelerating development of next-phase initiatives.
The single most important lesson: Complex conditional logic forms are design problems first, implementation problems second. I spent 40% of the design effort mapping logic visually and documenting branching rules exhaustively. This upfront rigor prevented downstream developer errors and dramatically compressed implementation time. Spending five hours mapping state machine logic saves fifty hours of debugging.
A second insight: Invest heavily in domain expertise early. The two-hour conversation with Jose compressed weeks of discovery into a single focused session. A shallow understanding of settlement assessment, HEARTS integration, and referral scoring would have sent the design in wrong directions. Getting the subject matter expert in the room on day one was the highest ROI activity.
What didn't go as planned: initial timeline estimation suggested 35 hours/week for 5 weeks. Core design completed in ~120 hours (~3.5 weeks), suggesting either conservative estimation or particularly efficient execution. Learning: thorough domain knowledge reduces design exploration time.
If I started today, I'd conduct quick usability testing with 3–5 newcomers in week two, even remotely. The accessibility audit and developer pairing sessions came too late; earlier involvement would have validated logic assumptions faster.
Engineering development is underway (March–April 2026), with pilot launch expected in May across 1–2 locations and full rollout across all 8+ Achēv offices in June. The natural next phase includes post-launch optimization based on real-world usage heatmaps, identification of question drop-off points, and measurement of actual completion time. Secondary phases would include multi-language UX design (Spanish, Mandarin, Arabic translations + RTL support), an offline-capable mobile app version, and integration with referral tracking dashboards so case workers can see referral acceptance rates and client outcomes.
Open questions remain: How do clients with extremely limited digital literacy experience this form? Will the current question order optimize completion, or should branching logic reorder questions per user path? How will the form integrate into existing case worker interview workflows across phone, in-person, and hybrid modalities?
This project transformed NAARS from a strategic initiative into tangible design reality. Its success will unlock Achēv's broader digital transformation roadmap and position the organization as a tech-forward settlement provider in a competitive, growth-hungry sector.
Design clarity for vulnerable populations isn't a nice feature—it's a responsibility. Every interaction, every field, every error message is an opportunity to communicate respect.
