CASE STUDY · WEB / UX

Eine Vereinswebsite von null für den TTC Dahn

Wie aus „kein eigener Webauftritt" eine Seite wurde, die der Vorstand selbst pflegen kann.

Screenshot der TTC Dahn Website Homepage

Auftraggeber

TTC Dahn e.V.

Rolle

Solo · Design + Development

Bereich

UI/UX · Web Design · WordPress

Tools

Figma WordPress PHP HTML/CSS

Status · Jahr

In Entwicklung · 2026

01 — Überblick

Ein Verein mit acht Mannschaften, gut besuchten Spielen und bis jetzt keiner eigenen Website

Der TTC Dahn ist ein aktiver Tischtennisverein aus dem Pfälzerwald mit acht Mannschaften und vielen Mitgliedern. Die erste Mannschaft spielt kommende Saison Oberliga, die Heimspiele sind gut besucht. Wer den Verein im Web suchte, landete auf einer generischen Verbandsseite. Kein Branding, keine Kontaktinfo, keine Darstellung des Vereins.

Als aktiver Spieler habe ich das Problem selbst erlebt und die Initiative ergriffen: Domain gesichert, Hosting aufgesetzt, Website von Grund auf neu entwickelt. Design und Development in einem Projekt, ehrenamtlich. Die Aufgabe war nicht einfach eine Seite bauen. Die Aufgabe war, einer Community ein Zuhause im Netz zu geben, das sie selbst pflegen kann.

02 — Discovery

Welche Frage stellt jemand, der die Seite öffnet?

Weil ich den Verein von innen kenne, konnte ich die Discovery-Phase straffen: keine formalen Interviews, sondern Gespräche im Training, beim Punktspiel, im Vorstand. Das Ziel war zu verstehen, mit welcher konkreten Frage Menschen die Seite ansteuern, und welche Frage nicht auftauchen würde.

Jobs-to-be-done

Stammspieler „Wann spiele ich als nächstes? Heim oder auswärts?"
Neuling / Elternteil „Kann ich (oder mein Kind) da mitmachen? Wann ist Training?"
Sponsor / Lokales Unternehmen „Wer ist der Verein, was bekomme ich für ein Sponsoring?"
Vorstand „Kann ich das selbst pflegen, ohne Webagentur anzurufen?"

Was ich wusste

  • Mobile First. Trainingszeiten und Spielplan werden zu >80 % unterwegs abgerufen.
  • Vereinsfarben. Rot, Schwarz, Weiß, historisch fest verankert, kein Diskussionspunkt.
  • Keine Bildwelt. Es gibt keine professionellen Team-Shots, keine Hallenfotos.
  • Pflege durch Ehrenamt. Wer das übernimmt, hat keine Web-Erfahrung.

Was ich klären musste

  • Hierarchie der Inhalte. Was muss ins Hero, was kann tiefer scrollen?
  • Sponsor-Logik. Logos oder Namen, gleichberechtigt oder gestaffelt?
  • Spielplan-Pflege. Manuell eintragen oder click-tt synchronisieren?
  • Detailtiefe pro Team. Eigene Unterseiten oder eine Übersichtsseite?
03.1 — Design: Hero

Das erste, was Besucher sehen. Und warum kein Foto draufkommt.

Der Hero hat zwei Jobs gleichzeitig: dem Stammspieler in 3 Sekunden sagen, wann er spielt, und dem Neuling zeigen, dass er hier richtig ist. Beide Ziele auf einmal zu lösen, ohne das Design zu überladen, war die zentrale Spannung dieser Section.

Ich habe drei Ansätze wireframed. Alle drei scheitern an irgendeiner Form an der Realität des Vereins, aber auf unterschiedliche Weise. Das hat die Entscheidung am Ende sehr einfach gemacht.

