Open Kharkiv

Case

A redesign of Kharkiv’s city app: the new branding, new services and accessibility.

Role
UX/UI Designer
Team
2 designers
Platform
iOS · Android
Duration
10 months, MVP shipped in 1.5
Status
Live
Type
Team of 2 · 2025–2026
In short
Problem
Kharkiv’s app, which Roman had built earlier, looked outdated: the branding had changed, and new city services had nowhere to go.
What I did
Flows in parallel with Roman. Fully mine: the UI kit and styles, accessibility, sign-in, the Invincibility Points map, and the redesign of news, surveys and the card application.
Result
The first MVP in the new design went live in a month and a half, followed by 10 months of work on the app. Four colour modes, text up to 160%. I don’t have usage data.
1.5 moto the first MVP in the new design going live
160%maximum text size
4color modes on one token set
Open Kharkiv – project screens
Context

Before us, Roman had built the app on his own. The design had aged, the branding had changed, and new services had no place to go.

So it was a redesign, not a facelift: a new system, a new home screen, sign-in and transport, plus services the app never had. We worked on the app for 10 months; the first MVP in the new design went live in a month and a half.

Constraints: releases alongside development, no research with people, and text size in the accessibility modes is calculated by developers with a formula.

The old version: home with a card, a card reissue status, choosing a sign-in method
The old version: a home of identical tiles · “call the hotline” with nothing to do in the app · sign-in opens with a paragraph about BankID
Role

My role

Roman and I ran flows in parallel and reviewed each other’s work; the brand book, icons and animations are his. Fully mine: the UI kit and styles, accessibility, sign-in, the Invincibility map, and the redesign of news, surveys and the card application. We took the first versions of maps and transport through together.

Module map: home, information, city and transport, services, system, accessibility
Changes

What changed

AreaBeforeAfter
HomeThe same tiles for everyoneAdapts to the person: signed out, no card, with a card
Card statusesText on a banner, “call the hotline”A reason and an action: “Fix the application”, “Contact support”
Sign-inA paragraph about BankID, other methods as rowsMethods grouped, 17 new states – errors, returning sign-in, code reset
TransportA map with route numbers and one shared list of routes, no metroA map, stop routes with timetables, metro with lines
News and eventsEach filter on its own screenAll filters on one screen
AccessibilityNoneText at 100, 130 and 160%, four colour modes
New services–“My deputy”, “For Defenders”, the Invincibility map, a notification centre
Accessibility

Accessibility and system

Accessibility is part of the system, not a feature at the end: high contrast, greyscale and text at 100, 130 and 160%, with cards growing with the text. Underneath are 48 semantic tokens in four modes, so a theme or contrast mode is a mode switch, not a new set of mockups. Buttons are 48 px: the client asked for narrower ones and accepted 48 after I argued with the standards.

Home in light theme, high contrast and with 160% text
Light theme · high contrast · high contrast with 160% text
Home in Dark, High contrast and Dark high contrast modes
Home: Dark · High contrast · Dark high contrast
Decisions
Decision 01

The home screen adapts to the person

Why
People open the app signed out, without a Kharkiv resident card, with a card, or with an application under review or rejected. The old home showed the same tiles to everyone.
What I did
Home changes with the state: news and “Sign in with ID.GOV.UA”, news for people without a card, the X-card and quick actions for people with one.
Result
Everyone sees their own next step instead of the same set of tiles.
After: home signed out, without a card and with a cardBefore: home signed out, without a card and with a cardBeforeAfter
Before: “Sign in” · no card · a grey card and tilesAfter: news and sign-in · no card · X-card and quick actions
Decision 02

A card status always has a next step

Why
In the old version a status was text on a banner. A blocked card said “call the hotline”, and there was nothing else to do in the app.
What I did
A screen for each status: what happened and what to do. Application rejected – “Fix the application”; card blocked – “Contact support”. A placeholder for the card while the application is under review.
Result
A rejection or a block is no longer a dead end: the action is right on the status screen.
After: application under review, card blocked, application rejectedBefore: application under review, card blocked, application failed the checkBeforeAfter
Before: status as banner text, the hotline as the only way outAfter: a reason and an action button on every status
Decision 03

Sign-in: the same methods, a clearer choice and every state

Why
The old sign-in opened with a paragraph about BankID, with the other methods as identical rows below.
What I did
Sign-in through ID.GOV.UA with grouped methods: e-signature (file, token, cloud storage), Bank ID NBU, Diia.Signature, Diia.OAuth. A “Me” or “My child” choice, date of birth, secure sign-in with a code and biometrics.
Result
17 new states that weren’t there before: expired code, too many attempts, no internet, sign-in cancelled, passport not found, session ended and more.
After: sign-in with ID.GOV.UA, who will use the app, child’s date of birthBefore: choosing a sign-in method with BankID, who will use the app, child’s date of birthBeforeAfter
Before: a paragraph about BankID, other methods as a listAfter: methods grouped, a “Me / My child” choice
Decision 04

Transport and metro

Why
Names and CTAs were unclear, search and timetables needed rework, and end stations had no scenarios of their own, and the app had no metro at all.
What I did
New names and CTAs, search, timetable structure, end-station scenarios, a new metro section with lines, timetables and exits, a limit on saved routes. Separate states: air-raid alert on the map, offline, location off.
Result
The metro shows directions, weekday and weekend timetables and open exits; the map shows accessible transport.

StatusThe flows were approved by the client. The timetable was reworked several times at their request; no testing with people.

After: city transport map, routes at a stop, a metro route on the mapBefore: city transport map, the list of routes, a metro route on the mapBeforeAfter
Before: map, list of routes, a metro routeAfter: map, routes at a stop, the new metro

Prototype

Transport map, route search and news

Screens from the final design. The prototype plays on its own; switch to “Try it yourself” to click through it.

  1. Home
  2. Transport map
  3. Stop search
  4. Routes at the stop
  5. Route details
  6. Route on the map
  7. News and events

New

New, not there before

The old version had none of these services. The biggest of mine are requests to a deputy and the “For Defenders” booking.

“My deputy”: requests with clear statuses

People sent a request and didn’t know what was happening with it or where to find replies. Now there are statuses, a reason if a request isn’t reviewed, and the whole reply history in the request card, with documents and a rating.

The path of a request and its statuses

“For Defenders”: booking a visit from the phone

You pick a request category, read the service description, choose a date and a free time slot and fill in the applicant’s details. After booking there’s a ticket with the details, and the booking appears in the list on the service home. Institutions can be found on a map or in a list, filtered by district and type. Separate states: no free time on the date, booking failed, booking cancelled by the institution, missed visit.

For Defenders: categories, time picker, applicant details
“For Defenders” · time picker · applicant details

Filters on one screen, text you can read

Each event filter used to open as a separate screen. Now all filters are on one screen, and selected ones clear with one tap. Headings 26 px, body 16 px, buttons 48 px.

Events: list, filters with a date and category picked, nothing found
Events: list · filters · nothing found
Outcome
  1. 01

    A city app holds together through shared rules: I turned 33 colours from the approved screens into styles and merged the toasts into one component, and news, transport and requests began to behave the same way.

  2. 02

    Not everything was accepted: I proposed surveying people about what Home needs and making it lighter, but Home stayed as approved.

  3. 03

    Without research, approval didn’t answer whether things got easier. Next I’d test transport search, request statuses and the enlarged-text interface with people.

Contact

Write to me

It goes straight to my inbox, and I’ll reply from there.

Testimonials

Leave a testimonial

It appears on the site after I review it.