Note di prodotto su strumenti, test e rilascio
L’app ha cento funzioni. Cinque di queste contano.
TL;DR: I team aggiungono opzioni più in fretta di quanto le tolgono, e rilasciano senza provare la porta d’ingresso. La soluzione non è elegante. Disegna il percorso dell’utente prima della schermata. Riduci cento funzioni alle cinque che reggono l’uso. Descrivi gli strumenti in modo così chiaro che un modello possa costruirne l’interfaccia. Prova con il modello più piccolo disponibile, poi prova a mano ogni mattina finché l’automazione non si guadagna il diritto di sostituirti.
Questo articolo è disponibile anche in English , Deutsch e Español .
Disegna il percorso prima della schermata
Il lavoro di prodotto di solito parte da una schermata. Qualcuno apre un file di progetto, tira dentro i componenti, disegna una scheda, aggiunge un interruttore, aggiunge tre pulsanti. Il risultato è curato e non aiuta nessuno a concludere un compito.
Il problema è l’ordine. La prima cosa che serve è un diagramma di flusso del percorso dell’utente. Cosa viene prima? Cosa viene dopo? Cosa viene per terzo? Cosa dipende da cosa? Quali funzioni si usano più spesso? Quali funzioni contano di più?
Quando il disegno è chiaro, l’app si può progettare intorno a esso. E anche gli strumenti dietro si possono progettare intorno a esso. Un disegno, due risultati: l’interfaccia e l’API.
Cento funzioni, cinque che contano
Un prodotto può avere cento funzioni, o cento cose che si possono configurare, e probabilmente solo cinque di esse si usano il 99.9 percento delle volte.
Quelle cinque devono stare davanti. Devono funzionare ogni singola volta. Tutto il resto va sullo sfondo, dove resta raggiungibile senza contendersi l’attenzione.
Questo non è un discorso contro le funzioni. È un discorso su dove metterle. Una capacità che nessuno trova nella prima schermata è una capacità che nessuno usa.
Riduci il budget di confusione
La stessa lezione compare due volte, una nella progettazione degli strumenti e una in quella dell’interfaccia. Dai a un agente troppi strumenti e troppe capacità e si confonde. Esita, sceglie la cosa sbagliata, inventa argomenti, oppure torna al punto di partenza.
Una persona davanti a una schermata piena di opzioni si comporta allo stesso modo. Più pulsanti e più impostazioni non aggiungono potenza. Aggiungono caos.
La risposta non è una documentazione migliore. Sono meno cose. Riduci, riduci, riduci, e concentra tutta la superficie sul compito.
Strumenti, capacità, particolarità
La forma giusta per un server di strumenti non è un elenco piatto. C’è uno strumento, lo strumento ha capacità, e le capacità hanno capacità. Si apre all’indietro, come un albero.
Al primo livello ci sono soltanto gli strumenti. Al secondo livello ci sono le capacità. Al terzo livello ci sono le particolarità di quelle capacità.
Quella struttura non è decorazione. È il modo in cui un lettore, umano o modello, impara il prodotto senza una conversazione. Un elenco piatto di quaranta endpoint non dice a nessuno da dove iniziare.
Una descrizione chiara contiene già l’interfaccia
Un server MCP è un’API con le descrizioni di come funziona quell’API. Quando la descrizione è senza ambiguità, il lettore ne ricava il percorso dell’utente.
Questo apre una porta. Se un modello ha da una parte il sistema di progettazione e dall’altra lo strumento, può generare la schermata che sta in mezzo. Il traduttore nel mezzo è un modello linguistico.
Questo elimina un’intera categoria di riunioni. Quando la descrizione è chiara, non resta niente su cui discutere. O il flusso si può costruire da essa, o non si può.
La prova è la velocità, non il gusto
Le discussioni di progettazione di solito finiscono in opinioni. Se l’opzione A sta sopra l’opzione B non è una questione che si risolve discutendo.
Esiste una versione misurabile. Quanto ci mette un agente ad andare da A a B dentro il prodotto? Quanto deve pensare? Dove si confonde?
Così la qualità dell’interfaccia diventa un numero. E mette a nudo la realtà: un agente che legge un server MCP dal vivo dirà, senza giri di parole, che questo non lo capisce e che questo non è risolto bene.
Prova con il modello più stupido che trovi
Un modello di frontiera aggiusta i nomi fatti male tirando a indovinare dal contesto. Riempie l’argomento mancante, sceglie lo strumento più probabile e arriva comunque. Per questo è un giudice pessimo della chiarezza di un’interfaccia.
I modelli piccoli, che pensano poco e hanno poco contesto, non aggiustano niente. Se i nomi sono leggermente sbagliati, falliscono. Se il flusso si ramifica senza motivo, si perdono.
Così il modello piccolo diventa lo strumento di misura. Se il modello più stupido che trovi arriva in fondo, l’interfaccia è davvero chiara. Se non ci arriva, il problema è la descrizione, non il modello.
Semplificare vuol dire togliere
L’obiettivo è semplificare tutto, ridurre al minimo e togliere elementi. Non aggiungere elementi. Meno opzioni, meno funzioni, meno funzionalità su ogni schermata.
Questo esclude anche una mossa molto popolare. Ricostruire da zero non è automaticamente un progresso. Una riscrittura che arriva nello stesso punto è costata un trimestre e non ha cambiato niente.
L’unico desiderio che vale la pena proteggere è la riduzione a ciò che serve. Tutto il resto è attività.
Un compito, una schermata, dappertutto
Lo swap da una valuta a un’altra non deve avere due schermate diverse. Deve avere lo stesso aspetto al 100 percento ovunque compaia.
Uguale nell’app, uguale in un payment link, uguale quando qualcuno aggiunge denaro a un wallet. Il payment link è per le persone fuori dal prodotto, e questo non cambia niente. Aggiungere denaro al wallet e chiedere denaro per email sono lo stesso compito.
Ogni schermata diversa per lo stesso compito è un’altra cosa che l’utente deve imparare. La coerenza non è una preferenza di stile. È una decisione di costo.
Gli agenti da browser leggono la stessa schermata
Ci sono due tipi di agente. Uno chiama un’API costruita apposta per lui. L’altro apre un browser e guarda quello che vedrebbe una persona.
Il secondo tipo sta crescendo, e non ha bisogno di un’interfaccia speciale. Ha bisogno che quella normale si spieghi da sola immediatamente.
Questa è la vera prova di una schermata. Se un agente da browser su un telefono o su un desktop non capisce a cosa serve la schermata, anche una persona sulla stessa schermata sta tirando a indovinare.
Prova a mano finché l’automazione se lo guadagna
I test automatici controllano solo quello che qualcuno ha già pensato di verificare. Finché una suite non copre davvero i percorsi che contano, una pipeline verde non è la prova che la porta d’ingresso si apre.
Quindi la regola è manuale. Scegli i dieci percorsi che contano, e ogni persona del team li percorre su un dispositivo vero la mattina, prima della posta e prima della prima pull request. E si va avanti così finché qualcosa di automatico non lo sostituisce.
Questa è la parte meno alla moda della lista ed è quella che intercetta più problemi. Una schermata di login che nessuno riesce a superare non è un caso limite. È il prodotto.
Quando nessuno del team apre il prodotto
Un login rotto è un bug. Un login rotto che resta lì per giorni è la risposta a un’altra domanda.
Se il team non apre il prodotto in una mattina normale, il prodotto non viene usato dalle persone più vicine a esso. Ogni bug diventa un ticket astratto invece di un fastidio personale.
Detto senza giri di parole: fai una festa e non viene nessuno. Quella sensazione è un dato. Di solito significa che il prodotto non è mai entrato nella routine quotidiana, e nessuna quantità di funzioni nuove lo cambia.
Una scadenza batte un modello migliore
La generazione di codice ha cambiato la forma del problema dei junior senza eliminarlo. Un ingegnere junior con un modello di frontiera e senza un partner senior non diventa più veloce. Si perde, con educazione, per giorni.
Lo schema è prevedibile. Si chiede un componente, compare un’implementazione enorme, la build fallisce, l’errore torna dentro il modello, il modello propone un refactor. Dieci giorni dopo lo swap non è ancora finito.
Quello che manca non è la capacità o la motivazione. Manca una scadenza, più qualcuno con cui affrontare il problema. La generazione di codice senza un confine di rilascio produce la sensazione del lavoro e nessun risultato.
Quando una persona sola può costruire tutto
C’è un modo di fallire che compare solo quando una persona senior diventa molto veloce. In passato, alcune parti di un sistema erano semplicemente fuori portata per una persona sola. Il lavoro andava passato per intero, e andava avanti solo quando l’altra persona consegnava.
Quella dipendenza creava urgenza. Togliela e succede una cosa silenziosa. Quando tutti sanno che la persona più veloce interverrà a sistemarla, nessuno resta fino a tardi sul problema difficile. Aspettano la lamentela e la riscrittura.
Saper fare tutto da soli non è la stessa cosa che essere efficaci. A un certo punto la regola deve essere che una cosa rotta resta rotta per chi la possiede, abbastanza a lungo da sentirla. L’alternativa è un progetto dove una persona fa il lavoro e gli altri guardano.
Distribuzione senza budget pubblicitario
Pagare per il traffico è il modo costoso di essere ignorati. La strada più economica è già lì, dentro le chiamate di integrazione.
Prima, gli eventi riusciti erano quelli costruiti con dieci squadre indipendenti, ognuna con il suo pubblico. La stessa mossa funziona con i partner di infrastruttura. Registra una chiamata breve, fai cinque domande vere sull’integrazione, pubblica il risultato, e le due parti lo condividono.
Un articolo tecnico scritto con un partner raggiunge insieme il pubblico del partner e quello di chi costruisce. Sono 200 utenti nuovi da una sola conversazione, più un documento che dimostra che l’integrazione funziona.