Alt. 1 — verworfen
Alt. 2 — Zwischenstand
Final — umgesetzt
✓ funktioniert  ·  ✗ Problem  ·  • Beobachtung
Alt. 1Foto-Hero
[ großes Hallenfoto ]
[ CTA ]
Wir haben keine guten Hallenfotos. Stockbilder = sofort generisch.
Stammspieler scrollen an allem vorbei, was sie wollen.
Atmosphäre geht, aber nicht als Hero-Anker.
Alt. 2Live-Dashboard
Sehr informativ, fühlt sich „live" an.
Keine Persönlichkeit, liest sich wie eine Sportschau-API.
3 Kacheln konkurrieren um Aufmerksamkeit. Keine Hierarchie.
FinalTypo-Statement + 2 Pills
Headline trägt die Identität, kein Foto nötig.
Genau 2 Info-Pills: klare Hierarchie, keine Wahl.
Schwarz above the fold separiert sich klar vom Rest der Seite.
Entscheidung Das Typo-Statement löst das Hauptproblem (keine Fotos) und setzt gleichzeitig das Vereinsbranding. Die zwei Info-Pills (nächstes Spiel und Trainingszeiten) bedienen beide Haupt-User-Typen ohne Kompromiss. Alt. 2 wäre stark für eine App, nicht für eine Vereinsseite.
03.2 — Design: Trainingszeiten

4 Trainingstage, unterschiedliche Gruppen. Auf einen Blick scannen statt suchen.

Die Trainingszeiten-Section hat einen klar definierten Job: jemand öffnet die Seite, will wissen wann seine Gruppe trainiert, und ist in 10 Sekunden wieder weg. An vier Abenden wird trainiert, an manchen davon nur die Jugend. Jedes Layout, das dazu zwingt, erst zu suchen statt direkt zu scannen, macht genau das falsch.

Das klassische Wochen-Raster sieht gut aus im Desktop-Mockup, bricht aber auf dem Smartphone komplett zusammen. Mobile ist hier kein Edge Case, sondern der primäre Use-Case.

Alt. 1Wochen-Raster
Zeigt Verteilung der Trainingsabende auf einen Blick.
Auf Mobile katastrophal, 7 Spalten gehen nicht.
„Wann hat 1. Damen?" = suchen, nicht scannen.
FinalTagesliste, vertikal
Mo
Di
Mi
Do
Fr
Sa
Mo bis Sa als primärer Anker, jeder weiß welcher Tag heute ist.
Mobile: einfach untereinander, kein Layout-Drama.
Freitag hat 2 Slots und zeigt das sauber ohne Spalten zu sprengen.
Entscheidung Der Wochentag ist der mentale Anker des Users, nicht das Datum. Die vertikale Tagesliste spielt genau damit. Auf Mobile läuft sie ohne Layout-Kompromisse, und das 7-Spalten-Raster hätte dort nie funktioniert.
03.3 — Design: Spielplan

10 bis 30 Begegnungen, 8 Mannschaften. Filter statt Kalender.

Der Spielplan ist die zweithäufigst aufgerufene Section. Die Frage ist immer dieselbe: „Wann spielt meine Mannschaft, Heim oder auswärts?" Der Monatskalender ist die naheliegende Antwort, aber gleichzeitig die falsche.

Das Problem: mehrere Spiele am selben Tag machen jede Kalender-Zelle unleserlich. Und auf Mobile kollabiert die 7-Spalten-Ansicht, genau wie bei den Trainingszeiten.

Alt. 1Monatskalender
Zeigt die Verteilung, manche Wochen sind voll.
Mehrere Spiele pro Tag = Zelle wird unleserlich.
Mobile = ungenießbar.
FinalChronologische Liste + Filter
[Alle]
[1.H]
[2.H]
[Dam]
[Jug]
[H]
[A]
[H]
Datum links als Anker, dann Team + Heim/Auswärts-Pille.
Filter-Pills, eigenes Team in 1 Klick.
Skaliert: 5 oder 50 Zeilen, egal.
Entscheidung Listen schlagen Grids, wenn Daten variabel sind. Die chronologische Liste mit Team-Filter macht den häufigsten Job lösbar: „Wann spielt meine Mannschaft?" in einem Klick. Der Kalender wäre nur mit fixem Datenvolumen stabil.
03.4 — Design: News & Ergebnisse

Spielergebnis und Vereins-News. Trennen oder mischen?

Diese Section hatte das interessanteste Inhaltsproblem: zwei grundlegend verschiedene Inhaltstypen. Spielergebnisse sind faktisch, kurz, zeitgebunden. Vereins-News sind länger, redaktionell, haben eine andere Leszeit. Die Frage war, ob die Trennung dem User hilft oder ihn auf zwei Sections verteilt, die er getrennt pflegen muss.

