Encore: cómo es un sistema de diseño en 45 plataformas

En 2019, la dirección de Spotify se propuso que el audio estuviera disponible y fuera coherente en cualquier dispositivo. La cifra publicada por el equipo de diseño es impactante: 45 plataformas únicas y más de 2.000 tipos de dispositivos en 200 marcas. Alguien inicia una lista de reproducción en el televisor del salón, la continúa en el coche y la retoma en un portátil a la mañana siguiente.

Esto no es una versión a mayor escala del problema habitual de los sistemas de diseño; es un problema diferente. Un televisor se ve a tres metros, un reloj debe condensarlo todo, un ordenador de sobremesa tiene espacio de sobra y un coche tiene restricciones legales de interacción. Ninguna librería de componentes puede cubrir todo esto, y ninguna cantidad de documentación puede lograr que lo haga.

Encore se lanzó con dos segmentos. Encore Consumer Mobile se describió como increíblemente flexible, un catálogo vasto de componentes en constante crecimiento para experiencias centradas en móviles. Encore Web daba servicio a una gama más amplia de productos web. Debajo de ambos se encontraban los design tokens que cubrían decisiones fundamentales como esquemas de color y estilos tipográficos.

El modelo publicado es concéntrico. La base (foundation) está en el centro. Web y Mobile se sitúan encima como subsistemas pares con paridad de plataforma. Más afuera se encuentran los subsistemas más especializados —Content Web Platform, Advertising Web, Consumer Mobile—, cada uno cada vez más divergente del núcleo.

El valor de esta estructura es que la divergencia está acotada y localizada. Un componente que solo necesita publicidad reside en el anillo de publicidad, donde no puede filtrarse a la aplicación de consumo. Una decisión de color reside en la base, donde no puede ser anulada localmente. La alternativa —una única librería plana para todos— obliga a que cada necesidad especializada sea absorbida por el núcleo, hinchándolo, o que se construya fuera del sistema, que es donde mueren los sistemas de diseño.

Esta es la parte que rara vez aparece en los textos publicados sobre sistemas de diseño, porque es una confesión. Para 2022, el equipo consideró que el péndulo se había inclinado demasiado hacia la flexibilidad y que era necesaria una recalibración.

Lo ocurrido es reconocible. Consumer Mobile era deliberadamente flexible, por lo que los equipos de producto solicitaban componentes cada vez más refinados y el sistema seguía aceptando. La flexibilidad que comienza como una funcionalidad acaba convirtiéndose en una obligación: la necesidad específica de cada equipo se transforma en otro componente que el sistema debe mantener, y el catálogo crece más rápido de lo que cualquiera puede gestionar con coherencia.

La corrección de Spotify es el movimiento interesante. No restringieron Consumer Mobile ni empezaron a rechazar solicitudes. Formaron un equipo para crear componentes reutilizables para Encore Mobile, insertando una nueva capa entre Consumer Mobile y la base. La descripción publicada de su propósito es precisa: actúa como una primera línea de defensa, reduciendo la demanda sobre Consumer Mobile para que no tenga que proporcionar cada componente por sí mismo, al tiempo que crea una mayor paridad de plataforma en el resto del sistema.

Esto replantea un problema de gobernanza como uno estructural. Cuando un subsistema recibe solicitudes que no son realmente específicas para él, el problema no son las solicitudes, sino la falta de una capa compartida. Decir que no habría empujado a esos equipos a construir fuera del sistema. Añadir la capa permitió capturar ese trabajo.

El relato del equipo sobre el proceso de trabajo es lo suficientemente concreto como para imitarlo, y el cambio crucial que señalan es que los componentes multiplataforma ahora se diseñan como tales desde el principio, en lugar de considerarlo como algo secundario.

1. 1

   Reunir a todas las plataformas en la misma sala

   Representantes de iOS, Android y Web juntos, antes de diseñar nada. Su argumento sobre por qué esto es necesario es convincente: es raro encontrar a alguien experto tanto en web como en móvil, por lo que la experiencia debe reunirse en lugar de darse por sentada.

2. 2

   Cada plataforma audita y esquematiza lo que es único en su superficie

   El escritorio tiene más espacio. La televisión es diferente debido a la distancia de visionado. Un reloj requiere que toda la información esté condensada. Estos puntos se establecen como hechos sobre la superficie antes de que alguien discuta sobre el componente.

3. 3

   Alinear términos, estados e interacción de propiedades

   El grupo de trabajo define cómo se llaman las cosas, qué estados existen y cómo se combinan las propiedades. Este es el paso que se suele omitir, y omitirlo es la razón por la que dos plataformas acaban con un componente que comparte el nombre y nada más.

