Tagesplan 16.06.2026 — Von den Bedarfen der Communities her · 10–15 Uhr

Die Idee: Gleiche Technik, anderer Einstieg. Plan A erschließt den Tag entlang der Technik-Kette (Schlüsselpaar → Event-Typen → Anlegen → Lizenzierung). Dieser Plan B erschließt dieselben Arbeitsphasen von den Bedarfen der Communitymitglieder her — jede Phase beginnt mit einer Leitfrage, die ein Mitglied wirklich hat. Die Technik ist Mittel, nicht Rahmen.

| Plan A (Technik-Kette) | Plan B (Bedarfs-Leitfrage) | Symbol | |---|---|---| | Schlüsselpaar & Profil | „Wer bin ich hier?" — Identität | ○ | | Event-Typen erkunden + Community | „Wo sind meine Leute?" — Zugehörigkeit | ⬡ | | Material & Kalender-Event anlegen | „Was bringe ich mit?" — Beitragen | □ ◁ | | Lizenzierung & Blossom-Upload | „Wie zeige ich mich?" — Sichtbarkeit, rechtssicher veröffentlichen | ■ | | — | „Aus welchen Bausteinen wird unser Ort?" — Kreativphase (neu) | ○ ⬡ □ ■ ◁ |

Der Symbol-Faden: Plan B benutzt die Formensprache des UX-Designs (○ Person · ⬡ Community · □ Material · ◁ Event) von Beginn an als Arbeitszeichen — plus die Füll-Achse: hohl = Hinweis auf woanders Gefundenes, gefüllt = eigener, lizenzierter Inhalt. Das UX-Design führt die Sprache nachmittags nicht neu ein, sondern erntet sie.

