Портфоліо Design Engineer у 2026: 4 артефакти, які варто показати

Портфоліо Design Engineer - це не галерея екранів, а набір доказів, що ви вмієте шипити. Гайрінг-менеджер хоче побачити чотири речі: GitHub-репозиторій з чистою структурою і CLAUDE.md, Storybook з компонентами на ваших Figma Variables токенах, змерджений pull request і живий деплой на власному домені з вашими Claude Skills. Усе це можна зібрати на одному проєкті.

Я Dmytro Nikolaienko, 15 років у продуктовому дизайні, засновник UX Hero. Нижче - що доводить кожен артефакт, як його подати в кейсі, на чому найчастіше помиляються, і короткий шаблон кейса, який можна забрати собі.

Чим портфоліо Design Engineer відрізняється від класичного UX-портфоліо?

Класичне UX-портфоліо відповідає на питання «як ви думаєте». Портфоліо Design Engineer відповідає ще й на «чи доходить ваше рішення до користувача без перекладача». Як зібрати сильні UX-кейси з процесом і метриками, я детально розбирав у гайді з UX-портфоліо, тут не повторюватимусь. Ось різниця одним столом:

Критерій	Класичне UX-портфоліо	Портфоліо Design Engineer
Головне посилання	Behance, PDF, Figma-прототип	живий URL, Storybook, GitHub
Що доводить	мислення і процес	мислення, процес і доставку в продакшн
Одиниця кейса	екрани і флоу	компоненти, токени, PR, деплой
Як перевіряють	читають і дивляться	клікають, відкривають код, дивляться історію комітів
Роль AI	упаковка тексту і візуалу	частина процесу: що зробив агент, що вирішили ви
Що застаріває	макет без продовження	нічого, поки деплой живий

Хто такий Design Engineer і які скіли ринок від нього чекає, є в окремому матеріалі Design Engineer у 2026. Тут - тільки про те, як це довести.

Що таке «артефакт» у портфоліо Design Engineer?

Артефакт - це результат роботи, який рев'ювер може відкрити і перевірити сам, без вашого пояснення: посилання, репозиторій, PR, задеплоєна сторінка.

Скріншот - не артефакт. Відео з екрана - напівартефакт. Живий URL, де кнопка реально перемикає тему, - артефакт. Правило просте: якщо рев'юверу треба повірити вам на слово, це ще не доказ.

Артефакт 1: як показати GitHub-репозиторій, щоб його відкрили?

Що доводить: ви вмієте організувати проєкт, працюєте з Git як у команді і налаштовуєте AI-агента, а не просто «щось просите в чаті».

Як подати:

• README на перший екран. Що це за проєкт, живий лінк, як запустити за 1-2 команди, стек одним рядком.
• Зрозуміла структура. Папки components, tokens, stories без сміття і файлів «final-v3».
• CLAUDE.md у корені. Це файл, який Claude Code читає на старті сесії: конвенції, стек, правила для токенів. Він показує, що ви керуєте агентом, а не навпаки.
• Історія комітів, яку можна читати. feat: add Button states замість десяти «fix». Рев'ювер реально гортає історію.
• Закріпіть репо в профілі. GitHub дозволяє закріпити до 6 репозиторіїв, але краще 2-3 найсильніші, ніж шість чернеток.

Типові помилки: один гігантський коміт «initial», порожній README, секретні ключі в коді, форк туторіала без жодної вашої зміни. Як не боятись гілок і комітів, є в матеріалі Git для дизайнерів.

Артефакт 2: навіщо Storybook на ваших Figma Variables токенах?

Що доводить: ваша дизайн-система живе не тільки у Figma. Компоненти мають усі стани, а кольори і відступи йдуть з токенів, а не з хардкоду.

Як подати:

• Публічна лінка на Storybook (наприклад, через Chromatic), щоб рев'ювер відкрив її без клонування репо.
• 5-8 компонентів з усіма станами: default, hover, focus, disabled, loading, error. Краще менше, але повністю.
• Перемикач теми, який реально перемикає semantic-токени. Це найкоротший доказ, що токени з Figma доїхали в код.
• Поруч у кейсі - скрін колекції Variables у Figma з тими самими назвами.

Типові помилки: stories тільки на default-стан, #2563EB прямо в компоненті, назви токенів у коді не збігаються з Figma. Як зібрати таку документацію, щоб її читали, - в огляді Storybook для дизайнерів.

Артефакт 3: чому змерджений pull request важить більше за десять екранів?

Що доводить: ви вмієте провести фічу так, як це роблять у продуктовій команді: гілка, опис, рев'ю, правки, мердж. Для Design Engineer це головний сигнал, що вас можна пустити в репозиторій команди.

Як подати:

• Опис PR: що змінилось, навіщо, скріни «до/після», посилання на preview-деплой.
• Видимі коментарі рев'ю і ваші відповіді на них. Обговорення - це частина доказу, не ховайте його.
• У кейсі - одне речення про те, яке зауваження рев'ю змінило ваше рішення.

Типові помилки: PR сам собі без жодного коментаря, 40 змінених файлів в одному PR, опис з одного слова «update». Якщо реальної команди немає, попросіть рев'ю в колеги-розробника або зробіть PR в open source проєкт з невеликою правкою.

