Our Ability — Manoj Venkatesun

The problem

Our Ability is one of the few job platforms built for people with disabilities. The product worked. It just worked badly for the people it was built for.

I went through the old interface screen by screen and wrote down what I found.

The dashboard had a profile, a job feed, and a chatbot competing on one screen. Twelve coloured status pills with no key explaining what the colours meant. Sixteen skill tags in pink and yellow. A button saying "Return to Job Coach Portal" sitting on a candidate's page, where it didn't belong. The chatbot took up the left third of the screen and also doubled as the navigation menu.

My annotations on the old candidate dashboard. Everything competing for the same space, and a chatbot doing two jobs at once.

Job cards didn't have a consistent shape. Some had a verification badge, some didn't, so the layout shifted from card to card. If you can see the page that's mildly untidy. If you're hearing it read out, it's disorienting.

Inconsistent card layouts meant nothing you learned on one listing carried to the next.

The job detail page was a wall of text with no headings to jump between and no back button. To leave, you had to find "My Jobs" in the left menu.

No headings, no back button, and the apply button below the fold.

The chatbot only gave you buttons. There was no way to just type what you needed.

Scoping the redesign

Our Ability had four features: the candidate dashboard, the chatbot, a job coach portal, and an employer dashboard. My brief was to redesign all four.

I started by mapping how each type of user moved through the product. Job seekers, job coaches and employers all had different paths, and I wanted to understand all three before deciding anything.

Job seeker flow. The chatbot exists to catch people whose profile isn't complete enough to match against.

Employer flow. Mapped, then cut from this phase.

Then I took the plan to the founder and the managers and argued against it.

Not because of the timeline, though the timeline was tight. The reason was our users. Most people can handle an interface changing. You open an app, it looks different, you poke around for a minute and work it out. That isn't how it goes for someone who's built muscle memory around a screen reader path, or who finds an unfamiliar layout genuinely hard to process. Change everything at once and you don't get a better product. You get people who stop using it.

So I proposed shipping in batches. Redesign the candidate dashboard and the chatbot first, launch, see what happens, then keep going.

Stakeholders wanted to cut the job coach too. I pushed back on that one. Every candidate on Our Ability gets a job coach with unlimited support, and no competitor offers that. Cutting it would have removed the thing that makes the product worth using. It stayed, just not in this phase.

The employer dashboard I agreed to drop. It matters, and I'd want to design it, but it doesn't help a candidate get a job. With twelve weeks and one designer, that made it the easiest thing to let go.

Research

Three types of research over the first two weeks.

I interviewed ten job seekers who used the platform, including screen reader users, keyboard-only users, and people with motor impairments. I watched them try three things: complete a profile, search for a job, submit an application.

I sent a survey to the wider user base to check whether what I saw in interviews held up. Fifty people responded. The complaints lined up: accessibility barriers first, then poor job matching, then confusing navigation.

Then I sat with five users while they used the dashboard live. This was the most useful thing I did. People said the site was "fine" in interviews and then visibly struggled when I watched them use it.

I mapped the whole journey from finding the platform to waiting for a response.

Six stages, with the emotional arc across the top. The lowest point is profile creation, which is also where people gave up.

Every stage had friction. The worst was profile creation. People would start the form, hit an unlabelled field or a broken tab order, and give up. They never reached the job search at all.

Grouping everything into an affinity map, three things kept coming back.

Seventeen observations grouped into five themes, with what shipped against each one and what didn't make it into this phase.

People couldn't finish basic tasks without someone sighted helping them. The interface gave no feedback when something went wrong. Navigation changed from page to page, so nothing you learned on one screen carried to the next.

Those three became what I designed against.

Four rounds

01 · First pass

I put skill percentiles on the dashboard, assuming people would want to see how they scored. Job cards had a title, company, save button and view button. I left the job detail page alone because it was just text and an apply button, and I thought that was fine. Video resources went at the bottom of the dashboard. I put a search bar and location picker on every page, including the dashboard.

Most of that was wrong.

