User Research mit kleinem Budget: Wie Freelancer und kleine Teams zu echten Erkenntnissen kommen

Es gibt einen Satz, den ich in fast jedem Erstgespräch höre: „Für Research haben wir kein Budget." Meistens kommt er früh, fast entschuldigend, und er meint eigentlich etwas anderes — nämlich: „Wir wissen nicht, was Research kosten würde, und wir haben Angst, dass es viel ist."

Das ist ein Missverständnis, das ich gut verstehe. Wer „User Research" hört, denkt an Labor, Panel, Eyetracking, an eine Agentur mit einer Rechnung über fünfstellige Summen. Und ja, das gibt es. Aber die Methoden, die im Alltag von Freelancern und kleinen Produktteams tatsächlich den Unterschied machen, kosten selten mehr als einen halben Arbeitstag. Sie brauchen kein Werkzeug, das du nicht schon hast, und keine Stichprobe, die du dir nicht organisieren kannst.

In diesem Artikel geht es um genau diesen Bereich: Research unter realen Bedingungen. Ohne Research-Ops, ohne Rekrutierungsdienstleister, ohne Wochen im Zeitplan. Fünf Methoden, die auch dann tragen, wenn du allein am Projekt sitzt — plus die Frage, wie du das Ganze gegenüber Kund:innen so beschreibst, dass es nicht nach Luxus klingt.

1. Warum Research im kleinen Projekt zuerst gestrichen wird

Research ist in Angeboten die verletzlichste Position. Nicht weil sie teuer wäre, sondern weil sie als Einzige kein sichtbares Ergebnis produziert. Ein Screen kann man zeigen. Ein Klickprototyp beeindruckt im Meeting. Eine Erkenntnis dagegen ist ein Satz auf einer Folie — und Sätze wirken im Vergleich zu Bildern immer billig.

Dazu kommt eine zweite Dynamik: Der Verzicht auf Research fällt nie auf. Man merkt nicht, dass eine Annahme falsch war. Man merkt nur, dass die Umsetzung länger dauert als geplant, dass es drei statt einer Feedbackrunde braucht, dass ein Modul nach dem Launch „irgendwie nicht genutzt wird". Die Kosten entstehen trotzdem, sie tauchen nur in anderen Zeilen auf.

Und drittens gibt es einen Ersatz, der überzeugend aussieht und keiner ist: die Abstimmungsrunde. In der sitzen Auftraggeber:innen, Fachbereich, vielleicht die Geschäftsführung — Menschen, die das Produkt kennen, es aber nicht so benutzen wie die Zielgruppe. Ihre Rückmeldungen sind wertvoll für Inhalt, Recht und Priorisierung. Als Nutzerurteil sind sie unbrauchbar.

Faustregel: Sobald in einer Runde der Satz „Ich als Nutzer würde ja eher …" fällt, redet gerade jemand über sich selbst, nicht über die Zielgruppe. Das ist kein Vorwurf — es ist nur ein Hinweis darauf, dass die Frage an der falschen Stelle gestellt wurde.

Der Punkt ist nicht, dass kleine Projekte Research nicht bezahlen können. Der Punkt ist, dass Research in kleinen Projekten anders aussehen muss: kürzer, enger, häufiger. Nicht eine große Studie am Anfang, sondern viele kleine Prüfungen entlang des Weges.

2. Die eine Frage, die dein Research beantworten muss

Der häufigste Fehler beim Research mit kleinem Budget ist nicht die Methode. Es ist die fehlende Frage. Wer „mal testen" will, bekommt ein Protokoll voller Beobachtungen, aus denen sich alles und nichts ableiten lässt. Wer eine Leitfrage hat, bekommt eine Entscheidung.

Eine gute Leitfrage ist so formuliert, dass eine Antwort dein Handeln verändert. Nicht „Wie finden Nutzer:innen die neue Navigation?", sondern „Finden Erzieher:innen die Dokumentation eines Kindes, ohne vorher ins Hauptmenü zurückzugehen?". Die erste Frage bringt Meinungen, die zweite bringt eine Ja/Nein-Beobachtung, an der ein Konzept hängt.

Vier Fragetypen, die im Projektalltag fast immer reichen:

