Fifty interviews, turned into four people you can question.

Six months of fieldwork with the auto drivers, riders, bus drivers and traffic police who spend their whole working day inside Bengaluru's congestion. Rather than write it up, I built four characters who answer in the first person, each one bounded by what the real people actually said.

Fifty interviews, turned into four people you can question.

Six months of fieldwork with the auto drivers, riders, bus drivers and traffic police who spend their whole working day inside Bengaluru's congestion. Rather than write it up, I built four characters who answer in the first person, each one bounded by what the real people actually said.

Fifty interviews, turned into four people you can question.

Six months of fieldwork with the auto drivers, riders, bus drivers and traffic police who spend their whole working day inside Bengaluru's congestion. Rather than write it up, I built four characters who answer in the first person, each one bounded by what the real people actually said.

TL;DR

The Problem

Fifty conversations with the people who work inside Bengaluru's traffic would normally end up as a research deck, where four working lives get compressed into a handful of bullets that someone skims once and forgets.

What did I build?

Four composite characters, each built from the interviews and each able to answer questions in the first person, so that a visitor can ask about a bad shift or a difficult junction and get an answer grounded in what people actually said.

Why it was difficult

A language model will happily invent a convincing auto driver, which means most of the work was not in getting it to talk but in deciding what each character was not allowed to know, claim or offer.

My Role

Sole designer and builder, covering the fieldwork, the synthesis, the character construction, the interface, the constraint system and the build itself.

Timeline

6 months of research
2 weeks for build, Apr '26

View Live

Context

Research that stays inside a document stays inside a document.

Most traffic stories are written for commuters who pass through congestion, while my research was with the people who work inside it all day.

Most traffic stories are written for commuters who pass through congestion, while my research was with the people who work inside it all day.

Fifty of those conversations would normally end up as a deck that someone skims once, and almost everything that made them worth having would be gone by then.

Fifty of those conversations would normally end up as a deck that someone skims once, and almost everything that made them worth having would be gone by then.

Fifty conversations

Fifty conversations

Hours of detail, contradiction, specifics

One research deck

One research deck

Themes, quotes, findings

Six bullets someone remembers

Six bullets someone remembers

Traffic is stressful for workers

The build

So I built the interviews into
four people you can talk to

So I built the interviews into four people you can talk to

Rather than writing up what fifty people told me, I turned the research into four characters who answer questions in their own voice, drawn from what the drivers, riders and officers I spoke to actually said.

You ask about a bad shift or a difficult junction, and the answer comes from inside it rather than from a summary of it.

The Research

The four who can't leave

The fieldwork was a team research project I worked on, across ten stakeholder groups. The Archive is what I did with it afterwards.

I kept the four who can't leave, and what came up again and again wasn't lost time, it was damage to a body: chronic back pain in the auto drivers, coughing fits in the officers who stand in it all day.

Ten stakeholder groups

Ten stakeholder groups

Pedestrians, cyclists, riders, passengers, drivers, officers

Four who are paid to be on the road

Four who are paid to be on the road

Auto, two-wheeler taxi, bus, traffic police

Four characters you can question

Four characters you can question

Built from what they said, bounded by what they'd know

Characters

The Character

Meet the heroes

Each character is a composite of multiple real people, designed to feel specific rather than symbolic:

Ravi · 2‑wheeler taxi

Weaves through traffic under pressure to be fast, while carrying all the risk when things go wrong.

Manjunath ·

Auto driver

Fights through jams all day, where every wrong turn or argument cuts into already thin earnings.

Krishna ·

Traffic police

Stands in the open for hours, facing the brunt of other's bad decisions on the road.

Suresh · BMTC driver

Holds a packed bus together through hours of standstill traffic and delays he can’t control.

Hover to see more

Ravi · 2‑wheeler taxi

Weaves through traffic under pressure to be fast, while carrying all the risk when things go wrong.

Manjunath · Auto driver

Fights through jams all day, where every wrong turn or argument cuts into already thin earnings.

Krishna ·

Traffic police

Stands in the open for hours, facing the brunt of other's bad decisions on the road.

Suresh · BMTC driver

Holds a packed bus together through hours of standstill traffic and delays he can’t control.

Ravi · Two‑wheeler taxi

Weaves through traffic under pressure to be fast, while carrying all the risk when things go wrong.

Manjunath · Auto driver