The skill percentiles were interesting to look at and useless for finding a job. The job cards gave you no reason to trust them, because nothing told you whether a job was a fit. Search on the dashboard was clutter, since nobody searches from a page they haven't finished reading. And burying video resources at the bottom meant nobody would find them.

Stakeholders pushed back on the search bar placement. They were right.

Early dashboard sketches. Three variants of the tile layout before landing on one.

02 · Adding context

I added action cards at the top of the dashboard, so the first thing you see is either "finish your profile" or "watch a tutorial" depending on what you haven't done yet. Below that, recommended jobs with a match percentage on each one.

The match percentage came out of a conversation with the PM. We already had user skills and job requirements sitting in the database with nothing connecting them on the front end. Putting a number on the card meant someone using a screen reader could hear "90 percent match" and decide whether to keep listening.

Then I talked to users and stakeholders about the job detail page and found out I'd been wrong to skip it. People wanted to know which skills they were missing and how to prepare for the interview. That page needed to do more than list a description and an apply button.

I moved navigation from the left sidebar to a toggle bar across the top. It looked cleaner. More room for content. I put video tutorials in as a third tab.

It failed in testing.

Screen reader users couldn't navigate it. Almost everyone I tested went looking for the left sidebar first and got stuck when it wasn't there. The video tutorials sat in a tab nobody found, so a whole section of the product went unused.

The version that got thrown out. These screenshots predate the final visual system, which is why the buttons and colours don't match the rest of this case study.

Two things survived this round. Users asked for voice search alongside the text search, which made it into the final version. And I designed toast notifications for application success and failure, which also stayed.

04 · Reverting and refining

I put the sidebar back. Muscle memory beat visual cleanliness, and for this group of users that isn't a close call.

The dashboard got cut down to what matters during a job search: profile completion, applications submitted, jobs saved, upcoming interviews. A chart for activity over time. An interview calendar.

The dashboard that shipped. Four numbers that matter during a job search, and nothing else.

The chatbot moved out of the sidebar and became a floating button. In the old design it took a third of the screen whether you wanted it there or not. Floating, it stays available on every page without competing for space.

Before: Before and after. The chatbot went from occupying a third of the screen to a floating button you open when you need it. — Before and after. The chatbot went from occupying a third of the screen to a floating button you open when you need it.

After: Before and after. The chatbot went from occupying a third of the screen to a floating button you open when you need it. — Before and after. The chatbot went from occupying a third of the screen to a floating button you open when you need it.

Design decisions

Profile completion, split into four steps

The old form put everything on one long screen. I broke it into Personal Info, Education, Work Experience, and Extra-curricular, with a progress indicator at the top. You see one section at a time and nothing else.

This wasn't only about reducing clutter. Job recommendations get better the more of your profile is filled in, so the form wasn't a chore to get through, it was the thing the whole platform depended on. That meant it had to be something people would want to finish, not just something they could finish.

Labels sit above the fields rather than inside them as placeholder text. Placeholder text disappears the moment you focus a field, which is a problem when you're relying on a screen reader to tell you what you're typing into. Error messages appear directly under the field and get announced.

Before

After

Before and after. One long screen became four steps, with labels that stay visible.

Filters and match scores on job search

Experience level, remote or hybrid or on-site, date posted. Plus the match percentage on every card, so people can skip what isn't worth their time.

Before: Before and after. The match percentage and the missing-skills line mean you can judge a listing without opening it. Across the full grid, the four match bands are distinguishable by label as well as colour. — Before and after. The match percentage and the missing-skills line mean you can judge a listing without opening it. Across the full grid, the four match bands are distinguishable by label as well as colour.

After: Before and after. The match percentage and the missing-skills line mean you can judge a listing without opening it. Across the full grid, the four match bands are distinguishable by label as well as colour. — Before and after. The match percentage and the missing-skills line mean you can judge a listing without opening it. Across the full grid, the four match bands are distinguishable by label as well as colour.

The job detail page rebuilt around two questions

What am I missing, and how do I prepare. Labelled sections so screen readers can jump between them. A sticky apply button at the top instead of below the fold. A panel showing which skills you don't have yet. Interview prep linked from the page.