Alt. 1Zwei Streams getrennt
Klare Trennung, keine Verwirrung.
Zwei Sections = längere Seite ohne echten Mehrwert.
Vereinsleben „verliert" gegen sportliche Ergebnisse oben.
Alt. 2Vertikale Timeline
Typenneutral, alles rein chronologisch.
Visuell monoton, der Score als Highlight geht in der Liste verloren.
Zu „social-feed-y" für einen Verein.
FinalMixed Grid, Score = dunkel
[Alle]
[Verein]
[1.H]
9:5
5:5
6:4
Schwarz = Ergebnis, Weiß = News, ohne Beschriftung sofort lesbar.
Filter decken beide Achsen ab: Team und Inhaltstyp.
3×2 = stabile, kompakte Section ohne langen Scroll.
Entscheidung Visuelle Codierung (Farbe) ersetzt Beschriftung. Schwarze Kachel = Ergebnis, weiße = News. Kein Section-Header nötig, kein User-Training. Die Timeline war konzeptuell solide, verliert aber den Score als eigentliches Highlight.
03.5 — Design: Mannschaften

8 Teams. Übersicht ohne Unterseiten.

8 Mannschaften, jede mit Liga, Kapitän, Bilanz und nächsten Spielen. Die erste Frage war nicht, wie man diese Infos darstellt, sondern ob es für jedes Team eine eigene Unterseite braucht. Die Antwort war nein, der Pflegeaufwand hätte den Mehrwert bei weitem überstiegen.

Damit war die Aufgabe: alle relevanten Informationen pro Team auf eine Karte packen, ohne dass es aussieht wie eine Bundesliga-Tabelle.

Alt. 1Daten-Tabelle
Vergleichbar: Bilanz Team A vs. B in einer Zeile.
Liest sich wie eine Bundesliga-Tabelle, zu korporativ.
Mobile bricht katastrophal, 4 Spalten werden zu 4 Zeilen mal 8 Zeilen.
FinalTeam-Karten, alle ausgeklappt
Alle 8 Teams sichtbar, gleiche Höhe = scannbar.
Bilanz und nächste Spiele direkt in der Karte, keine Unterseite nötig.
Eine Sektion, ein Look. Keine Klicktiefe.
Entscheidung Keine Unterseiten pro Team. Eine Karte pro Team mit den wichtigsten Infos direkt drin, das hält den Pflegeaufwand niedrig und zwingt zur Fokussierung auf das Wesentliche. Die Tabelle hätte nur Daten gezeigt, keine Identität.
03.6 — Design: Sponsoren

Hauptsponsor, 2x Premium, 5x Partner. Hierarchie ohne Farb-Chaos.

Sponsor-Sections sind bei Vereinsseiten fast immer dasselbe: ein Logo-Grid, alle gleich groß, alle gleich wichtig. Das Problem: Hauptsponsor und lokale Pizzeria sehen identisch aus, was vertraglich und optisch ein Problem ist.

Die Herausforderung war, Sponsoring-Pakete visuell zu staffeln, ohne auf bunte Logos angewiesen zu sein, die es noch nicht gibt.

Alt. 1Gleichberechtigtes Logo-Grid
[ Logo ]
[ Logo ]
[ Logo ]
[ Logo ]
[ Logo ]
[ Logo ]
[ Logo ]
[ Logo ]
Klassisch, kennt jeder von Vereinsseiten.
Hauptsponsor = gleiche Größe wie Pizzeria. Vertraglich ein Problem.
Rote, gelbe, grüne Logos = visueller Lärm ohne eigene Kontrolle.
Alt. 2Reine Textliste, gestaffelt
Klare Hierarchie ohne Logo-Stress.
Sponsoren wollen ihr Logo, das ist vertraglich oft fixiert.
Vielleicht als Mischform?
FinalHierarchisches Raster
Größe = Vertragswert. Hauptsponsor breit & dunkel = unverwechselbar.
Stufung 1 / 3 / 4 macht Akquise-Pakete sichtbar.
Logos folgen später, Layout funktioniert auch nur mit Namen.
Entscheidung Hierarchie durch Größe, nicht durch Farbe. Das hierarchische Raster macht Sponsoring-Pakete sofort lesbar, für potenzielle Sponsoren und für den Vorstand, der neue Verträge verkaufen will. Es funktioniert auch ohne ein einziges Logo.
03.7 — Design: Verein-Teaser

