Selected product work by Ihor Popov

Creating seamless experiences for complex systems.

View selected work About the work
import { observe, map } from "./research";
import type { Problem, Flow } from "./types";
/** UX: understand the work */
export function ux(problem: Problem): Flow {
const people = observe(problem.users);
const journey = map(people.tasks);
// remove what slows people down
return journey.without("friction");
}
import { arrange, compose } from "./layout";
import { grid } from "./tokens";
import type { Content, Screen } from "./types";
/** UI: shape the interface */
export function ui(content: Content): Screen {
const layout = arrange(content, grid);
const states = ["empty", "loading", "error"];
// every state, not just the happy path
return compose(layout, states);
}
import { ux } from "./ux";
import { ui } from "./ui";
import { test, refine } from "./validate";
import type { Brief } from "./types";
/** Design: align UX and UI */
export async function design(brief: Brief) {
const flow = ux(brief.problem);
const screen = ui(brief.content);
const findings = await test(flow, screen);
return refine(screen, findings);
}

01 / Selected work

Selected product work.

Every card opens its case. Each one is presented the same way: stage, role, scope, and the outcome the evidence supports.

Domains
  • E-commerce
  • Travel
  • Hospitality
  • Fintech
  • Developer tools
  • B2B operations
Responsibilities
  • Product discovery
  • User interviews / usability testing
  • UX audits
  • Workflow design
  • Interaction and UI
Tools and methods
  • Figma and FigJam
  • Notion
  • BMad Method
  • Cursor / Claude Code / Codex
Design engineering
  • Prototypes in code
  • Design systems in code
  • Motion and interaction
  • WCAG 2.2 AA checks
  • Visual regression tests

02 / Skills

What I bring to a product team.

Research, structure, and interface work, not one of them alone. Hover over a skill, or select it, to read how I have applied it and why it pays off.

Research and discovery

Learn how the work is really done before drawing anything.

  • Research and discovery

    User interviews

    How I apply it

    I use interviews to learn how people actually do the job before the interface exists: their objects, hand-offs, workarounds, and the moments a task stalls. I prepare a short guide, let the person walk their own process, and record what they say rather than my conclusions.

    Why it pays off

    Verbatims turn a requirements list into pains a team can argue about. On Malkai the reservation agent's day, gathered in requirement sessions I took part in, became the chapter the whole workflow is built around.

    Shown in

  • Research and discovery

    Usability testing

    How I apply it

    I test with the smallest artifact that can fail: a clickable prototype, a paper flow, or the live build. Participants get tasks, not tours. I note where they hesitate, what they call things, and where they recover without help.

    Why it pays off

    It separates what I think is clear from what is. It is also how I score severity honestly: one break that stops a task outranks a hundred cosmetic notes, and an additive idea stays a hypothesis until people have used it.

  • Research and discovery

    Research synthesis

    How I apply it

    I turn transcripts, notes and support history into a small set of pains and decisions, each tagged with its source and its confidence. A pain with no source is marked as an assumption, not promoted to a finding.

    Why it pays off

    Synthesis is what lets a team stop re-reading the interviews. On Malkai the pains feed the journey map and the decisions directly, and the persona emotion curves are labelled as hypotheses because nobody validated them with the client.

    Shown in

  • Research and discovery

    Journey mapping

    How I apply it

    I map the whole journey first, then draw the slice we are designing inside it: stages, lanes for roles and objects, and where each screen sits. Emotion curves go in only when they carry a real hypothesis.

    Why it pays off

    The map shows what is covered and what is not. On Malkai it exposed that all three guest curves trough at decision and deposit, exactly where the prototype ends, and it names the stages that have no surface yet.

    Shown in

  • Research and discovery

    UX audit

    How I apply it

    I walk the real workflow on the live build, end to end, and capture every screen where it breaks. Findings are written against named heuristics and scored on two axes, user impact and effort, so the labels express triage rather than taste.

    Why it pays off

    A scored audit is a plan, not a complaint list. On Interlace it produced 29 findings in five areas, a phased roadmap, and the brief for one guided admin path.

    Shown in