Before: Before and after. A wall of text became a page you can navigate by heading. — Before and after. A wall of text became a page you can navigate by heading.

After: Before and after. A wall of text became a page you can navigate by heading. — Before and after. A wall of text became a page you can navigate by heading.

A looser chatbot

Every response in the old version was a button. The new one keeps quick replies for common paths but lets you type freely, with voice input for people who find typing slow or painful.

Resources that show you what you're getting

The training library was a list of five links. No thumbnails, no descriptions, no way to tell what a resource covered before clicking it. In research this came up as people not knowing what they'd get, so they didn't click at all.

I rebuilt it as cards with a thumbnail, a category tag, a description and a rating. Same content, but now you can decide whether something is worth your time before opening it.

Before: Before and after. Five plain links became cards you can actually judge. — Before and after. Five plain links became cards you can actually judge.

After: Before and after. Five plain links became cards you can actually judge. — Before and after. Five plain links became cards you can actually judge.

Accessibility

Every screen went through the Stark plugin in Figma.

Body text at 8.08:1, clearing AA at 4.5:1 and AAA at 7:1.

Everything interactive works with a keyboard and gets announced by a screen reader. The profile stepper shows distinct states for completed, current and upcoming, and each step is focusable. Match badges carry a word as well as a colour, so the meaning survives colour blindness and greyscale.

The thing this project taught me is that passing an audit and being usable aren't the same. You can hit every contrast ratio and still ship something people can't get through. The real problems here were structural: an information architecture that didn't make sense, forms built for a mouse, a flow you couldn't follow without sight. Contrast was the easy part.

Touch target audit. Every interactive element clears the 44px minimum, which matters more than usual on a platform where a lot of people have motor impairments.

Type scale audit. Nothing below 12px, and body text never below 14px.

I also ran every screen through vision simulations. This is where the match badge decision earned its keep.

Deuteranopia. Green and blue badges converge, so the percentage and the label are the only things telling you which band a job falls into.

Full greyscale. Nothing depends on colour to be readable.

Reduced contrast, closer to how a lot of our users actually see the screen.

This is why every match badge carries a word as well as a colour. "78% · Good match" survives all three. "78%" in blue does not.

Results

What shipped. A full design system covering the dashboard, profile flow, job search, job detail and chatbot, with annotated specs. The front-end team built directly from it.

Accessibility. WCAG 2.1 AA across every screen. 8.08:1 on body text.

Testing. I tested with five to ten users with a range of disabilities. Each person got a different task: finish a profile, find and apply to a job, or use the chatbot. Most finished without help. Navigation was the sticking point. Several people needed me to explain what each tab held before they could get oriented, though once I explained it they moved through fine. The chatbot gave a few people trouble.

Stakeholders. John Robinson, the CEO, said I brought his vision into reality and that I designed the dashboard the engineering team built from. The PM said the work went past what the client expected.

What I learned

Consistency matters more when people can't scan. If you can see a page you can recover from an inconsistent layout. You spot the button somewhere else and move on. On a screen reader you can't. Every time a button style changed or navigation shifted between pages, someone who'd learned the pattern on the last screen hit a wall. I started treating consistency as an accessibility requirement rather than a nice-to-have.

Test rough work early. I nearly waited for high fidelity before showing anything to users. Paper prototype testing caught two navigation assumptions I'd carried over from the old design without questioning them. Finding those later would have cost a sprint.

Sometimes the right answer is to change less. The instinct with a broken product is to redesign all of it. For this group of users that would have made things worse before it made them better.

What I'd do differently

Two things stayed with me after the twelve weeks.

AI-assisted job matching, not a chatbot, but something built into how the platform works. Right now someone still has to scroll a recommended list and work out for themselves which roles are actually accessible and suited to them.

Voice as the main way to use the product, not an accessibility add-on. A lot of people on this platform find typing slow or painful. Most platforms treat voice as a checkbox. Building around it would change the experience for a real portion of the user base.

That gap is pretty obvious once you've spent twelve weeks looking at it up close.

Redesigning a disability job platform that was hard to use if you had a disability