Designing a Memorial App for Holocaust Stolpersteine

CLIENT

Stichting 18 September

PARTNERS

Fontys ICT · Netwerk Oorlogsbronnen

DOMAIN

Memorial · Mobile (iOS + Android)

PERIOD

2024

TEAM

6-person product team (1 designer)

TYPE

Pro bono · Social impact

RECOGNITION

Joe Cattini Local Hero Award 2024

STATUS

Live in production since June 2024

TL;DR

Mobile app for memorial network

A mobile app for the Holocaust Stolpersteine memorial network in the Netherlands and Belgium — small brass plaques in front of the last homes of Nazi-persecution victims. The client had spent a decade digitising 15,500 victim stories but had no public way to surface them. As the only designer on a six-person product team, I owned discovery, UX, UI, brand identity and product decisions end-to-end.

This case is about the design and product decisions I made along the way: how to surface a 15,500-entry dataset on mobile, how to handle UGC contributions safely, how to apply GDPR to a memorial database, and how to make product calls without a PM.

Stolpersteine app overview — brass-toned interface across key screens

RESULTS

What it became.

DOWNLOADS

12,000+

App Store + Google Play · no marketing budget

DAILY ACTIVE USERS

~100

sustained 2 years post-launch

USER CONTRIBUTIONS

500+

stones added via UGC flow in first months

RECOGNITION

Joe Cattini Local Hero Award 2024

Eindhoven · 2024

An annual recognition by the city of Eindhoven for contributions to peace, freedom and tolerance. Previous recipients have been community initiatives and individuals — the Stolpersteine app was the first digital product to receive it.

Joe Cattini Local Hero Award presentation

Two years on, the app continues to operate in production — daily users stable, contributions still arriving, dataset still growing. Discussions underway with partner organisations in Germany about consolidating fragmented local Stolpersteine apps onto this platform.

01 — CONTEXT

15,500 names. No way to find them.

A Stolperstein — “stumbling stone” — is a small brass plaque set into the pavement in front of the last freely-chosen home of a victim of Nazi persecution. The Netherlands and Belgium hold thousands of them. The client, Stichting 18 September, had spent a decade digitising 15,500 victim stories — but the data lived behind an internal interface, invisible to visitors standing on the actual stones.

The brief was open: surface the dataset. The constraints were sharp: pro bono, no analytics budget, no PM. Four audiences with incompatible needs — passers-by who don’t know what the stones are, descendants searching for a specific name, educators bringing groups, researchers cross-referencing archives.

Stolpersteine in the pavement and the four audiences the app serves

CONSTRAINTS

Pro bono delivery. No analytics infrastructure. No A/B testing budget. No PM — product decisions ran alongside design. Rigor had to come from explicit early decisions about scope, ethics, and what the product would not do.

02 — MY ROLE

Sole designer, full product surface.

LED

Discovery (interviews with the client and users — visitors, descendants, educators) · persona modelling · information architecture for a 15,500-entry dataset · full UX and UI for every flow — map, victim profile, search, contribution, onboarding, localisation · brand identity and app icon · product decisions on scope and prioritisation.

WITH THE TEAM

Five developers directly (no PM, so I ran product calls alongside design) · the client lead as de facto product owner · Netwerk Oorlogsbronnen for upstream data structure · an external advisor on GDPR/AVG.

03 — KEY DECISIONS

Seven calls that shaped what the app respects.

01

KEY DECISION

Map-first, not list-first

15,500 entries. A list view was the obvious choice — and the wrong one for an app used at physical sites.

Home opens on a map centred on the user, stones as understated brass pins: tap for a peek with name and dates, then the full profile. List view stays as a secondary path for users who already know the name.

Map answers the real question at a site — “whose home was this.” List-first framed the app as an archive; map-first frames it as a layer over the city. Map also solved scale: 15,500 names overwhelm any list but become navigable when filtered by location.

02

KEY DECISION

Victim profile: narrative-first hierarchy

Profiles contain dates, deportation routes, family — the kind of data that, presented as a grid, flattens a person into a record.

Narrative-first: the name is the largest element on the screen, portrait below, the story in human-readable form, with dates and routes structured underneath, not above.