Structure and strategy

Turn the operation into a route a team can build.

  • Structure and strategy

    Information architecture

    How I apply it

    I decide what is global and what belongs to the object the person is inside, then let the navigation say it. Labels come from the users' words, not from the database.

    Why it pays off

    Most "where am I?" problems are architecture problems dressed as visual ones. On Interlace the sidebar became the project's own inside a project, while the global lists stayed global.

    Shown in

  • Structure and strategy

    Workflow design

    How I apply it

    I model the operation before the screens: objects, states, ownership and hand-offs, and the moment where context gets lost. Each screen is then designed to carry that context into the next one.

    Why it pays off

    It is how a set of pages becomes one route. Malkai's enquiry queue, record, builder and guest itinerary are connected surfaces because the workflow was drawn first.

    Shown in

  • Structure and strategy

    Requirements into specification

    How I apply it

    I translate requirement sessions into workflow and design specifications a team can build from: what each surface must show, which states exist, and what is still open, marked visibly rather than hidden.

    Why it pays off

    A specification that admits its gaps gets reviewed honestly. On Malkai the unresolved navigation stays labelled TBD inside the prototype itself instead of pretending the full product exists.

    Shown in

  • Structure and strategy

    Prioritisation and roadmap

    How I apply it

    Every finding or idea gets a priority from impact and effort, then a place in a phased sequence with the reasoning for that order written down next to it.

    Why it pays off

    Teams ship in order, not all at once. The Interlace roadmap groups the audit findings into six phases and explains why this order and not another.

    Shown in

Interface and systems

Make the decisions visible, consistent and ready to build.

  • Interface and systems

    UI design

    How I apply it

    Hierarchy, states, density and feedback for real working screens: dense where people scan, calm where they read. Every control sits next to the thing it changes.

    Why it pays off

    The interface is the contract people actually experience. The Malkai enquiry queue, the Interlace project home and the commerce storefront each show it at a different density.

    Shown in

  • Interface and systems

    Design systems

    How I apply it

    Tokens, components and content rules shared across every screen, documented with their states and their open defects, and kept honest in both light and dark themes.

    Why it pays off

    A system is what lets a prototype grow without drifting. Malkai's status model and ink registers, and the commerce platform's themeable component library, are the two documented examples.

    Shown in

  • Interface and systems

    Prototyping

    How I apply it

    I build prototypes the team can walk: state-driven, with real content, and close to the build, so a review can test a decision rather than admire a picture.

    Why it pays off

    The smallest artifact that can be wrong is the fastest way to learn. Malkai's front-end proof of concept is live, and the Interlace redesigned path runs inside this site.

    Shown in

  • Interface and systems

    Accessibility

    How I apply it

    Semantic structure, keyboard and touch operation, visible focus, contrast checked on the surface it sits on, and motion that can be removed. Treated as correctness during design, not as a final audit layer.

    Why it pays off

    It is part of the launch definition here and in the cases. The Interlace audit checks contrast as a rule rather than a taste, and this site runs automated WCAG checks on every route.

  • Interface and systems

    Design-to-build hand-off

    How I apply it

    I work in the materials the build uses: tokens, component contracts, state tables and named rules. Engineers get the reasoning and the edge cases, not only the picture.

    Why it pays off

    Less is lost between design and code when the design already speaks code. The Interlace system rules and the Malkai token catalogue are written as build rules.

    Shown in

04 / About

Product designer. Systems thinker. Build-aware collaborator.

Ihor Popov works on complex product flows, interface systems, and prototypes. This portfolio presents selected projects Ihor contributed to, with role and evidence limits stated case by case.

  • Operational workflow modelling
  • Interaction and interface design
  • Design systems and build-aware prototyping
More about the work

05 / Contact

Have a complex product problem?

Start with the part that is hardest to make clear.

Get in touch