Pissarres blanques amb CLI

Hi ha una manera molt senzilla de mesurar la veterania d'un dissenyador: analitzar-ne la dependència de les eines. En començar, és natural obsessionar-se amb el programari de tendència, la metodologia de moda o el darrer set de prompts que garanteix resultats efectistes en segons. Si hagués de donar un únic consell a qui comença, a més a més d'una bona biblioteca, li diria que no se separés mai d'una pissarra blanca. En aquests diagrames, fletxes i formes que semblen jeroglífics per a qui arriba tard a la reunió, és on resideix realment el cabdell de qualsevol projecte.

Al sector B2B / SaaS, dissenyar és triar el nivell d'abstracció adequat per resoldre un problema de negoci. De vegades la solució és visual, de vegades és purament lògica i, sovint, és una barreja de totes dues, comprimida en el temps gràcies a la IA.

Les darreres setmanes de 2025 van ser un laboratori perfecte per a aquesta tesi. Recentment, dos projectes consecutius a l'estudi ens van servir per validar que el disseny no és una recepta única. Dos problemes amb naturaleses oposades que ens van exigir operar en nivells d'abstracció totalment diferents.

El primer va ser una eina interna per a un SaaS amb una urgència crítica de sortida al mercat. Vam decidir que la millor interfície era, senzillament, cap. Apostem per una interfície de línia d'ordres (CLI) per gestionar la configuració del producte. No va ser un retrocés nostàlgic, sinó una decisió estratègica, sacrificant la comoditat de la interfície a favor d'una validació tècnica immediata. Prioritzem l'arquitectura i la robustesa lògica sobre l'experiència d'usuari. Operar en aquest nivell d'abstracció ens va permetre validar variables complexes amb una agilitat que una UI tradicional només hauria endarrerit. En aquest escenari, la IA es va encarregar d'accelerar la viabilitat tècnica i ens va permetre iterar sobre la lògica del producte molt abans de plantejar-nos la seva representació visual.

Dies després, l'escenari va ser l'invers, necessitàvem alinear en menys d'una setmana un equip tècnic i un producte sobre una nova funcionalitat. En aquest cas, el pragmatisme en va dictar l'execució. En lloc de dissenyar des de zero, utilitzem IA per acoblar patrons i components ja validats en un prototip funcional. Si en el cas anterior eliminem la UI per alliberar el valor del producte al mercat, aquí l'automatitzem per accelerar el consens de l'equip. La inspiració, com se sol dir, va ser la data de lliurament.

Tot i això, en aquesta carrera per l'eficiència hi ha un perill latent: la temptació de prendre dreceres sense tenir un mapa.

Recentment, el CTO d'una gran companyia em compartia una preocupació que ressona a tota la indústria. Estaven detectant una bretxa de coneixement crítica en els seus desenvolupadors júniors, una dependència absoluta del prompt que els permetia lliurar codi funcional, però sense comprendre l'estructura subjacent ni les implicacions de seguretat o escalabilitat del que estaven «generant». El problema no era avui, sinó el demà: qui liderarà i supervisarà els sistemes d'aquí a cinc anys si ningú no va aprendre a construir-los des dels fonaments?

Per això havien optat per una solució radical: forçar els perfils més joves a resoldre reptes tècnics mitjançant programari no connectat, recorrent únicament a tutories i bibliografia física. Només a través d'aquesta «desconnexió forçada» es garanteix que el professional desenvolupi el criteri necessari per no ser un simple operari de la màquina.

Si deleguem l'execució a la IA sense entendre l'arquitectura, ja sigui codi o disseny, perdem la capacitat de corregir, d'iterar amb sentit i, finalment, de liderar. El disseny de producte el 2026 ja no es tracta de qui utilitza millor l'eina, sinó de qui entén millor el problema. La IA ens pot donar la resposta, però nosaltres hem de continuar sent els amos de la pregunta.

Per cert, si algú necessita un recolzament estratègic per al vostre equip de producte o simplement vol contrastar idees, la nostra pissarra sempre està disponible.

 

Més entrades de Disseny