• Entscheidungsfrage: Zwei Wege sind denkbar, du musst dich festlegen. Tabs oder Filterleiste? Ein langes Formular oder drei Schritte? Der Test entscheidet nicht für dich, aber er zeigt, welcher Weg Menschen weniger kostet.
• Verhaltensfrage: Du willst wissen, was Leute tatsächlich tun, nicht was sie sagen. „Zeig mir, wie du heute den Monatsbericht erstellst" schlägt jede Selbstauskunft.
• Abbruchfrage: Irgendwo verlieren sich Nutzer:innen — im Onboarding, im Checkout, im Upload. Du willst die Stelle finden, nicht die Ursache raten.
• Vokabularfrage: Nennen die Leute das Ding genauso wie dein Interface? Der Abgleich zwischen Fachsprache und Nutzersprache ist der billigste Research überhaupt und verändert oft mehr als ein Redesign.

Wenn dir zu einer geplanten Frage kein Szenario einfällt, in dem die Antwort etwas ändert, streich sie. Das ist kein Sparen, das ist Fokus.

3. Fünf Methoden, die ohne Budget funktionieren

Alle fünf lassen sich in einem halben Tag vorbereiten und durchführen. Keine braucht mehr als ein Notebook, ein Telefon und die Bereitschaft, Leute anzusprechen.

Der Kurztest mit dem, was da ist

Du zeigst fünf Personen aus dem erreichbaren Umfeld — Coworking, Nachbarbüro, Verein, Familie außerhalb der Branche — einen Prototypen und gibst ihnen eine Aufgabe. Zehn Minuten pro Person.

• Wann es passt: Für alles, was allgemeine Bedienlogik betrifft — Navigation, Beschriftungen, Reihenfolge von Schritten.
• Wann nicht: Sobald Fachwissen nötig ist. Wer nie eine Kita geleitet hat, kann dir zu einem Beobachtungsbogen nichts sagen, das über „sieht übersichtlich aus" hinausgeht.
• Die Falle: Bekannte wollen dir gefallen. Deshalb gibst du eine Aufgabe und stellst keine Fragen — und du sagst vorher, dass du nicht den Menschen prüfst, sondern den Entwurf.

Das kurze Interview mit fünf Leuten

Dreißig Minuten, Videocall, offene Fragen zum Arbeitsalltag statt zum Produkt. Ich frage in dieser Runde fast nie nach dem Entwurf, sondern nach dem Vorher: Wie läuft das heute? Wo hakt es? Was passiert, wenn etwas schiefgeht?

Das ist die Methode mit dem besten Verhältnis von Aufwand zu Ertrag. In einem Bildungsportal-Projekt kam so heraus, dass die eigentliche Belastung nicht die Dateneingabe war, sondern das Nachhalten von Fristen — eine Funktion, die im Konzept gar nicht vorkam und danach zum zentralen Element der Startseite wurde.

• Rekrutierung ohne Panel: über den Auftraggeber (Bestandskund:innen, Support, Vertrieb), über Fachgruppen und Communities, über den eigenen Newsletter. Eine kleine Aufwandsentschädigung ist fair und macht Zusagen verbindlicher.
• Aufwand: ein halber Tag für fünf Gespräche, plus zwei Stunden Auswertung.

Vorhandene Datenspuren lesen

Die günstigste Nutzerforschung ist die, die schon stattgefunden hat. Support-Tickets, E-Mails an die Info-Adresse, interne Suchanfragen im Produkt, Absprungpunkte im Funnel, Formularfelder mit auffälliger Fehlerquote. Das kostet Lesezeit und sonst nichts.

Besonders ergiebig sind die internen Suchanfragen: Sie sind eine Liste von Dingen, die Menschen erwartet und nicht gefunden haben — formuliert in ihren Worten. Wer wissen will, welche Begriffe ins Menü gehören, findet dort mehr als in jedem Workshop. Wie du aus solchen Spuren konkrete Verbesserungen ableitest, habe ich am Beispiel von Suchfunktionen für Web und App genauer beschrieben; die quantitative Seite — Absprünge, Trichter, Testaufbau — steht im Artikel zur Conversion-Optimierung durch UX Design.

Card Sorting auf Papier

Begriffe auf Karten schreiben, Teilnehmende gruppieren lassen, zuhören. Analog mit Karteikarten oder digital in einem geteilten Board. Für Struktur- und Benennungsfragen ist das die direkteste Methode, die ich kenne, und sie funktioniert schon mit sechs bis acht Personen erkennbar gut.

