Studio · Por aquí se empieza

Tres semanas para sacar el criterio de las reuniones.

Tres semanas y alcance cerrado. Salís con el criterio de vuestro producto convertido en reglas. Priorizamos las que pueden comprobarse de forma fiable y dejamos explícito qué debe seguir siendo juicio humano. Si después no seguimos trabajando juntos, eso se queda.

Ver cómo funciona

Para quién es

  • Tenéis un sistema de diseño y, aun así, cada pantalla se vuelve a discutir desde cero.
  • Queréis mover decisiones al servidor —composición, agentes— y no sabéis qué tendría que estar escrito antes de tocar nada.
  • El criterio existe, pero vive en la cabeza de tres personas y no hay forma de comprobarlo cuando esas tres no están en la reunión.
  • El equipo revisa a mano, versión tras versión, cosas que una regla podría vigilar sola.

Para quién no

  • Si solo necesitáis el diseño visual de unas pantallas, este diagnóstico no es el formato adecuado.
  • Si nadie del equipo puede revisar e integrar cambios en el repositorio, no tendremos dónde dejar las comprobaciones que merezcan quedarse.
  • Si la decisión ya está tomada y lo que se busca es alguien que la firme desde fuera.

Qué os lleváis

  1. 01

    El mapa de decisiones

    Qué decide vuestro producto, quién lo decide hoy y dónde está escrito. La respuesta al «dónde» suele ser «en la cabeza de tres personas».

  2. 02

    Las reglas, escritas

    Entre diez y veinte candidatas: cuándo aplican, qué debe ocurrir, qué no se permite y cómo se comprobarían. Las no verificables no se disfrazan de automatización: quedan como revisión humana o investigación pendiente.

  3. 03

    El validador funcionando

    El subconjunto priorizado que sea técnicamente fiable, dentro de vuestro repositorio y vuestro flujo. Cuando una regla no admite una comprobación honesta, no se fuerza: se documenta su revisión humana.

  4. 04

    Lo que costaría seguir

    Alcance, orden y lo que no hay que hacer. Sirve para contratarme y sirve para no contratarme: la información es la misma.

Cómo van las tres semanas

  1. Semana 1

    Leer

    Vuestro sistema, vuestro repositorio y dos conversaciones de noventa minutos con quien decide de verdad.

  2. Semana 2

    Escribir

    Las reglas candidatas, una por una, discutidas con el equipo y descartadas sin pena cuando no hay manera de verificarlas.

  3. Semana 3

    Dejarlo corriendo

    El validador dentro de vuestra build y una sesión de traspaso para que el siguiente cambio lo haga el equipo, no yo.

Lo que necesito de vuestro lado

  • Lectura del repositorio donde vive el sistema.
  • Una persona que pueda revisar y fusionar una rama.
  • Noventa minutos de quien decide, dos veces.

La demostración

Este sitio ya funciona así.

Antes de publicar, este sitio comprueba automáticamente enlaces, imágenes y criterios de contenido. Es una demostración del mecanismo, no una promesa de que todo criterio de un producto pueda automatizarse.

Explorar las 11 reglas del sitio

10 pueden detener la publicación si detectan un incumplimiento.

  1. 01

    Estado honesto

    Bloquea la publicación

    Cuando un proyecto es público, debe declarar territorio, resumen y estado. No se permite publicar una ficha sin decir en qué punto está.

    R1 estado-honesto

  2. 02

    Toda imagen explica por qué está

    Aviso

    Los still life no son decoración: son metáforas. Si acompañan a un proyecto, llevan texto alternativo y pie que justifique su presencia.

    R2 imagen-con-motivo

  3. 03

    Presupuesto de imagen

    Bloquea la publicación

    Ninguna imagen servida supera los 200 KB. Los originales pueden pesar; lo que viaja por la red, no.

    R3 presupuesto-imagen

  4. 04

    Sin páginas huérfanas

    Bloquea la publicación

    Una página que existe y nadie enlaza no es una página: es deuda.

    R4 sin-huerfanas

  5. 05

    Sin relleno

    Bloquea la publicación

    El vocabulario prohibido no es una guía de estilo: es un bloqueo.

    R5 sin-relleno

  6. 06

    Un contenedor no pisa el color de un componente

    Bloquea la publicación

    Aprendido a la mala: una regla de navegación que pintaba a sin excluir .btn dejó el botón del menú en 1,28:1 contra su propio fondo. Un botón lleva su color; el contenedor no decide por él.

    R6 componente-manda

  7. 07

    Una clase que cruza a un componente necesita :global

    Bloquea la publicación

    Aprendido tres veces el mismo día: los estilos con ámbito de Astro llevan el identificador del archivo que los declara. Si pasas una clase a un componente (<Still class="plate-fallback" />), el nodo real la recibe con OTRO identificador y la regla no aplica. Síntoma: la imagen de respaldo no se ocultaba y se veían vídeo e imagen a la vez.

    R7 clase-cruza-componente

  8. 08

    Toda ancla interna tiene que existir

    Bloquea la publicación

    Aprendido rompiéndolo: al reestructurar la home desapareció la sección #demostracion y el menú siguió apuntando ahí. Un enlace que no lleva a ninguna parte no falla ruidosamente, simplemente no hace nada.

    R8 ancla-existe

  9. 09

    El texto publicado le habla al lector

    Bloquea la publicación

    La página de privacidad terminaba con «si necesitas una versión ampliada, dímelo»: una frase dirigida a quien encargó el texto, publicada donde peor sienta romper el marco. Es residuo de redacción, y se cuela sin ruido.

    R9 habla-al-lector

  10. 10

    La afirmación regulatoria lleva su aviso

    Bloquea la publicación

    Nada de lo que publica La Vigencia es asesoramiento jurídico, y eso se dice en la propia ficha, no en la letra pequeña de otra página.

    R10 aviso-legal

  11. 11

    Un container conserva su margen lateral

    Bloquea la publicación

    Aprendido rompiéndolo: .case-body llevaba también la clase container, y un atajo padding: X 0 le borraba el padding horizontal que esa clase aporta. En escritorio no se nota —el max-width ya deja aire—, así que el fallo sobrevivió meses: en móvil el texto de todas las fichas de proyecto tocaba los dos bordes de la pantalla. El atajo es el problema; el longhand padding-top / padding-bottom deja pasar lo que pone el contenedor.

    R11 container-con-margen

Dos ejemplos: comprobar que los enlaces apuntan a un destino y detectar estilos que eliminan los márgenes laterales en móvil. Convertir estos fallos en comprobaciones ayuda a que no reaparezcan con el siguiente cambio.

Cómo se escribe una regla así

Empezar

Contadme qué sistema tenéis, qué decisión se repite y qué os gustaría hacer explícito. Primero reviso el encaje; si hay un siguiente paso claro, lo propongo. Si no, también.

Plantear un diagnóstico

¿Todavía no hay nada que diagnosticar? Las otras formas de colaborar · formación para el equipo.