DorukYetgin

UX / UI DesignerM.Sc. HCI · University of Trento

Engineer turned UX designer. I find where systems break down for people, then design them back up.

Open to new opportunities

Selected work

Game & UI design2026 Papers, Peasant! A medieval paperwork game where tension comes from bureaucracy, not combat. View case study → Language leaves a location. NLP · Machine learning2026 Language leaves a location Predicting where a German social media post was written, from its text alone. View case study → Partenze · Departures07:47OraTrenoDestinazioneBin.Rit.07:48RV 2232Bolzano/Bozen107:52R 10703Verona Porta Nuova3→5+15'08:01FR 9461Roma Termini208:16RE 1854Brennero/Brenner1+5' UX research · Facilitation2025 Social robots in train stations Three research phases across three Italian stations found the real pain was real-time information. View case study → P&BBefore · hover menuAfter · top nav Usability testing · UI2023 Pull&Bear redesign Usability tests with 8 shoppers, three problems found, fixes proposed as hi-fi wireframes. View case study →

? In progress · Cognitive ergonomics2026 Can people detect AI-made content? A study on how well people tell AI-generated content from human work. Case study coming soon. Coming soon

Systems, then people

Industrial engineering taught me to read a system: queues, flows, handoffs, failure points. HCI taught me to stand inside it and ask how it feels. I design for both: the details users feel and the structure they never see.

I'm Doruk, a UX/UI designer from Antalya, now based in Trento. I'm in the second year of my HCI master's at the University of Trento.

Before design I studied Industrial Engineering in Istanbul and worked in recruitment, UX research, hospitality and supply chain. Each job showed me the same thing from a different side: systems work well on paper and break down where people meet them.

FigmaFigma MakeUnityClaudeUsability testingInterviewsFocus groupsJourney mappingThematic coding

2025 — nowM.Sc. Human-Computer InteractionUniversity of TrentoTrento, IT

2024Supply Chain InternSuwenIstanbul, TR

2024UX Researcher InternKeytorc / UX ServicesIstanbul, TR

2023Recruitment InternPegasus AirlinesIstanbul, TR

2020 — 24B.Sc. Industrial EngineeringBahçeşehir UniversityIstanbul, TR

Papers, Peasant!

A small simulation game about paperwork. Inspired by Papers, Please, but with a very different atmosphere: tension through bureaucracy, not combat.

Project typeSimulation / puzzle game

RoleGame & UI Designer

Year2026

ToolsUnity 6, Claude, itch.io assets

Concept

One gate, many peasants

You are the gatekeeper of Castle Ede, in the Kingdom of Emmeloord, in the year 1042. Every visitor hands you a Letter of Passage. Your job is to read carefully and decide correctly.

Every stamp has a cost you can see and a consequence you can't.

Ring bell→Visitor approaches→Check document→Decision

Design pillars

Four rules we designed by

Procedural complicityThe game never tells the player outright that a decision was morally wrong.

Escalation, not difficulty spikesNew rules arrive one at a time, explained by the head guard, so the player is never overwhelmed.

Visible cost, invisible costArrest, lost wages, an unpaid bill, hunger, a sick child.

Ambiguity over expositionWhat the player learns about the king's state of mind comes through contradictory, secondhand testimony.

Serve the king, or help the resistance.

Narrative

A kingdom seen from a gate

The story moves day by day on a kingdom-wide scale, but the player only sees it through the eyes of a guard.

It feeds the core loop by changing the rulebook. When the king turns paranoid, citizens from the Princedom of Ede are no longer allowed in, and the player has to choose where their loyalty lies.

Screens

UI design and gameplay

Annotated game screen: castle background, coins counter, NPC, wanted posters, rulebook and the three decision buttons — Every element on the gate screen and what it does

Behance ↗

Credits

Text in. Coordinates out.

Language leaves a location

Predicting where German Jodel posts were written from their text alone, comparing a classic SVM with a fine-tuned BERT model.

Project typeLanguage-based interaction

RoleSolo project

Year2026

Core methodsSVM, fine-tuned BERT, Regression

The task

Where was this written?