Was dabei zählt, ist weniger das Ergebnisdiagramm als die Begründung beim Sortieren. Der Satz „Das gehört für mich zusammen, weil ich das immer am selben Tag mache" sagt dir mehr über die richtige Informationsarchitektur und Navigation als jede Klickpfad-Statistik.

Der Fünf-Sekunden-Test

Du zeigst einen Screen fünf Sekunden lang und fragst danach: Worum geht es hier? Was kann man tun? An wen richtet sich das? Drei Fragen, fünf Personen, zwanzig Minuten insgesamt.

Wichtig ist die Reihenfolge: erst zeigen, dann wegnehmen, dann fragen. Wer den Screen während der Antwort noch sieht, liest ab statt sich zu erinnern — und genau die Erinnerung ist das Interessante, denn sie zeigt, was im ersten Blick hängen bleibt. Notier die Antworten wörtlich; die Begriffe, die Leute spontan benutzen, sind gleichzeitig ein Vorschlag für deine Überschriften.

Der Test prüft nicht Bedienbarkeit, sondern Verständlichkeit auf den ersten Blick — und er ist gnadenlos ehrlich bei Startseiten, Landingpages und ersten Onboarding-Schritten. Wenn nach fünf Sekunden niemand sagen kann, worum es geht, hilft auch der beste zweite Screen nicht mehr.

Beispiel: Bei einer Festival-Website hielten drei von fünf Testpersonen den Ticket-Bereich für ein Newsletter-Formular — allein wegen der Anordnung von Eingabefeld und Knopf. Die Korrektur war eine Viertelstunde Arbeit. Ohne den Test wäre sie erst nach dem Vorverkaufsstart aufgefallen.

4. Wie viele Nutzer:innen du wirklich brauchst

Die bekannte Zahl lautet fünf. Sie stammt aus Nielsens Beobachtung, dass fünf Testpersonen den größten Teil der Usability-Probleme einer Oberfläche aufdecken. Die Zahl stimmt ungefähr — aber sie wird regelmäßig falsch gelesen.

• Fünf gilt pro Nutzergruppe, nicht pro Projekt. Wenn dein Produkt Erzieher:innen, Leitungen und Eltern bedient, sind das drei Gruppen mit drei sehr verschiedenen Aufgaben. Fünf gemischte Personen ergeben dann kein Bild, sondern einen Mittelwert aus drei Bildern.
• Fünf gilt für qualitative Fragen. „Wo scheitern Leute?" beantwortest du mit fünf. „Wie viel Prozent scheitern?" nicht. Für Anteile brauchst du entweder deutlich größere Stichproben oder — meist sinnvoller — Verhaltensdaten aus dem laufenden Produkt.
• Zwei Runden mit je drei Personen schlagen eine Runde mit sechs. Nach der ersten Runde änderst du etwas, in der zweiten prüfst du die Änderung. Research, das nicht in eine Korrektur mündet, ist nur teure Bestätigung.
• Die letzte Person zählt am wenigsten. Wenn Person vier und fünf nichts Neues zeigen, hör auf und fang an zu ändern. Sättigung ist ein legitimes Abbruchkriterium.

Für kleine Teams heißt das praktisch: lieber alle drei Wochen dreißig Minuten testen als einmal im Projekt einen ganzen Tag. Die Frequenz schlägt die Stichprobengröße, weil sie Fehler früh erwischt — solange sie noch billig zu korrigieren sind.

5. Die Sitzung selbst: Aufgaben statt Meinungsfragen

Der Unterschied zwischen brauchbarem und wertlosem Research entscheidet sich in den ersten drei Minuten einer Sitzung — und zwar daran, ob du nach Verhalten oder nach Meinung fragst.

• Statt „Findest du die Navigation verständlich?" → „Du willst herausfinden, wie viel Urlaub dir noch zusteht. Zeig mir, wie du vorgehst."
• Statt „Würdest du hier klicken?" → „Was erwartest du hinter diesem Bereich?" (gefragt, bevor geklickt wird)
• Statt „Ist das zu viel Text?" → „Lies laut mit, wenn du magst — sag mir, wo du hängen bleibst."
• Statt „Hat dir das gefallen?" → „Was war der unangenehmste Moment gerade?"

Dazu drei Verhaltensregeln, die sich nicht verhandeln lassen:

