Produktnotizen zu Tools, Tests und Ausliefern
Die App hat hundert Features. Fünf davon zählen.
TL;DR: Teams fügen Optionen schneller hinzu, als sie welche entfernen, und liefern aus, ohne die Haustür zu testen. Die Lösung ist unspektakulär. Zeichne die User-Journey, bevor du den Screen zeichnest. Reduziere hundert Features auf die fünf, die die Nutzung tragen. Beschreibe die Tools so klar, dass ein Modell die Oberfläche daraus bauen kann. Teste mit dem kleinsten verfügbaren Modell und teste danach jeden Morgen von Hand, bis Automatisierung sich das Recht verdient, dich zu ersetzen.
Dieser Beitrag ist auch verfügbar in English , Español und Italiano .
Zeichne die Journey, bevor du den Screen zeichnest
Produktarbeit beginnt meistens mit einem Screen. Jemand öffnet eine Design-Datei, zieht Komponenten hinein, zeichnet eine Karte, fügt einen Toggle hinzu, fügt drei Buttons hinzu. Das Ergebnis sieht poliert aus und hilft niemandem, eine Aufgabe zu beenden.
Die Reihenfolge ist das Problem. Was zuerst gebraucht wird, ist ein Flowchart für die User-Journey. Was kommt zuerst? Was kommt danach? Was kommt als drittes? Was hängt wovon ab? Welche Features werden am häufigsten genutzt? Welche Features sind am wichtigsten?
Sobald diese Zeichnung sauber ist, kann die App darum herum entworfen werden. Und die Tools dahinter können ebenfalls darum herum entworfen werden. Eine Zeichnung, zwei Ergebnisse: die Oberfläche und die API.
Hundert Features, fünf die zählen
Ein Produkt kann hundert Features haben, oder hundert Dinge, die man einstellen kann, und wahrscheinlich werden nur fünf davon 99.9 Prozent der Zeit genutzt.
Diese fünf müssen vorne stehen. Sie müssen jedes einzelne Mal funktionieren. Alles andere wandert in den Hintergrund, wo es erreichbar bleibt, ohne um Aufmerksamkeit zu konkurrieren.
Das ist kein Argument gegen Features. Es ist ein Argument über die Platzierung. Eine Fähigkeit, die niemand auf dem ersten Screen findet, ist eine Fähigkeit, die niemand nutzt.
Reduziere das Verwirrungsbudget
Dieselbe Lektion zeigt sich zweimal, einmal im Tool-Design und einmal im Interface-Design. Gib einem Agent zu viele Tools und zu viele Fähigkeiten, und er wird verwirrt. Er zögert, wählt das Falsche, erfindet Argumente oder läuft zurück zum Anfang.
Ein Mensch vor einem Screen voller Optionen verhält sich genauso. Mehr Buttons und mehr Einstellungen bringen keine Macht. Sie bringen Chaos.
Die Antwort ist nicht bessere Dokumentation. Sie ist weniger Dinge. Reduzieren, reduzieren, reduzieren, und die ganze Oberfläche auf die Aufgabe fokussieren.
Tools, Fähigkeiten, Besonderheiten
Die richtige Form für einen Tool-Server ist keine flache Liste. Es gibt ein Tool, das Tool hat Fähigkeiten, und die Fähigkeiten haben Fähigkeiten. Es fächert sich nach hinten auf, wie ein Baum.
Auf der ersten Ebene gibt es nur die Tools. Auf der zweiten Ebene gibt es die Fähigkeiten. Auf der dritten Ebene gibt es die Besonderheiten dieser Fähigkeiten.
Diese Struktur ist keine Dekoration. So lernt ein Leser, Mensch oder Modell, das Produkt ohne ein Gespräch kennen. Eine flache Liste mit vierzig Endpunkten sagt niemandem, wo er anfangen soll.
Eine klare Beschreibung enthält die Oberfläche schon
Ein MCP-Server ist eine API mit Beschreibungen, wie diese API funktioniert. Wenn die Beschreibung eindeutig ist, kennt der Leser die User-Journey daraus.
Das öffnet eine Tür. Wenn ein Modell auf der einen Seite das Design-System hat und auf der anderen Seite das Tool, kann es den Screen dazwischen erzeugen. Der Übersetzer in der Mitte ist ein Sprachmodell.
Das entfernt eine ganze Klasse von Meetings. Wenn die Beschreibung klar ist, bleibt nichts zu diskutieren. Entweder lässt sich der Flow daraus bauen oder nicht.
Der Beweis ist Geschwindigkeit, nicht Geschmack
Design-Debatten enden meistens in Meinungen. Ob Option A über Option B steht, ist keine Frage, die jemand durch Argumentieren klären kann.
Es gibt eine messbare Version. Wie schnell kommt ein Agent von A nach B durch das Produkt? Wie lange muss er nachdenken? Wo wird er verwirrt?
Das macht Interface-Qualität zu einer Zahl. Es legt außerdem die Realität offen: ein Agent, der einen laufenden MCP-Server liest, wird klar sagen, dass er das nicht versteht und dass das nicht gut gelöst ist.
Teste mit dem dümmsten Modell, das du findest
Ein Frontier-Modell repariert schlechte Benennung, indem es aus dem Kontext rät. Es füllt das fehlende Argument, wählt das wahrscheinliche Tool und kommt trotzdem an. Das macht es zu einem schlechten Richter darüber, ob eine Oberfläche klar ist.
Kleine Modelle mit wenig Denkaufwand und wenig Kontext reparieren nichts. Wenn die Benennung leicht daneben liegt, scheitern sie. Wenn der Flow unnötig verzweigt, verlieren sie sich.
Also wird das kleine Modell zum Instrument. Wenn das dümmste Modell, das du findest, durchkommt, ist die Oberfläche wirklich klar. Wenn nicht, ist die Beschreibung das Problem, nicht das Modell.
Vereinfachen heißt entfernen
Das Ziel ist, alles zu vereinfachen, zu minimieren und Elemente zu entfernen. Nicht Elemente hinzuzufügen. Weniger Optionen, weniger Features, weniger Funktionalität auf jedem Screen.
Das schließt einen beliebten Zug aus. Von Grund auf neu zu bauen ist nicht automatisch Fortschritt. Ein Rewrite, der am selben Ort landet, hat ein Quartal gekostet und nichts geändert.
Der Wunsch, den es zu schützen gilt, ist die Reduktion auf das Notwendige. Alles andere ist Beschäftigung.
Eine Aufgabe, ein Screen, überall
Ein Swap von einer Währung in eine andere sollte nicht zwei verschiedene Screens haben. Er sollte überall, wo er auftaucht, 100 Prozent gleich aussehen.
Gleich in der App, gleich in einem Payment-Link, gleich wenn jemand Geld auf eine Wallet legt. Der Payment-Link ist für Menschen außerhalb des Produkts, und das ändert nichts. Geld auf die Wallet legen und Geld per E-Mail anfordern sind dieselbe Aufgabe.
Jeder anders aussehende Screen für dieselbe Aufgabe ist eine weitere Sache, die der Nutzer lernen muss. Konsistenz ist keine Stilfrage. Sie ist eine Kostenentscheidung.
Browser-Agents lesen denselben Screen
Es gibt zwei Arten von Agent. Der eine ruft eine API auf, die für ihn gebaut wurde. Der andere öffnet einen Browser und schaut sich an, was ein Mensch sehen würde.
Die zweite Art wächst, und sie braucht keine spezielle Oberfläche. Sie braucht die normale Oberfläche, die sich sofort selbst erklärt.
Das ist der eigentliche Test eines Layouts. Wenn ein Browser-Agent auf einem Handy oder einem Desktop nicht herausfinden kann, wofür der Screen da ist, rät ein Mensch auf demselben Screen auch.
Teste von Hand, bis Automatisierung es sich verdient
Automatisierte Tests prüfen nur, was jemand zuvor als Prüfung aufgeschrieben hat. Solange eine Suite die wichtigen Journeys nicht wirklich abdeckt, ist eine grüne Pipeline kein Beweis, dass die Haustür aufgeht.
Also ist die Regel manuell. Wähle die zehn Journeys, die zählen, und jeder im Team läuft sie morgens auf einem echten Gerät durch, vor der E-Mail und vor dem ersten Pull Request. Mach das so lange, bis etwas Automatisches es ersetzt.
Das ist der uncoolste Punkt der Liste und der, der am meisten findet. Ein Login-Screen, den niemand passieren kann, ist kein Randfall. Er ist das Produkt.
Wenn niemand im Team das Produkt öffnet
Ein kaputter Login ist ein Bug. Ein kaputter Login, der Tage überlebt, ist eine Antwort auf eine andere Frage.
Wenn das Team das Produkt an einem normalen Morgen nicht öffnet, wird das Produkt nicht von den Menschen genutzt, die ihm am nächsten sind. Jeder Bug wird dann zu einem abstrakten Ticket statt zu einem persönlichen Ärgernis.
Die klare Version: du wirfst eine Party und niemand kommt. Dieses Gefühl sind Daten. Es heißt meistens, dass das Produkt nie in der täglichen Routine war, und keine Menge neuer Features ändert das.
Eine Deadline schlägt ein besseres Modell
Code-Generierung hat die Form des Junior-Problems verändert, ohne es zu entfernen. Ein Junior mit einem Frontier-Modell und ohne erfahrenen Partner wird nicht schneller. Er verliert sich, höflich, für Tage.
Das Muster ist vorhersehbar. Eine Komponente wird angefragt, eine große Implementierung erscheint, ein Build scheitert, der Fehler geht zurück ins Modell, das Modell schlägt ein Refactoring vor. Zehn Tage später gibt es immer noch keinen fertigen Swap.
Was fehlt, ist nicht Können oder Motivation. Es ist eine Deadline, plus jemanden, mit dem man das Problem durcharbeitet. Code-Generierung ohne Auslieferungsgrenze erzeugt das Gefühl von Arbeit und keines der Ergebnisse.
Wenn eine Person alles bauen kann
Es gibt einen Fehlermodus, der nur auftaucht, wenn eine erfahrene Person sehr schnell wird. Früher lagen manche Teile eines Systems einfach jenseits einer Person. Arbeit musste komplett übergeben werden, und sie bewegte sich nur, wenn die andere Person lieferte.
Diese Abhängigkeit hat Dringlichkeit erzeugt. Entferne sie, und etwas Stilles passiert. Wenn alle wissen, dass die schnellste Person einspringen und es reparieren wird, bleibt niemand länger am schwierigen Problem. Sie warten auf die Beschwerde und das Rewrite.
Alles selbst tun zu können ist nicht dasselbe wie wirksam zu sein. Irgendwann muss die Regel sein, dass ein kaputtes Ding für den kaputt bleibt, dem es gehört, lange genug, dass er es spürt. Die Alternative ist ein Projekt, in dem eine Person die Arbeit macht und der Rest zuschaut.
Distribution ohne Werbebudget
Für Traffic zu bezahlen ist der teure Weg, ignoriert zu werden. Der günstigere Weg sitzt schon in den Integrations-Calls.
Früher waren die erfolgreichen Events die, die mit zehn unabhängigen Crews gebaut wurden, jede brachte ihr eigenes Publikum mit. Derselbe Zug funktioniert mit Infrastruktur-Partnern. Nimm einen kurzen Call auf, stelle fünf echte Fragen zur Integration, veröffentliche das Ergebnis, und beide Seiten teilen es.
Ein technischer Artikel, der mit einem Partner geschrieben wurde, erreicht das Publikum des Partners und das Publikum der Builder gleichzeitig. Das sind 200 neue Nutzer aus einem Gespräch, plus ein Dokument, das beweist, dass die Integration funktioniert.