J’vais vous donner un exemple très con de ce que je disais hier pour le coût réel des features d’UI/UX, parce que je tombe encore sur un…

On part d’une interface toute simple
Vraiment, ça ne semble pas casser des briques comme ça…

Cas d’usage de cette fenêtre : le client a déjà souscrit à une offre chez nous, et désire modifier son n° de carte bleu
(Oui oui, ne vous inquiétez pas, un jour je compte bien vous les facturer, nos Cozies 😂)

Besoin du produit : « oui mais si le gens a déjà accepté les CGU lors de sa souscription et qu’on ne les a pas changé depuis, du coup il ne faut plus la case à cocher »
C’est éventuellement légitime de ne pas redemander à approuver les CGU une 2nde fois, mais qu’est-ce que ça implique comme boulot réel ?
Vous allez me dire « ben suffit de virer la case ». Oui, il suffit de…

Sauf que virer la case, ça fait que par défaut, le bouton « enregistrer », ben il passe de « désactivé » à « activé »…
Déjà rien que là, tu te prends un petit bout de code en plus pour générer ton HTML tout moisi fonction de si tu as des CGU à signer ou non…

Ensuite, ben comme tu ne lui changes pas son abonnement, juste sa carte, qui plus est qui est du coup stocké côté Stripe pour nous et pas du tout dans nos db (on n’a pas le droit cause PCI-DSS 😂), ben le code n’a MÊME PAS accès aux CGV à ce moment-là de la page en fait…

Je me retrouve à devoir aller chercher en db quel est l’abonnement associé à la carte, pour savoir si les CGV sont acceptées ou pas. Ce qui n’existait pas avant.
À devoir gréver mon HTML de test pour générer les classes qui vont bien parce que le « par défaut le bouton est désactivé » devient « ben ça va dépendre en fait ».
À vérifier que mon JS ne va pas planter parce qu’il va lui manquer cette case à cocher. Ou qu’il ne cherche pas à la soumission (contrôle de validité possible).

Follow

Bilan : pour « juste » virer une case à cocher dans un HTML, j’en suis à 2j de prise de tête…
N’aurait-on pas pu juste décider que l’utilisateur allait tout le temps valider les CGU quelque soit le cas ?

Sans parler que c’est typiquement du code qui va être difficile à tester vu le cas d’usage et qu’on risque de passer à la trappe assez rapidement. Au risque de grosses régressions sur le chemin vital pour ta boîte (facturation) !

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!