Nicht helfen. Der Reflex, in der Stille einzuspringen, ist der teuerste Fehler in jeder Testsitzung. Jede Sekunde Ratlosigkeit ist ein Datenpunkt. Zähl innerlich bis zehn, bevor du etwas sagst.

Nicht erklären. Wenn du erklären musst, wie etwas gemeint war, hast du das Ergebnis schon. Notier es und mach weiter.

Nicht verteidigen. Auch nicht mit dem Satz „Das ist nur ein Prototyp". Sag stattdessen zu Beginn einmal klar, dass der Entwurf geprüft wird und nicht die Person — und dann halt dich raus.

Zur Aufzeichnung: Ein Mitschnitt hilft enorm bei der Auswertung, braucht aber eine ausdrückliche Einwilligung, und die gehört vor die Aufnahme, nicht in eine Fußnote. Für kleine Projekte reicht meist die kleinere Lösung: kein Video, sondern Notizen einer zweiten Person, die still mitschreibt. Das spart die halbe Datenschutzdiskussion und kostet dich wenig an Erkenntnis.

Tipp: Plane nach jeder Sitzung fünfzehn Minuten Puffer ein. Nicht als Pause, sondern zum Aufschreiben. Was du direkt nach dem Gespräch notierst, ist um ein Vielfaches genauer als das, was du abends aus der Erinnerung rekonstruierst.

6. Auswertung ohne Research-Ops

Hier scheitern die meisten kleinen Research-Vorhaben — nicht an der Erhebung, sondern daran, dass die Notizen liegen bleiben. Ein Verfahren, das mit einem halben Tag auskommt:

• Eine Beobachtung pro Zeile. Kein Fließtext. „P3 sucht Speichern-Knopf unten rechts, findet ihn oben" ist eine Zeile. Was du in Sätzen aufschreibst, kannst du später nicht sortieren.
• Beobachtung und Deutung trennen. „P2 zögert vor dem Absenden" ist eine Beobachtung. „P2 hat Angst, etwas kaputtzumachen" ist eine Deutung. Beides ist nützlich, aber nur die erste Sorte hältst du bei Widerspruch.
• Gruppieren, nicht zählen. Zusammenschieben, was denselben Ursprung hat. Drei verschiedene Symptome mit einer Ursache sind ein Befund, nicht drei.
• Nach Schwere ordnen, nicht nach Häufigkeit. Ein Problem, das eine Person am Abschluss hindert, wiegt schwerer als eine Irritation, die vier Personen erwähnen und trotzdem überwinden.

Das Ergebnis ist eine Seite. Oben die Leitfrage und die Antwort darauf in zwei Sätzen, darunter drei bis fünf Befunde, jeder mit einer belegenden Beobachtung und einer vorgeschlagenen Änderung. Diese eine Seite ist das, was im Projekt zirkuliert — nicht das Protokoll, nicht die Aufzeichnung.

Bei der Aufbereitung helfen KI-Werkzeuge inzwischen ernsthaft: Transkripte zusammenfassen, Notizen vorclustern, Formulierungsmuster über mehrere Gespräche hinweg finden. Was sie nicht ersetzen, ist die Beobachtung selbst — ein Modell kann dir nicht sagen, wie lange jemand gezögert hat. Wo die Grenze zwischen sinnvoller Unterstützung und Selbstbetrug verläuft, habe ich im Artikel über KI-Tools im UX-Prozess ausführlicher aufgeschrieben.

7. Vier Fallen, die auch erfahrenen Leuten passieren

Günstiges Research ist nicht schlechteres Research — aber es ist anfälliger, weil niemand danebensteht und gegensteuert. Die vier Fehler, die ich am häufigsten sehe (und selbst gemacht habe):