4. 4

   Diseñar el componente considerando todo a la vez

   No se trata de la versión de una plataforma más algunas adaptaciones. Es un único componente cuyas variantes ya se conocían antes de dibujarlo.

El tercer paso es el que merece la pena adoptar independientemente de cuántas plataformas tenga. La mayoría de las desviaciones de los componentes empiezan por una desviación del vocabulario: lo que para un equipo es «secundario», para otro es «ghost»; el estado desactivado de un equipo es el de «solo lectura» para otro y, para cuando alguien se da cuenta, ambos ya se han implementado.

Si busca el sistema de diseño de Spotify, una de las primeras cosas que encontrará son las Design & Branding Guidelines públicas de Spotify en el sitio para desarrolladores. Es importante aclarar que esto no es Encore ni un sistema de diseño en el sentido habitual. Es un documento de cumplimiento.

Su estructura lo delata: atribución, uso de contenido de Spotify, navegación de contenido, enlaces a Spotify, vistas de reproducción, visualización de entidades, uso del logotipo, uso de los colores, restricciones de logotipo y nomenclatura, fuentes. El motivo expuesto para las reglas de atribución es que el contenido disponible a través de Spotify pertenece a muchos titulares de derechos diferentes, por lo que cualquier uso de los metadatos de Spotify —nombres de artistas, álbumes y pistas, portadas, reproducción de audio— debe ir acompañado de la marca Spotify. La página indica que el uso de los recursos implica la aceptación de los Términos de Servicio del Desarrollador.

La distinción es importante si está construyendo algo que integre el contenido o la marca de un tercero. Esas reglas son contractuales, y el argumento de que «quedaba mejor sin el logotipo» no es una defensa válida. También es importante como categoría: si su producto es consumido por productos de otras personas, es posible que necesite este documento además de un sistema de diseño, y no son el mismo tipo de trabajo de redacción.

El modelo concéntrico se traslada directamente a las guías de diseño escritas para agentes de código de IA, y resuelve un problema que aparece en cuanto un proyecto tiene más de un tipo de superficie.

El fallo habitual es un único archivo DESIGN.md que intenta cubrir un sitio de marketing, el shell de una aplicación y una tabla de datos densa. Sus reglas acaban siendo ambiguas —"espaciado generoso, aunque las tablas pueden ser más densas"— y una regla ambigua no es una regla. El modelo tiene que decidir, y decide de forma distinta cada vez.

La organización por capas funciona de la misma manera que Encore:

# DESIGN.md          <- foundation: tokens, roles, prohibitions
                        applies everywhere, never overridden

# app/marketing/DESIGN.md
   Extends the root. Spacing scale shifted up one step.
   Hero type may use the display scale (48px+).
   Cards may use shadow elevation.

# app/dashboard/DESIGN.md
   Extends the root. Compact spacing (8-12px controls).
   Elevation is surface steps + hairline, never shadow.
   Table rows: 32px, no vertical padding above 8px.

Cada archivo es categórico dentro de su alcance. La raíz contiene solo aquello que genuinamente no debe variar —roles de color, familia tipográfica, prohibiciones— y las hojas contienen las decisiones que legítimamente difieren. Un agente que trabaja en app/dashboard/ lee dos archivos y obtiene una respuesta única y clara en lugar de un solo archivo con advertencias.

Analizamos 299 archivos DESIGN.md publicados para que los lean los agentes. El 44% no contenía ningún valor de tamaño concreto en ninguna parte y el 54% dependía de al menos un adjetivo vago —"limpio" en el 39%, "moderno" en el 36%. Ese es el problema de la ambigüedad en su estado extremo: un archivo que nunca se compromete con un número no puede entrar en conflicto consigo mismo, pero tampoco puede producir una interfaz coherente.

Probablemente no tenga 45 plataformas. Es posible que tenga tres superficies, dos de las cuales han divergido silenciosamente, y un equipo que no deja de pedir un componente que nadie más quiere. Es el mismo problema a menor escala, y las respuestas de Encore son válidas para ese tamaño.

Coloque lo que no debe variar en una base y haga que sea genuinamente irreemplazable. Permita que las necesidades especializadas residan en capas especializadas en lugar de forzarlas en el núcleo o expulsarlas totalmente del sistema. Cuando una capa se vea desbordada por las solicitudes, busque la capa faltante debajo de ella antes de empezar a rechazar peticiones. Y diseñe para todas las superficies al mismo tiempo, porque un componente adaptado a posteriori es un componente que divergirá.