Jodel is a location-based social app, so every post carries a place. Dialect, local slang and place names leave traces in the text.

The task was to predict a post's geographic origin from its words alone, framed as a regression problem rather than picking from a list of cities.

The data

A real social corpus

The official SMG2021 dataset: German-language Jodel conversations from Germany and Austria, with geographic labels. Anonymous, everyday language rather than edited text.

318,487Training posts

29,122Development

31,515Test (gold)

Approach

Two models, one question

01 · Baseline

SVM

Learning from patterns in words. Character and word TF-IDF features with a linear SVR, trained with SGD.

Character n-grams: 2–4
Word n-grams: 1–2
Feature space: 50,000
Output: Lat + lon

02 · Transformer

BERT

Understanding words in context. A pretrained German BERT fine-tuned with a regression head to predict coordinates.

Backbone: bert-base-german
Training: 5 epochs
Sequence length: 64 tokens
Output: Lat + lon

Why it's here

Designing with models

Designers increasingly work alongside models. This project taught me what language models can and cannot infer about people, and that shapes how I design AI-powered interactions.

Results

BERT wins on every metric

Reduction in median error56.5%

Half of BERT's predictions land within 161 km of the real location.

SVM367.33 km

BERT159.63 km

Median distance error · lower is better

Metric	SVM	BERT
Mean distance	464.96 km	179.40 km
Median distance	367.33 km	159.63 km
Accuracy @ 50 km	2.0%	13.2%
Accuracy @ 100 km	7.3%	28.8%
Accuracy @ 161 km	16.7%	50.5%

Evaluated on 31,515 test posts. Distance: lower is better. Accuracy: higher is better.

Place is not only in the metadata. It is also in the language.

The full study

The paper covers the method, the evaluation and the limits of the comparison, such as the memory constraints that shaped the SVM baseline.

See full project on Behance ↗

Partenze · Departures07:47OraTrenoDestinazioneBin.Rit.07:48RV 2232Bolzano/Bozen107:52R 10703Verona Porta Nuova3→5+15'08:01FR 9461Roma Termini208:16RE 1854Brennero/Brenner1+5'

Social robots in train stations

Three research phases on how travellers find information in Italian rail stations, and whether a robot could help.

Project typeQualitative UX Research

RoleUX Researcher & Facilitator

Year2025–2026

Core methodsEthnography, Interviews, Focus group

Research question

Where it starts

Would a social robot in train stations ease the experience of people who are travelling?

We studied travellers in three stations of different sizes to find where ticketing and information break down, and where a robot could step in.

RoveretoSmall

TrentoMid-sized

VeronaLarge

Process

Three phases, one narrowing question

Phase 1

Observe

Ethnographic sessions across four time bands, from early morning to night.

30 observations

Phase 2

Interview

Semi-structured interviews, transcribed and coded.

12 interviews · ~60 min

Phase 3

Discuss

A moderated focus group across seven guideline themes.

6 participants · 90 min

Phase 1 · Field

People don't trust the machines

Little trust in ticket machines

Constant re-checking: board, phone, board again

Asking strangers before trying a machine

Thoroughness is dropped when rushed

Regulars have workarounds, newcomers fail

Phase 2 · Pivot

Tickets were fine. Information wasn't.

Buying tickets was frustrating in places, but participants wanted small fixes, not a new interface. The real pain was real-time information: platform changes, late announcements, contradictory boards and unclear signage.

So we narrowed it: would a robot ease travel by helping people gather real-time information?

Phase 3 · Findings

A robot is only as good as its sources

Sources contradict each other, so travellers fully trust none of them

When the system fails, people fall back on each other

A robot is welcome only if its information is verified

Fix the system first. Then let the robot join it.

Implications

The order matters

A robot placed in a broken information system inherits the system's failures. We recommended this sequence:

Synchronise information across all channels

Make signage and updates clear and consistent

Fix how platform changes and delays are announced

Only then add a robot as a verified information interface

Full project on Behance ↗

Let's talk.

I'm open to new opportunities. If my work caught your eye, I'd love to hear from you.

LinkedIn ↗ Behance ↗