• Die Bestätigungsrunde. Du hast dich in eine Lösung verliebt und testest sie, um sie bestätigt zu bekommen. Erkennbar daran, dass du dich über Widerspruch ärgerst. Gegenmittel: Schreib vor der Sitzung auf, welches Ergebnis dich zwingen würde, den Entwurf zu verwerfen. Wenn dir keines einfällt, testest du nicht, du führst vor.
• Die falsche Stichprobe aus Bequemlichkeit. Kolleg:innen, andere Designer:innen, digital versierte Bekannte. Diese Gruppe scheitert an nichts und findet alles logisch — weil sie Muster kennt, die deine Zielgruppe nie gesehen hat. Ein einziges Gespräch mit einer echten Nutzerin schlägt fünf mit Leuten aus der Branche.
• Der Test der eigenen Erklärung. Du führst durch den Prototypen, kommentierst mit, hilfst über die Lücken. Am Ende hast du geprüft, ob deine Erläuterung verständlich ist — nicht das Interface. Im echten Betrieb steht niemand daneben.
• Der Befund ohne Adressat. Die Erkenntnis ist gut, landet aber in einem Dokument, das niemand öffnet. Ein Befund braucht eine Zeile im Backlog, eine Person und ein Datum, sonst ist er ein Gedanke.

Dazu ein Grenzfall, der keine Falle ist, aber oft für eine gehalten wird: Nicht jede Frage gehört ins Nutzergespräch. Ob ein Feature rechtlich zulässig ist, ob es sich rechnet, ob es zur Produktstrategie passt — das entscheidet niemand, der das Produkt benutzt. Research beantwortet Fragen nach Verhalten und Verständnis. Alles andere ist Arbeit für dich, deinen Auftraggeber oder die Fachabteilung.

8. Research verkaufen, ohne es Research zu nennen

Bleibt die unangenehme Seite: Wie bringst du das in ein Angebot, ohne dass die Position als Erstes gestrichen wird?

Drei Dinge, die bei mir funktionieren:

• Nicht als eigene Phase ausweisen. Research als separater Posten lädt zum Streichen ein. Als Bestandteil der Konzeptphase — „Konzept inkl. zwei Testrunden" — steht es nicht zur Disposition, weil das Konzept selbst nicht zur Disposition steht.
• In Korrekturkosten rechnen, nicht in Tagen. Ein halber Tag Testen gegen zwei Wochen Umbau nach dem Launch: Diese Gegenüberstellung versteht jede Geschäftsführung sofort. Sie ist auch ehrlich, denn genau so verteilen sich die Kosten.
• Den Zeitpunkt mitverkaufen. Der Wert von Research sinkt mit jedem Tag Entwicklung. Vor dem ersten Screen ist eine Erkenntnis eine Richtungsentscheidung; nach dem Launch ist sie ein Change Request.

Und ein vierter Punkt, der weniger mit Verkaufen zu tun hat als mit Haltung: Fang bei dir selbst an. Die ersten drei Testrunden in meinen eigenen Projekten habe ich niemandem in Rechnung gestellt. Sie haben sich trotzdem gelohnt — weil ich seitdem in Angeboten nicht mehr behaupten muss, dass Testen hilft, sondern erzählen kann, was es im letzten Projekt verhindert hat. Das ist ein anderes Gespräch.

Beispiel: In einem Kita-Software-Projekt hat eine einzige Testrunde mit vier Fachkräften ergeben, dass ein geplantes Filter-Modal überflüssig war — die gesuchte Einschränkung war in 90 Prozent der Fälle dieselbe und gehörte als Voreinstellung ins Interface, nicht in einen Dialog. Eingespart: die Entwicklung eines Moduls, das niemand vermisst hat.

Fazit

User Research mit kleinem Budget ist keine abgespeckte Version der richtigen Sache. Es ist eine eigene Arbeitsweise: kürzer, häufiger, näher an der Entscheidung, die gerade ansteht.

Was ich mitgeben würde:

• Eine Leitfrage pro Runde. Wenn die Antwort nichts ändert, ist es die falsche Frage.
• Fünf Personen pro Nutzergruppe reichen für qualitative Fragen — und zwei kleine Runden schlagen eine große.
• Aufgaben stellen statt Meinungen abfragen. Menschen erzählen dir zuverlässig, was sie glauben zu tun, und zeigen dir zuverlässig, was sie tun.
• Die Auswertung braucht einen festen Platz im Kalender, sonst bleibt sie liegen — und dann war die Erhebung umsonst.
• Research früh ist Gestaltung, Research spät ist Nachbesserung. Der gleiche Aufwand, ein völlig anderer Ertrag.

Wer als Freelancer oder in einem kleinen Team arbeitet, hat dabei sogar einen Vorteil: Zwischen Erkenntnis und Umsetzung liegt keine Abstimmungskette. Du kannst am Dienstag testen und am Mittwoch ändern. Diese Geschwindigkeit ist mehr wert als jedes Labor.