Zu den Leitfragen: „Wohin gehöre ich?" aus dem ersten Aufschlag ist zu „Wo sind meine Leute?" geschärft — die Frage zielt auf Menschen, nicht auf Struktur. Die Fragen sind bewusst in der Ich-Form: Es sind die Fragen, die auch die Persona aus den Community-Interviews gestellt hätte („Was darf ich? Wo werde ich gesehen?") — der Bedarfs-Blick holt die Persona-Substanz zurück, ohne die Dramaturgie wiederzubeleben.

Warum das zur Priorität passt: Befund 1 der Community-Interviews lautet: Ein Communitymitglied findet Material, aber es traut sich nicht, es weiterzugeben — es weiß nicht, ob es darf. Die Rechtssicherheits-Priorität ist ein Community-Bedarf. „Wie zeige ich mich, ohne etwas falsch zu machen?" bleibt deshalb auch in Plan B der Kernblock.

Gesammelt wird in Plan B nicht ein Befund-Sammler (System-Sicht), sondern ein Bedarfs-Sammler (Mitglieder-Sicht): Jede Phase endet mit Bedarfs-Karten — „Ein Communitymitglied braucht an dieser Stelle …". Dabei gilt: Ein Bedarf ist ein Handlungswunsch, kein Systemschritt. „Braucht Registrierung" ist kein Bedarf — „will beim zweiten Besuch wiedererkannt werden" ist einer. Die Technik ist die Antwort, nicht die Frage. Die Synthese ist in die Kreativ- und Mockup-Blöcke eingewoben; die Board-Führung überführt laufend ins Anforderungs-Board.

Chronologischer Überblick · 10:00–15:00

| Zeit | Block | Dauer | |---|---|---| | 10:00–10:15 | Ankommen: Der Ort aus Sicht seiner Mitglieder | 15 min | | 10:15–10:50 | Phase 1 — „Wer bin ich hier?" · Identität | 35 min | | 10:50–11:25 | Phase 2 — „Wo sind meine Leute?" · Zugehörigkeit | 35 min | | 11:25–12:05 | Phase 3 — „Was bringe ich mit?" · Beitragen | 40 min | | 12:05–13:00 | Phase 4 — „Wie zeige ich mich?" · Sichtbarkeit, rechtssicher (Kernblock) | 55 min | | 13:00–13:30 | 🍽 Mittagspause | 30 min | | 13:30–14:05 | Kreativphase — „Aus welchen Bausteinen wird unser Ort?" | 35 min | | 14:05–14:30 | Mockups im Dialog (UX-Design) — Team-Entwürfe treffen UX-Stand | 25 min | | 14:30–14:50 | Projektmanagement (Projektleitung) — Strukturvorgaben & Rollenklärungen | 20 min | | 14:50–15:00 | Check-out & Übergabe in den Gesamtprozess | 10 min |

Die Phasen im Detail

10:00–10:15 · Ankommen: Der Ort aus Sicht seiner Mitglieder (15 min)

• Leitfragen-Bogen zeigen: Wer bin ich hier? → Wo sind meine Leute? → Was bringe ich mit? → Wie zeige ich mich? → Aus welchen Bausteinen wird unser Ort?
• Symbol-Legende (1 min): vier Formen, eine Füllregel — ○ Person · ⬡ Community · □ Material · ◁ Termin; hohl = Hinweis, gefüllt (■ ◀) = eigener, lizenzierter Inhalt. Die Spaltenköpfe des Bogens tragen die Symbole; sie begleiten den Tag als Arbeitszeichen (keine Mockup-Vorwegnahme — die kommen vom UX-Design um 14:05).
• Spielregel: Jede Phase endet mit Bedarfs-Karten („Ein Communitymitglied braucht hier …") in den Bedarfs-Sammler. Bedarf = Handlungswunsch, kein Systemschritt.

Leitung: Moderation · Board: Board-Führung

10:15–10:50 · Phase 1 — ○ „Wer bin ich hier?" · Identität (35 min)

Niemand wacht auf mit dem Bedarf nach einem Schlüsselpaar. Der Bedarf heißt: wiedererkannt werden, etwas unter eigenem Namen geben können, die eigene Identität keiner Plattform schulden. Das Schlüsselpaar ist die Antwort, nicht die Frage — und die Antwort gehört dem Mitglied selbst:

1. Schlüsselpaar erzeugen — als Erfahrung von Selbstbesitz: dieser Schlüssel ist meine Identität, keine Plattform vergibt sie mir (nsec sicher ablegen, die Begleitung für Schlüssel-Sicherheit unterstützt).
2. Profil anlegen — als Selbstbild: Wie will ich gesehen werden? Name, Bild, was ich unterrichte/tue.
3. Gegenseitig finden und folgen.
4. npub auf das Board — in die Kreis-Sammlung im Leitfragen-Bogen (jede Person ein hohler Kreis): Name rein, und sobald das Profil angelegt ist, den eigenen Kreis füllen — aus ○ wird ●. Die Füll-Mechanik des Tages beginnt hier: gefüllt = wirklich da, von mir signiert.

Bedarfs-Frage: Wofür braucht ein Mitglied hier überhaupt ein „Ich" — was will es tun, das ohne nicht geht? Wie spät und wie niedrigschwellig darf das „Ich" kommen (erst stöbern, Identität erst beim ersten Geben)? Und was darf es dabei auf keinen Fall erleben (Schlüssel-Angst, englische Fehlermeldungen)? Ergebnis: Jede:r hat eine eigene Identität + Bedarfs-Karten Identität. Begleitung: Schlüssel-Sicherheit, Tech-Begleitung

10:50–11:25 · Phase 2 — ⬡ „Wo sind meine Leute?" · Zugehörigkeit (35 min)

Identität allein trägt nicht — Zugehörigkeit bindet:

1. Communities erkunden und der Test-Community beitreten.
2. Die Begegnungsformen des Orts kennenlernen (= Event-Typen aus Mitglieder-Sicht): ○ Profile von anderen (Kind 0), □ Material von anderen (Kind 30142), ◁ Termine (NIP-52), ⬡ Community-Beiträge (NIP-72), Reaktionen/Kommentare. Die Community selbst steht als hohles Sechseck am Board — sind alle beigetreten, wird es gefüllt.
3. In Paaren: An welcher Begegnungsform merke ich, dass hier Leben ist?

Bedarfs-Frage: Woran erkennt ein neues Mitglied in den ersten 5 Minuten, dass hier seine Leute sind — und was muss Beitreten mehr bieten als Mitlesen, damit es sich lohnt? Ergebnis: Alle sind in der Community + Bedarfs-Karten Zugehörigkeit. Begleitung: Tech-Begleitung

11:25–12:05 · Phase 3 — □ ◁ „Was bringe ich mit?" · Beitragen (40 min)

Mitglieder sind keine Konsument:innen — sie bringen etwas mit:

1. Jede:r gibt einen Materialhinweis (Kind 30142, echte AMB-Metadaten) und einen Termin (Kind 31923) in die Community.
2. Dabei explizit machen: Was wir hier geben, sind Hinweise — □ und ◁, hohle Formen. Das Metadaten-Event referenziert eine woanders gefundene Quelle, es repräsentiert sie nicht vollinhaltlich. Die Hülle zeigt auf den Fundort.
3. Dabei beobachten: Wie leicht ist Geben? Wo fühlt es sich nach Formular an statt nach Schenken?

Bedarfs-Frage: Was braucht ein Mitglied, damit aus „ich habe etwas" tatsächlich „ich gebe etwas" wird — und was kommt zurück (Resonanz, Dank, Sichtbarkeit), damit es ein zweites Mal gibt? Ergebnis: Pro Person 1 Material + 1 Termin + Bedarfs-Karten Beitragen. Begleitung: Tech-Begleitung (Werkzeuge), Board-Führung (Bedarfs-Sammler)

12:05–13:00 · Phase 4 — ■ „Wie zeige ich mich?" · Sichtbarkeit, rechtssicher (55 min · Kernblock)

Der wichtigste Bedarf — direkt aus den Community-Interviews: Ich würde teilen, aber ich weiß nicht, ob ich darf.

Die Pointe des Blocks im Symbol: Aus □ wird ■ — der Unterschied ist die Lizenz. Bisher haben wir auf Gefundenes gezeigt (hohle Formen). Jetzt wird eigener Inhalt wirklich veröffentlicht — vollinhaltlich im Netzwerk (Longform, Kanban, Wiki oder lizenzierter Blossom-Upload), signiert von mir.

1. Sortierübung (10 min): eigenes Foto / CC-BY-Bild / „im Netz gefunden" — welches darf ■ werden (auf den Blossom-Server)? Warum (nicht)? Was bleibt □ (nur Hinweis)?
2. Lizenz fürs eigene Bild/Medium klären, Attribution nach TASL (Titel · Autor:in · Source · Lizenz).
3. Upload auf Blossom, Verknüpfung mit dem eigenen Material — das □ aus Phase 3 wird zum ■.
4. Gegenprobe in Paaren: Erkennt die andere Person, was sie mit meinem Material tun darf?

Bedarfs-Frage: Der Bedarf heißt gesehen werden, die Angst heißt etwas falsch machen: Wie nimmt der Ort die Angst, ohne das Zeigen zu verhindern — und was muss die Architektur dafür erzwingen? Ergebnis: Pro Person 1 korrekt lizenziertes, attribuiertes Medium auf Blossom + Bedarfs-Karten Sichtbarkeit/Recht. Begleitung: Rechtssicherheit/Lizenzen, Tech-Begleitung (Upload)

13:00–13:30 · 🍽 Mittagspause (30 min)

Die Board-Führung sortiert die Bedarfs-Karten vor. Tech-Begleitung und Board-Führung legen das Baustein-Kit für die Kreativphase aufs Board.

13:30–14:05 · Kreativphase — „Aus welchen Bausteinen wird unser Ort?" (35 min)

Der Tagestitel wird wörtlich genommen: Aus Bausteinen wird ein Ort — baut ihn. In der Tradition des ersten Konzeptionstags (25.11.2024, Lego in Frankfurt) — diesmal remote:

• Baustein-Kit auf Miro: vorbereitete visuelle Bausteine in der Formensprache des UX-Designs — Personen-Kreise ○, Community-Sechsecke ⬡, Material-Quadrate in beiden Füllzuständen (□ Hinweis / ■ eigener Inhalt), Event-Dreiecke ◁/◀, dazu Funktions-Kacheln (Feed, Kalender, Suche, Chat, „Erstellen"-Button, Lizenz-Anzeige …).
• Sandkasten (direkt unter dem Kit): vier Entwurfs-Zonen im Browser-Fenster-Look — hier entstehen die imaginierten Community-Hub-Startseiten.
• Auftrag (in Paaren, 20 min): Steckt aus den Bausteinen eure Startseite im Sandkasten zusammen — die Startseite, die die Bedarfe des Vormittags beantwortet. Duplizieren, anordnen, beschriften; Lücken-Bausteine selbst zeichnen ist erlaubt.
• Alternativ/ergänzend: Wer mag, visualisiert per KI und stellt das Ergebnis daneben.
• Pitches (15 min): 2 Minuten pro Entwurf — Welcher Bedarf hat euer Layout bestimmt?

Ergebnis: 3–5 Startseiten-Entwürfe aus Mitglieder-Sicht, in derselben Formensprache wie die UX-Mockups. Leitung: Moderation · Kit & Board: Board-Führung/Tech-Begleitung

14:05–14:30 · Mockups im Dialog (25 min · UX-Design)

Das UX-Design zeigt die aktuellen Mockups (Stand 09.06.) nach den Team-Entwürfen — dadurch wird es ein Dialog statt einer Präsentation:

• Walkthrough: Startseite als eigene App, Formensprache, Selektions-Navigation, eingeloggte Seite als Journey. Das Team kennt die Formen da schon als Tageszeichen — das UX-Design erntet, statt einzuführen.
• Abgleich: Wo treffen sich Team-Entwürfe und Mockups? Wo weichen sie ab — und welcher Bedarf steckt hinter der Abweichung? Insbesondere: Wo ist der Lizenz-Schritt im Publish-Flow sichtbar — wo zeigt der Flow den Übergang □ → ■?
• Füll-Achse zur Entscheidung: Trägt die Unterscheidung hohl/gefüllt als Erweiterung der Formensprache? Dazu die gesammelten Brüche aus der Symbol-Konvention (Füllung vs. Aktiv-Zustand, rechteckige Bestands-Karten, Terminologie „Aus dem Web teilen" = □).
• Gelegenheit, die offene Menü-Reihenfolge (Communities/Personen/Materialien/Events) mit dem ganzen Team zu entscheiden.

Ergebnis: Abgeglichene Design-Richtung + Resonanz-Karten; die Board-Führung überführt Bedarfe und Entwurfsmotive ins Anforderungs-Board. Leitung: UX-Design · Moderation: Moderation

14:30–14:50 · Projektmanagement: Strukturvorgaben & Rollenklärungen (20 min · Projektleitung)

Wie in Plan A: Die Projektleitung (Direktor) gibt dem gesteuerten Entwicklungsprozess den Rahmen — Kadenz, Entscheidungswege, Berichtslinien; Rollenklärungen mit Mandat. Anker ist das von der Board-Führung gefüllte Anforderungs-Board.

Ergebnis: Verabredete Strukturen, geklärte Rollen, Mandat für die erste Priorisierungsrunde.

14:50–15:00 · Check-out & Übergabe (10 min)

Eine Runde, ein Satz: „Welcher Bedarf geht mir nach?" — danach übernimmt der Entwicklungsprozess.

Rollen am Tag (wie Plan A, plus Kit)

| Rolle | Aufgabe | |---|---| | Moderation | Moderation, Leitfragen-Bogen, Zeit | | Board-Führung | Board, Bedarfs-Sammler, Überführung ins Anforderungs-Board | | Tech-Begleitung | Technische Begleitung + Baustein-Kit | | Schlüssel- & Rechtssicherheit | Schlüssel-Sicherheit & Rechtssicherheit/Lizenzen | | UX-Design | Formensprache fürs Kit, Mockups im Dialog (14:05) | | Projektleitung (Direktor) | Strukturvorgaben & Rollenklärungen (14:30) |

Board-Logistik: Wo landet was?

Fünf Stationen auf dem Miro-Board, alle in der linken Board-Hälfte (von oben nach unten: Tagesplan B → Leitfragen-Bogen → Symbol-Kit → Sandkasten):

1. Leitfragen-Bogen / Bedarfs-Sammler (Frame direkt unter Tagesplan B) — die Arbeitsfläche des Tages. Fünf Spalten, eine pro Leitfrage; die Spaltenköpfe tragen die Symbole (○ · ⬡ · □ ◁ · ■ · alle), und oben in jeder Spalte sitzen hohle Form-Shapes als Füll-Mechanik: Phase geschafft → Form füllen (Spalte 1: ein Kreis pro Person für die npub-Sammlung; Spalte 2: das Community-Sechseck; Spalte 3: □ und ◁; Spalte 4: der Übergang □ → ■). Regel: Jede Phase endet mit 2 Minuten Bedarfs-Karten im Format „Ein Communitymitglied braucht hier …" — jede:r schreibt selbst, die Karten wandern in die Spalte der laufenden Phase. Spalte 4 (Kernblock) trägt ein Beispiel-Sticky als Formatvorlage. Die Moderation nutzt die Spaltenköpfe als roten Faden: Am Ende jeder Phase kurz auf die Spalte zeigen und 2–3 Karten vorlesen.
2. Symbol-Kit (Frame unter dem Leitfragen-Bogen) — Legende + duplizierbare Bausteine in der Formensprache des UX-Designs mit beiden Füllzuständen, dazu Funktions-Kacheln und Joker.
3. Sandkasten (Frame unter dem Kit) — vier Entwurfs-Zonen im Browser-Fenster-Look für die imaginierten Community-Hub-Startseiten der Kreativphase.
4. Destillat (Board-Führung): In der Mittagspause und parallel zum Mockup-Block werden die Karten jeder Spalte auf 1–3 Kern-Bedarfe verdichtet (Dubletten zusammenlegen, konkretisieren).
5. Anforderungs-Board (Gesamtprozess-Spalte ganz links, unter Prinzipien und Prozess-Loop) — das dauerhafte Prozess-Artefakt. Die Board-Führung überführt die Destillate: Bedarfe mit Rechts-/Standard-Bezug in die Spalte „Extern/Markt" (hat automatisch Priorität), alles andere in „Intern/Backlog". Eine Karte = ein Bedarf/eine Anforderung. Der Projektmanagement-Block (14:30) und die erste Priorisierungsrunde arbeiten dann direkt auf diesem Board weiter — von dort wandern Karten durch die Spalten Als Nächstes → In Arbeit → Review/Gate → Veröffentlicht.

Für Plan A gilt dieselbe Logistik, nur heißen die Spaltenköpfe dann nach den vier Hands-Ons (Befund- statt Bedarfs-Karten).

Zusätzliche Voraussetzungen gegenüber Plan A

• [ ] Baustein-Kit + Symbol-Legende auf dem Board (Feinschliff Board-Führung/Tech-Begleitung mit dem UX-Design): duplizierbare Bausteine in der Formensprache des UX-Designs mit beiden Füllzuständen + Funktions-Kacheln + leere „Joker"-Bausteine
• [ ] Kurz-Briefing UX-Design — zwei Punkte: (1) Mockups kommen nach den Team-Entwürfen (Dialog-Format statt Präsentation); (2) die Füll-Achse (□ Hinweis / ■ eigener Inhalt) ist ein Team-Vorschlag als Erweiterung der Formensprache — Entscheidung liegt beim UX-Design
• [ ] Optional: KI-Zugang für die Kreativphase testen
• [ ] Alle übrigen Punkte aus Plan A gelten unverändert (Test-Community, Relay/Blossom, Lizenz-Spickzettel, Beispielbilder, Einladung)

Entscheidungshilfe A oder B

• Plan A, wenn der Tag vor allem Systemreife prüfen soll: Die Technik-Kette macht Lücken im Werkzeug sichtbar (Befund-Logik).
• Plan B, wenn der Tag vor allem Richtung geben soll: Die Bedarfs-Logik produziert priorisierbare Mitglieder-Bedarfe und eigene Startseiten-Entwürfe als Material fürs UX-Design und den Entwicklungsprozess.
• Beide Pläne füllen dasselbe Anforderungs-Board und enden bei den Strukturvorgaben der Projektleitung — der Gesamtprozess bleibt identisch.