Guindo Design
Disseny Estratègic de Producte Digital
Jeikin
Accessibilitat integrada en el flux de treball dels agents d'IA
El problema que ningú vol resoldre
Fa molts anys que dissenyem eines i apliquem intel·ligència artificial a diferents nivells, col·laborant amb empreses de totes les mides, i hi ha quelcom que es repeteix en cada projecte: l'accessibilitat tècnica genera massa fricció en el desenvolupament.
Els equips volen complir amb tots els requisits, però l'accessibilitat es viu com una pedra a la sabata, quelcom que afegeix complexitat, alenteix les entregues i que ningú sap ben bé per on començar a resoldre. Les eines que existeixen detecten problemes, però no ajuden a corregir-los. Assenyalen errors i desapareixen. El desenvolupador es queda sol davant un llistat de warnings que no entén.
Mentrestant, els agents d'IA estan escrivint cada vegada més codi. Components sencers, pàgines completes, fluxos funcionals. Ràpid, eficient, impressionant. Però sense cap control d'accessibilitat. La IA està dissenyada per ser complaent i consumir pocs tokens, de manera que sol prioritzar resultats ràpids i generar codi no accessible per defecte. Cap auditoria manual pot seguir aquest ritme.
La normativa europea d'accessibilitat (European Accessibility Act) ja és aquí. Els equips necessiten complir, però el procés per aconseguir-ho segueix trencat.
L'origen de Jeikin
A Guindo treballem amb intel·ligència artificial des de fa anys. Quan els agents d'IA van començar a escriure codi complet (no només suggerir línies, sinó generar components, pàgines i fluxos sencers) vam veure que produïen interfícies sense cap criteri d'accessibilitat. Botons sense etiquetes, formularis sense associació, contrastos insuficients, navegació per teclat inexistent.
Si els agents d'IA són tan eficients per produir codi per què no poden assegurar que sigui accessible? No com un simple linter que mostra warnings al terminal, sinó com un company de revisió que sap quins criteris apliquen, que exigeix verificar que els problemes s'hagin corregit, i que generi la documentació de compliment automàticament. Aquest company és Jeikin (obre en una finestra nova).
El repte de disseny
Jeikin havia de funcionar per a tres audiències que mai es veuen entre si.
- El desenvolupador viu al seu editor, a GitHub, al terminal. No vol aprendre una eina nova. No vol obrir un altre dashboard. Vol que l'accessibilitat aparegui al seu flux de treball habitual, en el seu llenguatge, sense interrompre el que ja està fent.
- El responsable d'equip necessita exactament el contrari: visió de conjunt. Quants problemes hi ha oberts, quina és la tendència, quina evidència té per a una auditoria. Necessita un dashboard, però un que s'alimenti sol, sense dependre que l'equip recordi actualitzar res.
- I hi ha un tercer usuari per al qual ningú havia dissenyat abans: l'agent d'IA. Perquè un agent faci una revisió d'accessibilitat de qualitat, necessita instruccions clares, criteris ben definits i un flux estructurat que li impedeixi saltar-se passos. Dissenyar l'experiència de l'agent és dissenyar la qualitat del resultat.
Les decisions que donen forma al producte
Invisible per al desenvolupador, visible per al lead
Jeikin no és una eina més al stack. S'integra directament a l'editor i a GitHub. El desenvolupador demana una revisió d'accessibilitat com a part de la seva conversa amb l'agent d'IA, rep troballes amb referència a l'arxiu i la línia exacta, corregeix, i el propi agent verifica que la correcció és vàlida. Sense canviar de context, sense obrir una altra pestanya.
El responsable d'equip, mentrestant, veu tot el progrés al dashboard: issues oberts, criteris coberts, tendència del projecte, evidència exportable. La informació flueix de l'editor al dashboard sense que ningú hagi de fer res.
El desenvolupador revisa accessibilitat des del seu editor, sense canviar de context
El responsable d'equip veu el progrés al dashboard: issues, criteris i evidència
Dogfooding com a principi de disseny
Jeikin s'audita a si mateix. Cada pantalla, cada component, cada text del producte ha passat per la seva pròpia eina de revisió. Això ens obliga a resoldre cada problema que detectem abans de demanar-li a ningú més que ho faci. Si Jeikin no pot complir els seus propis criteris, no té autoritat per exigir-los als altres.
Transparència i confiança
Jeikin explica què farà abans de fer-ho. Demana permís abans d'escanejar codi. No modifica res sense aprovació. El codi roman a la màquina del desenvolupador; només les troballes arriben al dashboard.
Cada correcció es verifica automàticament abans de marcar-la com a resolta
L'App de GitHub
L'aplicació a GitHub (obre en una finestra nova) revisa automàticament cada pull request. Publica troballes accionables directament al codi, amb el criteri d'accessibilitat aplicable i enllaços que obren l'arxiu exacte a l'editor amb un sol clic. Els problemes crítics bloquegen la fusió del codi fins que es corregeixen. El desenvolupador no necessita recordar que Jeikin existeix. Jeikin apareix quan és rellevant i es retira quan no ho és.
Jeikin publica troballes accionables directament al codi del pull request
Això és només el principi. Jeikin no és un producte estàtic, sinó un projecte viu que evoluciona cada setmana. Estem recollint feedback constant dels equips que ja l'utilitzen per polir els fluxos de treball i assegurar que l'eina s'adapta a la realitat de cada sprint. No busquem la perfecció teòrica, sinó una solució pragmàtica que evolucioni al mateix ritme que les necessitats dels nostres usuaris.