Das Ende der Seite. Storytelling und Conversion in einer Section.

Die letzte Section vor dem Footer hat drei Jobs auf einmal: Übergang zur Vereinsseite bauen, Kontaktinfos bereitstellen und die Mitglieds-Conversion triggern. Die Frage war, ob das in einer Section funktioniert oder ob drei separate Sections nötig sind, die den Seiten-Tail lang und träge machen.

Alt. 1Langer „Über uns"-Block
[ CTA ]
Niemand liest 8 Zeilen Vereinsgeschichte auf der Startseite.
CTA ohne Kontaktinfos drumherum wirkt hohl.
Alt. 23 separate Sections
[ Mitglied werden ]
Alles drin, klar getrennt.
3 Section-Header hintereinander, der Seiten-Tail wird zäh.
Mitglieds-CTA verschwindet unten in der Seite.
FinalSplit: Teaser + Kontakt-Karte
[ Jetzt Mitglied werden → ]
Eine Section, zwei Jobs: Storytelling links, Conversion rechts.
Kontakt-Karte als solider Ankerpunkt vor Footer.
CTA prominent, aber nicht aggressiv. Passt gut zum Vereins-Ton.
Entscheidung Split-Layout löst drei Jobs in einer Section: Storytelling, Kontakt und Conversion existieren nebeneinander, nicht hintereinander. Der Seiten-Tail bleibt kompakt, und der Mitglieds-CTA hat einen Kontext, in dem er Sinn ergibt.
04 — Finale Lösung

Eine Seite, die Stammspieler in 5 Sekunden, Neue in 30 abholt

Vereinsfarben (Rot, Schwarz, Weiß), klare Typo-Hierarchie statt Bildwelt, und Inhalte in der Reihenfolge der häufigsten Fragen: nächstes Spiel, Trainingszeiten, Spielplan, dann Tieferes. Auf WordPress umgesetzt, damit der Vorstand Inhalte selbst pflegen kann, ohne PHP, ohne Theme-Editor.

Das Design entstand direkt aus den Entscheidungen im Wireframe-Prozess. Keine Section ohne einen konkreten Job-to-be-done dahinter.

Vollansicht der TTC Dahn Homepage
05 — Impact

Was die Seite für den Verein verändert

Die Seite ist seit kurzem live. Harte Conversion-Metriken folgen, aber was sich sofort geändert hat:

0 → 1 vereinseigene Domain und Webauftritt, vorher gab es nur die Verbandsseite.
140+ Mitglieder mit zentraler Anlaufstelle für Trainingszeiten und Spielplan.
Mobile-first Layout auf Smartphone-Nutzung optimiert, das ist der primäre Use-Case.
Self-service Vorstand pflegt News und Termine selbst, ohne externen Dienstleister.

Geplante Metriken: organischer Traffic über „TTC Dahn"-Suchen, Kontaktanfragen, Sponsoring-Leads. Sobald Daten vorliegen, folgt hier ein Update.

06 — Learnings

Was ich aus dem Projekt mitnehme

Drei Muster haben sich durch alle sieben Design-Entscheidungen gezogen, und drei Sachen mussten unterwegs sterben.

Was ich gelernt habe

  • Listen schlagen Grids. Trainingszeiten und Spielplan funktionieren chronologisch besser als kalendarisch, weil der mentale Anker der User der Tag ist und nicht das Datum.
  • Visuelle Codes ersetzen Beschriftung. Schwarze Kachel = Ergebnis, weiße = News. Kein Section-Header nötig.
  • Hierarchie durch Größe, nicht Farbe. Hauptsponsor wird breit, nicht bunt. Funktioniert auch ohne Logos.

Was ich verworfen habe

  • Foto-Hero. Keine Hallenfotos, keine Stockbilder. Typo trägt die Identität.
  • Detailseiten pro Team. Pflegeaufwand deutlich größer als der Mehrwert für den User.
  • Trennung Ergebnisse / News. Macht die Seite länger ohne die User-Frage besser zu beantworten.

Offene Fragen

  • Logo-Größen pro Sponsoring-Stufe, das muss noch mit dem Vorstand abgestimmt werden.
  • Spielplan: manuell pflegen oder mit click-tt synchronisieren?
  • News-Pflege: wer schreibt, wie häufig, mit welchem Workflow?