The dataset is full of dates because that’s what survives in archives — but the person isn’t a date. This was the decision the client reacted to most strongly: it matched what they had been trying to do for years.

03

KEY DECISION

GDPR / AVG: privacy for the dead and the living

AVG generally doesn’t protect data about the deceased — but it does protect living descendants. Profiles that name surviving relatives crossed a real legal line.

Two-tier visibility: profiles separate historical context from references to people who may still be alive, and contribution flows ask submitters to flag whether named individuals are living. Historical context is public; references to potentially-living people are omitted by default and surfaced only with confirmed consent.

Retrofitting privacy after launch would have meant pulling stones from the live app. Building the layer up front kept legal exposure off the client and protected descendants who had no say in the data being public.

Two-tier visibility model separating historical context from living people

04

DECISION

UGC contribution: open the door, guard the threshold

The database had to stay alive — new stones, corrections, family photos — but the contribution surface is unusually sensitive. Every submission requires a source, contact email, and explicit consent. Nothing publishes automatically; client reviews and merges. Mandatory source-attribution is intentional friction — filters casual edits while staying welcoming to descendants with real material.

UGC contribution flow with source, consent and review gate

05

DECISION

Onboarding for the uninitiated

Audience splits sharply — descendants and educators know what Stolpersteine are; accidental visitors don’t. First launch shows a single sentence, a visual of the brass plaque, and two actions — “show me the nearest stones” or “search by name.” Skippable; re-accessible from settings.

First-launch onboarding explaining what a Stolperstein is

06

DECISION

Multi-language: localise the interface, not the history

App serves Dutch, French, English, German, and Hebrew speakers — but historical content (1940s place names, camp names, victim names) doesn’t translate cleanly. Interface chrome translated fully. Historical proper nouns stay in their original form, with a short annotation where context is needed — never replacing it.

Localisation pattern keeping historical proper nouns intact

07

DECISION

Working with a non-product-fluent client

Client team are historians and archivists. Standard design-review formats (wireframes, click-throughs) didn’t get useful responses. Reframed reviews as “this is what a granddaughter sees when she searches for her grandmother — does this feel right.” Decisions tied back to specific user moments. The client lead became a fast, decisive partner on direction, hands-off on UI choices. Faster decisions and a design that held its integrity.

04 — ARTIFACTS

Created artifacts

01

Figma flows

Map, victim profile, search, contribution (UGC), onboarding, localisation, settings

02

Interactive prototype

High-fidelity prototype covering primary user journeys

03

Personas + journey maps

Four personas: passer-by, descendant, researcher, contributor

04

Brand identity

App icon, type system, colour system anchored on the brass of the stones

05

Live app

Stolpersteine App — App Store and Google Play

06

Award + press

Joe Cattini Local Hero Award, Studio 040, Eindhovens Dagblad, Fontys

05 — KEY INSIGHT

Design ethics aren’t a constraint on the work — they are the work.

Every typography choice, every information hierarchy, every UGC validation rule was an ethical decision at the level of “does this specific screen treat this specific person with dignity.” The skill is recognising what each product owes the person on the other end of the screen — and letting that shape the design from the first wireframe, not bolting it on at the end.

WHAT CARRIES FORWARD INTO B2B WORK

The skills built on this case map directly onto enterprise problems.

IA for 15,500 entries

Data-heavy interfaces with thousands of records, deep filtering, multi-entity navigation

UGC moderation

Trust & safety, admin and moderation surfaces in platforms where one user’s input affects others’ data

GDPR-aware design

Privacy-by-design in enterprise products handling personal data

Two-audience onboarding

Multi-persona onboarding in technical platforms with mixed user expertise — carried directly into the Pluxbox onboarding work

Working with domain experts

Working with broadcast operators, compliance officers, legal teams — people who know the problem deeply but don’t speak the language of product

06 — REFLECTION

What I’d do differently.

01

Set up analytics from day one

We tracked downloads and rough daily-active numbers, but didn’t instrument the contribution funnel, search patterns, or onboarding drop-off. With proper analytics, the iteration loop after launch would have been sharper.

02

Document the privacy model formally

We made the right calls on AVG with strong external guidance, but those decisions live mostly in my head and in design files. For European expansion (Germany has different rules), that thinking needs to be a written policy that survives a team handover.