Cuándo diseñar para escalar, y cuándo es solo adivinar caro
Todos los artículos sobre escalabilidad te dicen que planifiques el crecimiento. Casi ninguno menciona que planificar el crecimiento tiene un precio, que lo pagas de inmediato y que el beneficio puede no llegar nunca.
Me he quemado por los dos lados. Es la única razón por la que creo que tengo algo útil que decir aquí.
Quemadura uno: el diseño que no podía crecer
Hace unos años trabajé en un producto para una startup pequeña. Fue bien, que era el problema. Según crecía, cosas que habían estado bien empezaron a romperse: componentes dibujados ligeramente distintos cada vez, estados que nadie había considerado, una tabla que funcionaba con diez filas y era inservible con cuatrocientas.
Nada de eso fue dramático. Fue una acumulación lenta de pequeñas incoherencias, y deshacerla costó unos dos meses de trabajo que no produjeron nada que un usuario pudiera ver.
La lección que saqué fue: piensa en lo que viene después. Lo cual era cierto, y luego lo apliqué de más durante casi un año.
Quemadura dos: el diseño que creció hacia un mercado que no llegó
En el proyecto siguiente lo hice bien. Multidivisa en el modelo de datos. Componentes construidos para un sistema de permisos que pensábamos tener. Maquetas que sobrevivirían a un segundo idioma. Una librería de componentes con variantes para casos que habíamos hablado pero no lanzado.
Nada se desperdició de forma evidente: el código funcionaba todo. Pero cada cambio posterior había que hacerlo tres veces, porque todo estaba parametrizado para casos que no aparecieron nunca. Entregamos más lento durante un año para servir a un público que no llegamos a tener.
Nadie abre un ticket por esto. Eso es lo que lo hace peligroso. Un diseño que se rompe al crecer provoca un desastre evidente que alguien tiene asignado arreglar. Un diseño construido para un crecimiento que no llegó provoca un impuesto silencioso sobre cada cambio, y nunca se le atribuye a la decisión que lo causó.
La señal que uso ahora
Dejé de intentar predecir y empecé a vigilar una sola cosa, el mismo giro que acabé dando con la medición: esta decisión se ha tomado ya dos veces, de forma distinta, y ha causado un problema?
Ya está. Esa es la prueba entera.
- Dos personas construyeron un componente de tarjeta ligeramente distinto y ahora la página se ve mal → construye el componente en condiciones.
- Alguien pidió una segunda divisa → no construyas multidivisa. Averigua si es un cliente siendo educado o un patrón.
- El mismo problema de maquetación ha salido en tres sitios → eso es un patrón, y se gana un sistema.
Un sistema de diseño es una respuesta a la repetición. Si la repetición no ha ocurrido, estás manteniendo la respuesta a una pregunta que nadie ha hecho. He escrito lo mismo sobre la versión más pequeña de un producto y es el mismo instinto: el coste es seguro e inmediato, el beneficio es especulativo y posterior.
La excepción que sí importa
Hay una clase de decisión en la que sí deberías pensar por adelantado aunque no tengas la señal, y no es la que suele preocupar a la gente.
No es visual. Es cualquier cosa que se vuelve difícil de cambiar en cuanto existen datos reales. Cómo modelas un usuario. Si algo pertenece a una persona o a una cuenta. Cuál es la estructura de URLs. Esas son puertas de una sola dirección: cambiarlas después significa una migración, y las migraciones son donde los productos van a perder un trimestre.
Colores, espaciados, variantes de componentes, maquetación: todo reversible. Adivina y sigue.
La distinción no es «decisiones grandes contra pequeñas», es cuánto cuesta equivocarse, y son preguntas distintas. Un montón de decisiones que en la sala parecen enormes son trivialmente reversibles, y un montón que parecen detalles no lo son.
Qué me diría a mí mismo en 2024
La versión de este artículo que escribí hace dos años terminaba con «piensa en cómo podría crecer, te alegrarás de haberlo hecho». Eso es media idea.
La entera: piensa en qué partes no podrías cambiar después, y sé honesto con que todo lo demás es una suposición. Nadie puede predecir el futuro. Lo que sí puedes hacer es identificar qué decisiones no podrías deshacer, gastar ahí tu cabeza, y dejar que el resto siga saliendo barato.
Si quieres un sitio concreto por donde empezar, la etapa 01 del método va exactamente de esto: decidir ahora o seguir pensando, y cuánto cuesta cada opción.
Preguntas que me hacen sobre esto
Cuándo deberías empezar a construir un sistema de diseño?
Cuando la misma decisión se ha tomado dos veces, de forma distinta, y ha causado un problema. Antes no. Un sistema es una respuesta a la repetición, así que si la repetición no ha ocurrido estás manteniendo la respuesta a una pregunta que nadie ha hecho, y el mantenimiento es real mientras el beneficio es hipotético.
Qué significa de verdad diseñar para escalar?
En la práctica significa dos cosas: que un componente pueda absorber un caso que no anticipaste sin reconstruirlo, y que alguien que llegue después sepa cuáles son las reglas. No significa anticipar todos los escenarios. Nadie puede hacer eso, e intentarlo produce una complejidad que pagas de inmediato contra un beneficio que puede no llegar nunca.
Cómo se evita sobreingenierizar un diseño?
Pregúntate cuánto cuesta equivocarse. Si el diseño se puede cambiar en una tarde, adivina y sigue. Si cambiarlo significa una migración, un reonboarding o un cambio de datos, eso es una puerta de una sola dirección y se gana el pensamiento extra. Casi toda la discusión sobre sobreingeniería es en realidad una discusión sobre en cuál de esas dos estás.
Es mejor diseñar para escalar demasiado pronto o demasiado tarde?
Demasiado tarde, normalmente, pero solo porque lo tarde se ve y lo pronto no. Un diseño que se rompe al crecer provoca un desastre evidente y arreglable. Un diseño construido para un crecimiento que no llegó provoca un impuesto lento sobre cada cambio, y nadie abre nunca un ticket por eso.