Comment marchent les demandes de fonction et les rapports de bug dans IGNITE AI

Les équipes produit ne peuvent pas réparer ce qu’elles ne peuvent pas reproduire. Un avis une étoile qui dit « l’IA craint » n’apprend rien ; un rapport de bug serré avec appareil, étapes et une capture de l’estimation cassée, si. IGNITE AI inclut des chemins in-app pour les demandes de fonction et les rapports de bug, pour que la vraie douleur de logging arrive chez ceux qui shippent l’appli.

Le meilleur feedback vient souvent de gens au milieu du flux : caméra qui lâche sur une assiette sombre, code-barres qui ne matche pas en rayon, un share Friends qui n’a pas posté. Ce contexte est de l’or. Le capturer in-app bat l’espoir qu’un commentaire social trouve la bonne boîte mail.

Ce guide montre comment écrire des rapports qui ont de la traction, comment séparer les bugs des goûts, et comment demander une fonction sans rédiger une deuxième roadmap produit. Ce n’est pas une promesse que chaque idée shippe.

Bug versus fonction : étiquette-le honnêtement

Un bug, c’est quelque chose de cassé par rapport au comportement attendu : crash, écran blanc, mauvaise sauvegarde, sync qui échoue, UI qui te piège. Une demande de fonction, c’est quelque chose de nouveau ou d’amélioré : un autre export, un défaut plus malin, un raccourci de flux.

Mal étiqueter ralentit le triage. Si Snap Track a sauvé le mauvais repas après que tu aies confirmé tes éditions, c’est un bug. Si tu voudrais un tap « ajouter une cuillère d’huile » dans l’éditeur, c’est une demande de fonction — même si ça te paraît urgent.

Le rapport de bug minimum utile

Inclus ce que tu faisais, ce que tu attendais, ce qui s’est passé, et si ça se répète. Ajoute la version OS, la version de l’appli si elle est visible, et le nom de l’écran. Joins une capture ou un enregistrement d’écran quand la vie privée le permet — floute les calories si tu dois, garde le chrome d’erreur visible.

Note le timing : juste après une update, Wi-Fi versus cellulaire, après un long background. Les bugs intermittents ont besoin d’une fréquence (« 3 logs photo sur 10 »). La colère vague sans étapes se gare ; les rapports précis se mettent en file.

Reproduire les problèmes photo et scan

Pour les problèmes Snap Track, dis quel mode : photo repas, étiquette, code-barres, boisson, ou saisie décrire/voix. Mentionne l’éclairage, si tu as édité avant de confirmer, et si les mauvaises données n’apparaissent qu’après la sauvegarde.

Pour les codes-barres, inclus la marque et le nom du produit, et si l’étiquette physique dit autre chose. Les mismatches de base se réparent souvent quand l’identité du produit est claire — pas quand le rapport dit seulement « scan faux ».

Écrire des demandes de fonction qui survivent à la revue

Énonce le job à faire en une phrase : « J’ai besoin de ré-enregistrer la même box meal-prep cinq jours sans la reconstruire. » Puis décris ton workaround actuel et pourquoi il échoue. Évite les cours de mock UI sauf si tu illustres une vraie impasse.

Priorise avec ta semaine, pas la wishlist d’Internet. Les demandes liées à l’adhérence — éditions plus rapides, portions plus claires, exports coach — comptent en général plus que les thèmes cosmétiques.

Ce qu’il ne faut pas mettre dans un rapport

Ne colle pas de mots de passe, de codes de récupération, ni de détails de paiement complets. N’inclus pas les repas privés d’autres personnes depuis un feed Friends. Ne menace pas ; ça n’accélère pas le triage et ça peut faire ignorer le fil.

Évite de bundler dix sujets sans lien dans un seul blob. Sépare les crashes des items wishlist pour que chacun puisse se fermer tout seul.

Avis store versus canaux in-app

Les avis store influencent les téléchargements ; c’est une mauvaise base de bugs. Utilise-les pour un sentiment haut niveau après avoir déjà déposé un rapport reproductible in-app. Si tu ne fais que reviewer, l’ingénierie ne verra peut-être jamais le chemin de stack trace que tu as tapé à 22 h.

Si le support te relance, réponds une fois avec la même structure. Ré-écho les étapes d’origine bat le fait de réécrire le roman à chaque fois.

Comment le feedback façonne une appli photo-first

Le logging vision, l’OCR d’étiquette et le partage social échouent par nature sur les cas limites. Les rapports de terrain depuis de vraies cuisines et salles apprennent plus que les démos labo. Ton cas limite ennuyeux — buée sur la lentille, takeout brillant, yaourt multipack — peut être le fix de demain.

Ça ne veut pas dire que chaque demande shippe au prochain sprint. Ça veut dire qu’un signal de haute qualité s’accumule. Le bruit de basse qualité ralentit tout le monde, y compris les fonctions que tu veux vraiment.

Où IGNITE AI veut le signal

Utilise les flux in-app de demande de fonction et de rapport de bug depuis Profil ou les surfaces d’aide, pour que les métadonnées puissent voyager avec le ticket. Continue d’enregistrer avec Snap Track pendant que tu attends ; les workarounds comme le mode décrire ou les repas sauvés débloquent souvent la journée même quand un chemin caméra se comporte mal.

Les utilisateurs Premium qui tapent des bugs de capture IA devraient le dire — ces chemins sont lourds en compute et valent des rapports précis. L’honnêteté sur les portes Premium dans le feedback aide aussi : « bloqué derrière un paywall sans m’y attendre » n’est pas la même chose que « estimation fausse après que j’ai payé ».

Conclusion

Les bons rapports sont courts, reproductibles, et étiquetés bug ou demande. Les captures et les noms de mode battent les essais une étoile vagues.

Quand quelque chose casse au milieu d’un log, dépose-le dans les canaux in-app d’IGNITE AI avec les étapes — puis fais avancer le journal avec un chemin de capture de repli pendant que l’équipe utilise ton signal.