Артефакт 4: що дає живий деплой на своєму домені і власні Claude Skills?

Що доводить: проєкт вийшов у світ, а ви налаштували собі робоче середовище, яке працює і на наступних задачах.

Як подати:

• Свій домен, а не project-abc123.vercel.app. Деплой через Vercel або Cloudflare Pages з preview на кожен PR.
• Lighthouse або перевірка доступності на головній сторінці - одна цифра або скрін у кейсі.
• Claude Skills у репо (папка .claude/skills): наприклад, skill, що перевіряє, чи компонент використовує тільки токени. Опишіть у кейсі, яку рутину він прибрав.

Типові помилки: лінк, що через місяць віддає 404, деплой без HTTPS або з відкритими ключами, Skills «для галочки», які ніхто не запускав. Сам деплой займає мало часу, покроково це є в матеріалі про Vercel деплой.

Як написати кейс Design Engineer: шаблон на 5 блоків?

Кейс до кожного артефакту має бути коротким: рев'ювер витратить на нього 1-2 хвилини, а решту часу проведе в посиланнях. Шаблон:

1. Проблема   - 2 речення: що болить і кому
2. Рішення    - 3-5 рішень і чому саме так
               (токени, стани, обмеження, від чого відмовились)
3. Посилання  - живий URL · Storybook · GitHub · PR
4. Claude vs я - що згенерував агент,
               що вирішив і перевірив я
5. Результат  - що змінилось: метрика, рев'ю, Lighthouse

Блок 4 - найважливіший у 2026 році. Не ховайте, що код писав Claude. Напишіть чесно: «Claude зверстав 6 компонентів за моїм CLAUDE.md, я визначив архітектуру токенів, переписав focus-стани під клавіатуру і відхилив два його рішення через контраст». Саме тут видно, що ви інженер рішень, а не оператор промптів.

Як я розбираю реальні репозиторії і кейси студентів, можна подивитись на YouTube-каналі UX Hero.

З чого почати, якщо зараз у портфоліо тільки Figma?

1. Оберіть один свій макет з 5-8 компонентами і готовими Figma Variables.
2. Створіть репозиторій, додайте README і CLAUDE.md до першого рядка коду.
3. Перенесіть токени в код і зберіть компоненти в Storybook з усіма станами.
4. Додайте одну фічу через PR і попросіть когось зробити рев'ю.
5. Задеплойте на свій домен, напишіть кейс за шаблоном вище і закріпіть репо в GitHub.

Усі чотири артефакти виходять з одного проєкту. Генерувати красиві екрани сьогодні вміє кожен, а довести дизайн до коду, який можна відкрити, перевірити і змерджити, - ні. Саме це і продає портфоліо Design Engineer.

Часті питання

Що має бути в портфоліо Design Engineer?

Чотири артефакти: GitHub-репозиторій з чистою структурою, файлом CLAUDE.md і читабельною історією комітів; Storybook з компонентами на ваших Figma Variables токенах; змерджений pull request з реальною фічею, що пройшла рев'ю; живий деплой на власному домені плюс власні Claude Skills. До кожного - короткий кейс з посиланням. Figma-макети теж лишаються, але як контекст до коду, а не замість нього.

Чи потрібні в портфоліо Design Engineer Dribbble і Behance?

Як основа - ні. Dribbble-шот показує, що ви вмієте намалювати екран, а гайрінг-менеджер на позицію Design Engineer перевіряє, чи вмієте ви довести його до продакшну. Візуал можна лишити як вітрину, але головне посилання в резюме має вести на живий деплой, Storybook або репозиторій.

Чи можна показувати код, який написав Claude?

Так, і приховувати це не варто. У 2026 році Design Engineer працює з AI-агентами, тому сильніше чесно написати в кейсі, що зробив Claude, а що вирішили ви: архітектуру компонентів, токени, стани, обмеження доступності. Цінність - у рішеннях і рев'ю, а не в тому, хто надрукував рядки.

Скільки проєктів потрібно для портфоліо Design Engineer?

Для старту вистачить одного проєкту, на якому зібрані всі чотири артефакти: репозиторій, Storybook, змерджений PR і живий деплой. Один наскрізний проєкт переконує більше, ніж п'ять незакінчених репозиторіїв. Далі можна додати другий, але закріплених на GitHub проєктів має бути небагато і тільки найсильніші.

Де навчитись зібрати такі артефакти?

На курсі UX Hero «Design Engineer» від Dmytro Nikolaienko кожна з 10 лекцій закінчується артефактом у вашому репозиторії: GitHub, токени з Figma у коді, Storybook, деплой на свій домен, власні Claude Skills і прод-PR у капстоні. Для тих, хто хоче проходити це з дедлайнами і рев'ю коду, є формат «Кохорта Design Engineer».

---

Портфоліо Design Engineer переконує не тим, як гарно виглядає, а тим, скільки в ньому можна відкрити і перевірити. Репозиторій, Storybook, PR і живий деплой - чотири лінки, після яких питання «а ви вмієте в код?» на співбесіді вже не виникає.