Design Ops 2026

Un sistema de disseny sol començar amb una intenció clara: reduir incoherències, facilitar la reutilització i ajudar que disseny i desenvolupament treballin amb un llenguatge compartit. Durant les primeres etapes, la biblioteca és manejable, els components són fàcils d’identificar i les decisions encara es poden resoldre entre poques persones.

El problema apareix quan el producte, l’equip i les necessitats comencen a créixer.

Sorgeixen noves variants per respondre a casos concrets, alguns components es dupliquen perquè no es troba l’opció adequada i certes excepcions, inicialment temporals, acaben convertint-se en una part habitual de la interfície. Mentrestant, la documentació deixa de reflectir el que passa en producció i disseny i desenvolupament comencen a treballar amb versions diferents d’un mateix patró.

Aquest desordre no sol aparèixer de manera sobtada. S’acumula a poc a poc, a través de petites decisions que semblen raonables per separat: copiar un component per avançar més de pressa, afegir una propietat que només necessita un equip o ajornar una actualització perquè hi ha altres prioritats. Amb el temps, la biblioteca creix, però no necessàriament millora.

Aleshores, el sistema que havia de reduir decisions comença a generar-ne. Els dissenyadors dubten sobre quin component utilitzar, els desenvolupadors troben diferències entre els fitxers de disseny i el codi, i cada modificació requereix comprovar dependències que ningú no coneix del tot. La consistència deixa d’estar garantida pel sistema i torna a dependre de l’esforç individual de cada persona.

Arribats a aquest punt, el repte ja no consisteix a dissenyar més components. Consisteix a crear una manera sostenible de mantenir-los, fer-los evolucionar i decidir què ha de romandre, canviar o desaparèixer. És aquí on Design Ops i la governança deixen de ser qüestions organitzatives secundàries i es converteixen en una part essencial del mateix sistema de disseny.

Design Ops: el sistema operatiu darrere del sistema de disseny

Un sistema de disseny no es manté per si sol. Pot tenir una biblioteca ben construïda, components reutilitzables, tokens coherents i una documentació inicial completa, però tot això perd valor si no existeix una manera clara de gestionar-ne l’evolució.

Aquí és on entra Design Ops.

Design Ops no consisteix únicament a organitzar fitxers, coordinar reunions o mantenir un calendari de lliuraments. La seva funció és crear les condicions perquè el treball de disseny sigui sostenible a mesura que augmenten els equips, els productes i les necessitats. És, en certa manera, el sistema operatiu que permet que el sistema de disseny continuï funcionant.

Mentre el sistema de disseny defineix quins components, patrons i principis s’han d’utilitzar, Design Ops estableix com es creen, qui els manté, de quina manera es revisen i quan s’han d’actualitzar o retirar. També ajuda a decidir com poden contribuir altres equips i quins criteris s’han de complir abans d’incorporar una nova solució a la biblioteca compartida.

Sense aquestes regles, cada canvi depèn de converses improvisades. No queda clar qui pot aprovar una variant, què cal fer quan disseny i codi no coincideixen o com actuar quan un component ja no respon a les necessitats del producte. El resultat sol ser una barreja de decisions locals, duplicitats i solucions que avancen en paral·lel.

Per evitar-ho, calen almenys tres elements: responsabilitats, processos i criteris compartits.

Les responsabilitats permeten saber qui manté cada part del sistema, qui valida els canvis i qui ha d’intervenir quan apareix un problema. Els processos ofereixen un recorregut comprensible per proposar, revisar, provar i publicar millores. Els criteris ajuden a distingir quan una necessitat justifica un component nou, quan es pot resoldre amb una variant i quan convé mantenir una solució fora del sistema global.

Això no significa convertir cada decisió en un tràmit lent ni centralitzar tot el control en un únic equip. Al contrari, una bona estructura de Design Ops hauria de reduir la dependència de converses constants i facilitar que les persones puguin avançar amb autonomia dins d’uns límits coneguts.

L’objectiu no és afegir més gestió al voltant del disseny, sinó evitar que la manca de gestió acabi creant més feina. Quan les responsabilitats, els processos i els criteris són clars, el sistema de disseny pot créixer sense dependre de la memòria, la disponibilitat o el criteri individual d’unes poques persones.

Ownership i governança: qui decideix què canvia

A mesura que un sistema de disseny creix, també creix el nombre de persones que l’utilitzen, el modifiquen i detecten noves necessitats. Per això, no n’hi ha prou amb permetre contribucions: també ha de quedar clar qui pot prendre decisions sobre el sistema.

L’ownership defineix qui manté cada component, qui revisa els canvis, qui valida la seva implementació i qui decideix quan una solució s’ha d’actualitzar o retirar. No implica que una sola persona ho controli tot, sinó que cada decisió tingui una persona responsable reconeixible.

Hi ha diferents models de governança. En un model centralitzat, un equip específic manté el sistema i aprova les contribucions. En un de federat, diferents equips hi participen de manera més autònoma sota unes regles comunes. El model híbrid combina tots dos enfocaments: un nucli central protegeix els fonaments mentre altres equips contribueixen en àrees concretes.

