An app that helps BC Students Claim the Benefits they’re unaware of.
My Contributions
UI/UX Design
Prototyping
User research
Responsiveness
Design system
Duration
4 weeks
Team
2 UI/UX Designers (me)
1 Developer
Tools
React Native
Expo
Anthropic Claude API
Overview
Avail is a mobile-first tool that matches BC students to benefits they didn’t know they qualified for, built as a final project for a BCIT app development course.
Avail walks a student through a short quiz, matches them with BC benefit programs using Ask Avail, an in-app AI, that provides results users can browse, filter, apply, or ask follow-up questions. The app is functional, not just a static prototype, and runs on Expo.
Four decisions shaped the design:
- A discovery tool, not an eligibility checker. Welcome copy and “likely eligible” badges make that clear on screen instead of burying it in fine print.
- Minimal onboarding. A 5-question quiz, under 2 minutes, no account required.
- Results at three depths. Top 3 on Home, a filterable Benefits list, and a detail page with eligibility, how to apply, and a source link.
- Guided prompts in Ask Avail. The chat opens with suggestions instead of a blank search bar, because an unfamiliar AI feature already causes hesitation.
This demo video shows the app in use.
Problem
People have missed out on close to $9B in benefits over five years, simply because they don’t know the programs exist.
$9B
Canada’s Parliamentary Budget Officer found benefits missed by Canadians who don’t file taxes add up to about $9 billion over five years, roughly $1.7–1.9B a year.
While existing tools, such as Canada’s Benefits Finder, provide general information about available government benefits, Avail aims to take this step further by identifying benefits users specifically qualify for and breaking down eligibility requirements and application procedures into clear, actionable steps. By making benefits easier to discover and understand, Avail helps bridge the gap between available financial assistance and the Canadian students who need it.
Discovery
Early feedback from professionals working at the Federal and Provincial levels of government challenged our initial project scope.
Our original proposal covered federal and provincial benefits for all Canadians. During our brainstorming phase, our instructor took the proposal to contacts in the government sector for feedback, helping direct us to a more achievable outcome in a shorter time frame, as we only had 4 weeks until the deadline.
“No single ‘centralized’ system exists across federal and provincial benefits. You’d be better off narrowing your scope, province vs. federal, and one population vs. others.”
— Feedback from government contacts
Their feedback flagged a problem we'd missed: there's no centralized data source for federal and provincial benefits. Consolidating information across separate government websites and turning their varying eligibility rules into reliable recommendations was more than our four-week timeline allowed.
So we narrowed our scope to BC students. That gave us a manageable set of programs we could curate by hand from official sources, so we could put our effort into making the eligibility matching accurate.
Ideation
Established the token system and validated core layout patterns before moving into individual screens.
With two designers working on separate screens that would eventually be handed off to the developer as one cohesive product, it was important to maintain consistency across our designs. Before splitting screens with my co-designer, I built the token system: colour, type, spacing, states. One source, so neither of us had to reconcile our own version later.
A teal scale, neutral greys, and success/warning/error states, each with a fill, outline, and text variant. Category labels use the same three-part structure:
Spacing is determined by where it's used rather than by scale number: tightest between an icon and its label, small between filter pills or quiz options, larger between cards, largest between sections.
Decisions
An early direction we dropped.
In our early iterations, we explored using an icon grid for answer options to make the process feel simpler and more approachable. However, we found that reducing complex information to icons and brief descriptions could create ambiguity, increasing the risk of users misinterpreting options and receiving inaccurate benefit recommendations.
To address this, we reduced the number of answer options per screen and introduced more targeted questions to progressively narrow down users' eligibility. Our final design included 5 questionnaires, prioritizing simple but focused questions with brief explanations for each option, making the process easier to navigate while maintaining accuracy.
Two early sketches of the quiz answers: an icon grid (left) and a plain list (right). Income brackets and immigration status have no obvious icon, which is why the list won.
The final version of a quiz question: a short list of choices, no icons.
Hand-drawn wireframes covering every screen, the starting point for the final designs.
The final Avail screens in order, for comparison with the early sketches.
Overly specific AI prompts limited benefit discovery.
The user is tasked with answering 5 questions to help the AI match them with the relevant benefits. Once this initial onboarding is complete, the user can explore the benefits themselves, or they can go the Ask Avail chat to learn more about the benefits they actually matched with.
Our initial AI-generated prompts focused on specific benefits and eligibility conditions too early in the conversation. The first version referenced a specific benefit and condition directly, such as, "What's the deadline for the BC Access Grant?", "Do I qualify if I'm part-time?", which narrowed down the users search options before they got to learn more about other benefits.
We redesigned the prompts to focus on broader questions first, allowing users to explore their matched benefits without being directed toward a particular program from the start.
The original Ask Avail screen, with the first set of guided prompts highlighted.
Before
What's the deadline for the BC Access Grant?
Do I qualify if I'm part-time?
Which benefit gives me the most money?
Each prompt named a specific benefit or condition, so it only made sense if that’s what you had matched with.
After
Which benefit gives me the most money?
How do I apply for my matched benefits?
What documents do I need to apply?
These work for any user, whichever benefits they matched with. One prompt from before stayed, because it applies to everyone.
The Screens.
The full flow, frame by frame: onboarding through to a matched benefit, browsing, chat, and profile.
App splash screen
Welcome: find your benefits
Quiz: full-time or part-time
Quiz: type of school
Quiz: annual household income
Quiz: student status details
Quiz: a few more questions
Matching you to benefits
Home: your matched benefits
Browsing all matched benefits
Benefit detail: BC Access Grant
Profile: your quiz answers
Ask Avail: AI chat assistant
Ask Avail: typing a question
Reflection
Build the design system before dividing screens.
I used auto-layout from the start, not just at handoff. The ideation section shows the token structure that came out of it. It kept the team consistent, and let the developer's Expo build match the Figma file with little back-and-forth.
A confident first draft may require a second opinion
The original proposal covered all of Canada. Outside feedback showed there was no centralized data source to build on. Narrowing to BC students gave us a set of programs we could curate by hand, a version we could actually execute in four weeks.
Testing your own product catches problems fast, and has limits.
Our team may have asked predictable questions since we were the ones building the app. However, if this continued past the course, we would have gathered 5 to 10 BC students outside of our program to test this app to obtain more accurate data.
AI matching is only as trustworthy as what you check it against.
Claude's matching only draws on trustworthy sources: the official program information we curated by hand. It was validated against the eligibility criteria we hand-checked, not against edge cases we didn't think to test. With more time, that's where I'd focus next: stress-testing matches against messier student situations before trusting the output.
Other works
