Aino
A learning path built around your job, not around AI.
- Type
- Personal concept project
- Role
- Product thinking, UX and interface design (solo)
- Tools
- Figma
- Note
- I designed it end to end, from defining the problem to the final interface. It hasn't been built and hasn't been tested with real users. The ideas below come from my own reasoning, not from interviews.
Aino is a learning platform for people who feel they're falling behind on AI. Instead of showing you a list of courses, it asks what you do for a living and gives you a step by step path with just the skills your job actually needs.
The core idea
Most of the worry about AI comes down to one question: will this replace me? I don't think that's the right question. If you design for it, you end up with the wrong product: content that sells fear, loud opinions, and courses that just explain what AI is.
A more useful way to look at it, and the one Aino is built on:
AI probably won't replace you. People who know how to use it will.
Looking at it this way changes what the product has to be. If the risk is that the technology replaces you, you need to understand the technology. But if the risk is that a colleague replaces you, you need to get better at the job you already have by using it.
That calls for a completely different kind of learning, and it's different again for an accountant, a lawyer, a teacher and a graphic designer.
Where this idea came from, to be honest: not from interviews. It came from watching how AI education is actually sold and used. There's a huge amount of general “learn AI” content, the courses are built around tools instead of around work, and people keep making the same complaint: they finish a course and still don't know what to do differently at work on Monday morning.
So this idea is my reading of that market. It's a hypothesis, not something I found out.
Who it's for
Aino has two sides, and the second side is what makes the first one possible.
People who feel behind. People who watch AI move this fast and worry that what they've learned so far will soon stop being useful, whether they're just finishing university or already a few years into their work. They don't know where to start. They just want to bring AI into their own field quickly enough not to fall behind.
People who are ahead. Experts who already know AI, or have brought it into their own work, and want to pass that knowledge on to more people, earn from selling courses and grow their personal brand.
I added the second group on purpose. General AI teaching can be produced in one central place, but AI for radiologists, for litigation or for architects can't. That knowledge only exists inside those professions. A platform that hosts these people and pays them can cover a hundred very specific paths, which no internal content team could ever produce.
I sketched one persona for each side: Arash for the learners and Dr. Maryam for the instructors. Both are my assumptions and haven't been tested with real users.
Three decisions
1. No course list on the front page.
The usual structure for a learning platform is a library you browse: categories, search, filters, most popular. It's familiar, it's cheap to build, and it works, but only for people who already know what they're looking for.
The person I designed Aino for is exactly the person who doesn't know what they're looking for. If you drop them into a list, you hand the hardest part of the problem right back to them, and that's the very part they came to get help with.
When you can't judge any of a hundred AI courses, scrolling through them isn't really a choice. You just get stuck.
What I did instead: onboarding starts with a few questions (what you do, what you already know, what you want to achieve), and the first thing you ever see is a path, not a library.
The cost: people have to put in real effort before they get anything back, right at the moment they're most likely to give up and leave. So every question has to clearly change the result. That's why there are only a few questions, they're written in plain language, and you answer them with a tap instead of typing.
2. The path is organized by profession, not by tool.
The obvious way to organize AI education is by technology: prompting, image generation, automation, agents. Every competitor does it that way, and it's easier to produce.
I organized it around the work someone in a specific role has to get done instead. The unit isn't “learn this tool.” It's “this is how work in your field gets done now.”
The reason is the exact problem this whole product exists to solve. What you learn around a tool doesn't carry over well. Someone finishes a general prompting course, goes back to their real work, and can't connect the example from the lesson to the task on their desk. Making that connection is the whole value, and courses built around tools leave it to the learner.
The cost: the course list breaks into many pieces. Instead of one prompting course for everyone, the same material has to be taught again inside each profession. That's expensive, and it's the strongest reason for the model with two sides I described above. So here, the structure of the product and the business model are really the same decision.
3. You can see the path and change it.
A path made by an algorithm has a trust problem: the user has no way to tell whether it was really made for them, or whether it's a template with their job title dropped in. And as soon as they suspect the second, the main promise of the product falls apart.
So I show the path as a series of steps the user can open up and change: reorder them, remove what they already know, or mark a step as done. Each step also says in one line why it's there, and that reason points back to an answer they gave.
The other option was a clean, closed path that basically says “trust us.” That looks nicer in a screenshot, but it's worse to actually use. Personalization you can't question feels more like a marketing claim than a feature.
Structure
Aino has two parts, one for each role: the learner side (onboarding → path → course → progress) and the instructor side (creating a course → publishing → earnings). What people do on each side is very different, but both sides are built from the same pieces: course cards, profiles and lists. That's why one design system works for both, and I didn't need to design two separate products.
Interface
Honest limits
Aino is a concept. It hasn't been built, and no part of the idea has been tested with the people it's about.
That matters most in one place: the whole product rests on the assumption that working people want AI training for their own job badly enough to fill out a questionnaire before they see any content. That assumption can be tested, and I didn't test it. The cheapest way would have been a landing page describing the path for three specific professions, then checking whether anyone actually finished a short form of five questions 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, not one I'd heard someone describe. 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
That way of looking at it. The sentence AI won't replace you; people using it will did more work than any feature on this page. It ruled out the obvious product, picked the audience, shaped the structure and explained the business model. For me, getting that one sentence right was the design work.