No hi ha un model vàlid per a totes les organitzacions. L’elecció depèn de la mida de l’equip, la varietat de productes i el nivell de maduresa del sistema. L’important és evitar dos extrems: que tot depengui d’unes poques persones o que qualsevol pugui introduir canvis sense coordinació.

Una governança eficaç no busca controlar cada detall, sinó assegurar que les decisions tinguin context, criteris compartits i seguiment. Així, el sistema pot evolucionar sense perdre coherència ni convertir-se en un fre per a qui l’utilitza.

Evitar el component sprawl

El component sprawl apareix quan la biblioteca creix sense prou control i es comença a omplir de components duplicats, variants gairebé idèntiques i solucions creades per resoldre casos molt concrets.

Sovint no es deu a una manca de criteri. Els equips necessiten avançar i, si no troben una solució adequada o el procés per sol·licitar canvis és massa lent, acaben creant una alternativa local. El que semblava una solució temporal pot acabar consolidant-se i conviure amb altres versions similars.

Abans de crear un component nou, convé comprovar si respon a una necessitat compartida, si es pot resoldre mitjançant una variant existent o si només afecta un context específic. També és important valorar si el seu comportament, contingut i propòsit són realment diferents, i no només la seva aparença.

Una solució local no és necessàriament un problema. Pot servir per experimentar i validar una necessitat abans d’incorporar-la al sistema global. El risc apareix quan aquestes excepcions no es revisen i acaben multiplicant-se sense que ningú no sàpiga quines s’han d’utilitzar.

Evitar el component sprawl no consisteix a limitar el creixement, sinó a assegurar que cada peça nova tingui una raó clara per existir i un lloc definit dins del sistema.

Versionament i documentació viva

Quan un component canvia, no n’hi ha prou amb publicar una versió nova. Les persones que l’utilitzen necessiten saber què s’ha modificat, per què, a qui afecta i si han de fer alguna acció per adaptar-s’hi.

Per això, el versionament ha de comunicar l’estat de cada component: si està en fase experimental, si és estable, si quedarà obsolet o si serà retirat. Quan un canvi trenca comportaments anteriors, també ha d’incloure instruccions de migració i un termini raonable per aplicar-les.

La documentació forma part d’aquest procés. No s’hauria de limitar a descriure propietats, mides o variants, sinó que ha d’explicar per a què serveix el component, quan s’ha d’utilitzar, quines limitacions té i quines decisions justifiquen el seu funcionament.

Per mantenir-se útil, la documentació s’ha d’actualitzar al mateix temps que el disseny i el codi. Si es deixa per després, és fàcil que acabi descrivint una versió que ja no existeix.

Una documentació viva redueix dubtes, evita interpretacions diferents i conserva el context darrere de cada decisió. Així, el sistema no depèn únicament de qui el va crear, sinó que pot ser entès i mantingut per tot l’equip.

Deute de disseny i ritmes de manteniment

El deute de disseny apareix quan decisions temporals, excepcions o components antics comencen a dificultar l’evolució del producte. Es pot manifestar en patrons duplicats, valors aplicats manualment, diferències entre disseny i codi o solucions que ningú no s’atreveix a retirar per por de trencar alguna cosa.

No tot el deute té la mateixa urgència. Convé prioritzar-lo segons el seu impacte: quant afecta l’experiència, quants equips en depenen, quins riscos genera i quanta feina addicional provoca. Així s’evita dedicar temps a corregir detalls menors mentre persisteixen problemes estructurals.

Per gestionar-lo no cal omplir el calendari de reunions. És més útil establir ritmes senzills i previsibles: revisions periòdiques del backlog, petites auditories de components, finestres de publicació i plans clars per retirar versions obsoletes.

També és important registrar el deute quan s’accepta conscientment. Una solució provisional pot ser vàlida si se’n coneix l’abast, té una persona responsable i hi ha un moment previst per revisar-la.

El manteniment funciona millor quan forma part de la feina habitual i no depèn d’una gran neteja ocasional. Un sistema cuidat amb freqüència acumula menys deute i permet que els canvis futurs siguin més ràpids, segurs i comprensibles.

Conclusió

La governança d’un sistema de disseny no s’hauria de convertir en una cadena d’aprovacions que alenteix cada canvi. La seva funció és oferir un marc clar perquè els equips puguin avançar amb autonomia sense perdre consistència.

Quan les responsabilitats, els criteris i els processos són comprensibles, és més fàcil saber quan reutilitzar un component, quan proposar una millora i quan experimentar amb una solució local. La governança deixa de ser una capa de control i es converteix en una eina per prendre decisions amb menys fricció.

També hi ha d’haver espai per evolucionar. Un sistema massa rígid pot obligar els equips a treballar-ne al marge, mentre que un de sense límits acaba fragmentant-se. L’equilibri consisteix a protegir els principis comuns i, alhora, permetre que apareguin noves solucions quan el producte les necessita.

Un sistema de disseny saludable no és el que no canvia mai, sinó el que pot fer-ho de manera comprensible i sostenible. Governar bé significa facilitar aquesta evolució, reduir decisions repetides i mantenir la coherència sense convertir el sistema en un obstacle.

Quina part del vostre sistema de disseny encara depèn de decisions informals o del coneixement d’unes poques persones?