Aino
A learning path built around your job, not around AI.
- Type
- Self-directed concept project
- Role
- Product thinking, UX, interface design (solo)
- Tools
- Figma
- Note
- Designed end to end, from problem framing to high-fidelity interface. Not built, and not validated with users — the thesis below is reasoned, not interviewed.

Aino is a learning platform for people who feel they're falling behind on AI. Instead of a catalog of courses, it asks what you do for a living and returns a sequenced path of exactly the skills your role needs.
The thesis
Most anxiety about AI is framed as will this replace me?I think that's the wrong question, and designing for it produces the wrong product — fear content, hot takes, and courses about what AI is.
The more useful framing, and the one Aino is built on:
AI probably won't replace you. People who know how to use it will.
That reframe changes what the product has to be. If the threat is replacement by the technology, you need to understand the technology. If the threat is displacement by a peer, you need to be better at your existing job using it— which is a completely different curriculum, and one that's different for an accountant, a lawyer, a teacher, and a graphic designer.
Where this came from — honestly:not from interviews. It came from watching how AI education was actually being sold and consumed: an enormous supply of generic “learn AI” content, courses organized around tools rather than around work, and a persistent complaint that people finish them and still don't know what to do differently on Monday morning. The thesis is a reading of that market, and it is a hypothesis, not a finding.
Who it's for
Aino is two-sided, and the second side is what makes the first one possible.
People who feel behind.Mid-career professionals in non-technical fields who have watched AI become unavoidable and have no idea where to start. They don't want to become engineers. They want to keep their standing.
People who are ahead. Practitioners who have already worked AI into their own field and can package that into a course and earn from it.
The second group is deliberate: general AI instruction can be produced centrally, but AI for radiologists, for litigation, for architectscan't. That knowledge only exists inside the professions. A platform that hosts and pays those practitioners can cover a hundred narrow paths that no in-house content team could ever produce.

Three decisions
1. No catalog on the front page.
The default architecture for a learning platform is a browsable library: categories, search, filters, popularity. It's familiar, it's cheap to build, and it works — for people who already know what they're looking for.
The person Aino is designed for is defined by not knowing what they're looking for. Dropping them into a catalog hands the hardest part of the problem straight back to them, and it's the part they came to outsource. Browsing a hundred AI courses when you can't evaluate any of them isn't choice; it's paralysis with better graphics.
Instead:onboarding opens with questions — what you do, what you already know, what you're trying to achieve — and the first thing you ever see is a path, not a library.
What it costs: real friction before any value is delivered, at exactly the moment abandonment is highest. Every step in that questionnaire has to justify itself by visibly shaping the result, which is why the questions are few, plainly worded, and answered by tapping rather than typing.
2. The path is organized by profession, not by tool.
The obvious way to structure AI education is by technology: prompting, image generation, automation, agents. Every competitor does it, and it's easier to produce.
I organized by job to be done in a specific role instead — the unit isn't “learn this tool,” it's “here is how work in your field gets done now.”
The reason is the failure mode this whole product exists to fix. Tool-shaped learning transfers badly: someone finishes a general prompting course, returns to their actual work, and can't bridge the gap between the example in the lesson and the thing on their desk. That bridge is the entire value, and tool-organized curricula leave it to the learner.
What it costs: it fragments the catalog. Instead of one prompting course serving everyone, you need it re-taught inside each professional context — which is expensive, and is the single strongest argument for the two-sided model above. The architecture and the business model are the same decision.
3. The path is visibly editable.
An algorithmically generated path has a credibility problem: the user has no way to tell whether it's genuinely tailored or a template with their job title pasted in. And the moment they suspect the latter, the product's core promise collapses.
So the path is shown as a sequence the user can inspect and change — reorder it, remove what they already know, mark something as done. Each step states why it's there, in one line, tied back to an answer they gave.
The alternative — a clean, sealed, “trust us” path — looks better in a screenshot and is worse to use. Personalization that can't be interrogated reads as a marketing claim rather than a feature.

Structure

Two role-based sections sharing one system: the learner side (onboarding → path → course → progress) and the instructor side (course authoring → publishing → earnings). The overlap between them is small, which is what makes a single design system across both viable.
Interface



Honest limits
Aino is a concept. It hasn't been built, and no part of the thesis has been tested with the people it describes.
That matters most in one place: the entire product rests on the assumption that professionals want role-specific AI training badly enough to sit through an onboarding questionnaire before seeing any content. That's a testable claim and I didn't test it. The cheapest test would have been a landing page describing the path for three specific professions and measuring whether anyone completed a five-question intake to see it.
What I'd do differently
Run that test before designing the interface. I designed a solution to a problem I had reasoned my way into rather than one I'd heard someone describe — and I know the difference, because on a later project I did it the other way around and the product came out different.
What I'd keep
The reframe. AI won't replace you; people using it will did more work than any feature on this page. It rejected the obvious product, chose the audience, dictated the architecture, and explained the business model. Getting the sentence right was the design work.