Fights through jams all day, where every wrong turn or argument cuts into already thin earnings.

Krishna · Traffic police

Stands in the open for hours, facing the brunt of other's bad decisions on the road.

Suresh · BMTC driver

Holds a packed bus together through hours of standstill traffic and delays he can’t control.

Build Process

I hadn't built anything like this before

I started with no experience of working with a model or writing code, and the assembly turned out to be the easy half: a Framer front end, one conversation module, a cloud function holding each character's brief, a model underneath doing the phrasing.

Framer UI
Conversation
module
Cloud function
(character + rules)
Language
model
back to
module

Build Process

I hadn't built anything like this before

I started with no experience of working with a model or writing code, and the assembly turned out to be the easy half: a Framer front end, one conversation module, a cloud function holding each character's brief, a model underneath doing the phrasing.

Framer UI
Conversation
module
Cloud function
(character + rules)
Language
model
back to
module

What I hadn't expected was that almost none of the work sat in the code. Once it ran, every remaining decision was about what the characters should refuse to do, and that came out of the interviews rather than the build.

Hover to learn more

Surface · Framer UI

This is where the questions get asked

  • Landing page, character grid, and conversation layouts reside here

  • The same layout is used for all four characters

Surface · Framer UI

This is where the
questions get asked

  • Landing page, character grid, and conversation layouts reside here.

  • The same layout is used for all four characters.

  • Landing page, character grid, and conversation layouts reside here


Single module

One component,
four people.

  • A shared module handles input, loading and responses.

  • Change behaviour or styling depending on character speaking.

Single module

One component,
four people.

  • A shared module handles input, loading and responses.

  • Change behaviour or styling depending on character speaking.

  • A shared module handles input, loading and responses.


Cloud function

Where the rules live.

  • Every question routes through a small server function

  • It attaches the character's brief and limits

  • Where research turns into system logic

Cloud function

Where the rules live.

  • Every question routes through a server function.

  • It attaches the character's brief and limits.

  • Where research turns into system logic.

  • Every question routes through a small server function



The model

Phrasing, not knowledge.

  • It receives a tightly scoped brief: who is speaking, what they know, how they talk

  • Quality comes from the brief rather than from model size

The model

Phrasing, not knowledge.

  • It receives a tightly scoped brief: who is speaking, what they know, how they talk

  • Quality comes from the brief rather than from model size

  • It receives a tightly scoped brief: who is speaking, what they know, how they talk


What I hadn't expected was that almost none of the work sat in the code. Once it ran, every remaining decision was about what the characters should refuse to do, and that came out of the interviews rather than the build.

Hover to learn more

Surface · Framer UI

This is where the
questions get asked

  • Landing page, character grid, and conversation layouts reside here.

  • The same layout is used for all four characters.

  • Landing page, character grid, and conversation layouts reside here


Single module

One component,
four people.

  • A shared module handles input, loading and responses.

  • Change behaviour or styling depending on character speaking.

  • A shared module handles input, loading and responses.


Cloud function

Where the rules live.

  • Every question routes through a server function.

  • It attaches the character's brief and limits.

  • Where research turns into system logic.

  • Every question routes through a small server function



The model

Phrasing, not knowledge.

  • It receives a tightly scoped brief: who is speaking, what they know, how they talk

  • Quality comes from the brief rather than from model size

  • It receives a tightly scoped brief: who is speaking, what they know, how they talk


Learnings

The research was the hard part,
and it always was

  • I built this with no experience of models or code, and the build took two weeks. What it needed was fifty conversations and the judgment to know which three details out of a hundred make a person recognisable, and that took far longer and doesn't get faster with better tools.

  • It isn't finished. Nobody has used it in front of me yet, and the test that matters is whether an auto driver relates himself with Manjunath.

  • That's what I'd do next: put it back in front of the people it came from.

Amrutha Anup

Product Designer

Social

Linkedin

Behance

Get in Touch

amruthaanup29@gmail.com

+91 7021990391

Bangalore, India

© 2026 Amrutha Anup

Amrutha Anup

Product Designer

Social

Linkedin

Behance

Get in Touch

amruthaanup29@gmail.com

+91 7021990391

Bangalore, India

© 2026 Amrutha Anup

Amrutha
Anup

Product
Designer

Social

Linkedin

Behance

Get in Touch

amruthaanup29@gmail.com

+91 7021990391

Bangalore, India

© 2026 Amrutha Anup