Edtech · Training Platform + Job Portal

Alokito Teachers

Train teachers, then help them get hired

The Alokito school dashboard on a soft warm gradient: 6 of 25 seats free on the current plan, counts of enrolled, pending, in-review and rejected teachers, and the registered teachers table with Enroll buttons

Role: UI/UX Designer
Team: Worked with 2 developers
Scope: Design system · Website · Training platform · Job portal
Read: 3 min

Training on one side, hiring on the other. The rules of the programme had to show on screen, and both products had to feel like one.

01/The project

Train teachers, then help them get hired

Alokito Teachers is a Bangladeshi startup that trains people to become teachers, then helps schools hire them. The public site was badly outdated, and the platform behind it didn't exist yet.

I was the only designer, with two developers. I designed the design system, the website, a training platform for four roles (teachers, schools, trainers and admins) and later a job portal. The hard part was the rules: phases that unlock in order, seats schools pay for, a score that carries into hiring. All of it is live. It's under NDA, so this page shows a selection, using sample data and a light visual refresh.

01Sole designer, 2 developers
02Website + 2 products
034 roles
04Live

02/At a glance

The platform, at a glance

A teacher's training dashboard, and the jobs home where training turns into applications.

One phase open at a timeLater phases wait their turn, and Coming up shows the dates the trainer set.

Readiness firstProfile completeness comes first, because it decides whether you can apply. Each job card has what you need to rule it in or out.

03/Where it started

Two halves nobody had put together

Before designing anything, I looked at what people in Bangladesh already used for each half: Bdjobs for hiring and 10 Minute School for learning. Neither did both. On Alokito, a teacher's training should carry straight into their applications, and a school should be able to hire from the people it trained.

The client also wanted a design system from day one, so I built the foundations before any page.

04/Rules first

I mapped the rules before any screen

Before any UI, I worked through the main flows with the client: signup and the first assessment, the four phases and their prerequisites, and how schools buy and use seats. That map decided what each role needed to see, and what had to behave the same everywhere.

The programme on one pageRedrawn for this page from the flows I mapped with the client. Every rule here shows up somewhere on screen.

05/One system

The same pieces in training and hiring

Because the system came first, a seat plan, a course and a job post are built from the same cards, bars and states.

Shared cardsTraining and hiring use one set of components, so the job portal felt like part of the same product when it arrived.

06/Training

Training platform

Putting the rules on screen

A lock needs a reason. A disabled card doesn't say why. Each locked card names what to finish first, and later phases stay in view so the whole path is clear.
Capacity beside the decision. Schools buy seats before they enrol anyone, so seats left sit right above the Enroll buttons. Billing got its own page.
One question open at a time. The builder keeps the whole assessment in view and opens a single question for editing, so you always know where it sits.

Finish to unlockFinishing the course opens the workshop waiting on it. Until then, the card says why it's locked.

Day one, one taskA new teacher can only take the basic assessment, so it leads the page. The wait for review has its own state.

Seats left firstSchools pay per seat, so the plan card leads with what's left. The counts below add up to it.

Edit in placeThe hardest screen. Trainers write the assessment themselves, and every field is one card, edited where it will show.

07/Job portal

Job portal

Designing for where it breaks

The job portal is where the training score gets used. A teacher is judging a job, and a school is judging a candidate. Each side could stall in different places, so I mapped them before designing screens, and the prototype connected every one for the developers.

Where each journey could breakThe main path for each side, where it could stall, and the call I made for each. Redrawn for this page.

Say what's missingInstead of "you can't apply", the form lists what's missing and links straight to it.

After you applySubmitting isn't the end, so the confirmation says what happens next.

Structured requirementsFour steps, saved as you go. Structure is what makes the match score possible.

08/The website

And the website in front of it all

The old site was badly outdated. I rebuilt it on the same system, with a clear route to courses, jobs and plans.

Before and afterThe old homepage, then the new one and the sections it walks through.

09/Outcome

Live, and the client is building on it

The website, the training platform and the job portal are all live. The client was happy with what we shipped, and Alokito raised funding after launch to keep growing. I have no usage numbers to share, and I wouldn't credit the funding to the design.

What I'd keep next time is the order: the rules first, then the system, then the screens. A lock, a seat or a score looks and behaves the same everywhere, which is why adding a job portal later didn't need a new visual language.

More work

All work →