Cómo trabajamos

El mapa del proyecto: quién es quién, de dónde sale el contenido, dónde vive todo y cómo se monta una página. Escrito para alguien de diseño que llega nuevo, no para un perfil técnico.

Qué es esto

La web nueva de SEK — SEK Group y los colegios SEK International School —, en WordPress con Gutenberg. Tres equipos en el mismo repositorio: UX hace los wireframes, UI —nosotros— los convierte en maquetas de alta fidelidad, y dev las lleva al theme de WordPress.

Lo que entregamos no es código para copiar: es la especificación visual. Dice cómo tiene que verse; dev reproduce los estilos y reescribe el HTML por debajo con sus propios bloques.

Enlaces principales

QuéEnlace
Figma — wireframes y librería de componentes[SEK] Library 2026
Wireframes en Vercel — cuando UX los monta ahí en vez de en Figmasek-gutenberg.vercel.app
Repositorio — el código, las tres carpetas de equipoBitbucket · pixeldivisiondev/sek-gutenberg
Dónde se entrega a devui/output/ en el repo — solo lo revisado; ver Páginas
Imágenes originales de SEKCarpeta de Drive — ver Imágenes
El linter — las reglas que se comprueban solasExplicado más abajo, en «Por qué las páginas se parecen entre sí»; la lista completa está en Para dev

El equipo

QuiénEquipoQué haceSu rama
Carla LópezUXWireframes y contenido. Es a quien se le pide el copy que falta y quien decide cuando el wireframe deja algo abiertoux/carla
Irene GalánUXWireframesux/irene
Guillermo VarelaUIMaquetación y sistema de diseñoui/guille
Gabriela PredadevTheme de WordPressdev/gabriela
Eduardo GildevTheme de WordPressdev/eduardo

Para lo que falta de contenido o hay que decidir, la interlocución es con UX — está todo listado en Para UX. Para bugs del theme y cómo migrar, con dev — en Para dev.

De dónde sale una página

  1. El board de sprints manda. Es un Google Sheet donde UX marca qué wireframes están listos. Una página es «pintable» cuando su columna UX está en ✓ DONE. El mapa está en SEK 2026/brain/Architecture/sprints-board.md, con el enlace al sheet.
  2. UX trabaja siempre en Figma ([SEK] Library 2026), pero según la página llega en uno de tres formatos:
    • Listado de contenido en Figma — el mejor caso: doce secciones con su título, su contenido y el «Formato» que pide cada una, como texto literal. No hay que interpretar nada.
    • Wireframe en Lovable — un prototipo aparte (sek-gutenberg.vercel.app cuando lo publican ahí), de referencia visual.
    • Wireframe hecho con Claude — captura o enlace de una maqueta generada por Claude, mismo tratamiento que un wireframe.
    Sea cual sea el formato, se busca siempre el homólogo más cercano ya publicado en staging — no se escribe HTML a partir del wireframe directamente.
  3. Se monta a partir de los bloques reales de staging, no escribiendo HTML: se descarga el bloque ya publicado y se le sustituye el contenido. Así la paridad con el theme es 1:1 por construcción y dev no tiene que adivinar nada.
  4. Se revisa mirando, no leyendo código: se abre la página y se compara con el wireframe.
La regla que más disgustos ha evitado: cuando el wireframe describe algo pero no lo aporta —un testimonio, unas cifras, una foto real— no se inventa. Se monta la estructura con el hueco marcado como pendiente y se anota en Para UX. Un dato inventado que llega a producción es mucho peor que un hueco visible.

Imágenes

Las fotos de las maquetas son placeholder, sacadas de Pexels por API para que la página se lea con una imagen real en vez de un rectángulo gris — no son fotos de SEK. Antes de publicar hay que sustituirlas por el material fotográfico definitivo y original del cliente. Sirven para validar composición, recorte y ritmo de la página, no como contenido final.

Las imágenes originales de SEK están en esta carpeta de Drive. Cuando exista foto real de la sección que se está montando, se usa esa — el placeholder de Pexels es el último recurso, no la opción por defecto.

Dónde vive todo

QuéDónde
El repositorioBitbucket · pixeldivisiondev/sek-gutenberg
En el ordenador~/Documents/Gut Projects/SEK 2026/dev/sek-gutenberg
Donde se trabajaui/guille/ — una carpeta dev-<página>/ por maqueta
Lo que coge devui/output/ — solo lo revisado
Los wireframes de UXux/output/ en el repo, y el Figma [SEK] Library 2026
El theme de WordPressLa raíz del repo — no se toca

Nuestra rama es ui/guille, y de ahí se sube a ui/main. Solo se toca la carpeta ui/: ni ux/ ni el theme.

Cómo se monta una maqueta

Cada página tiene dos ficheros dentro de su carpeta dev-<nombre>/:

Y un solo comando lo hace todo:

node compilar.mjs

Compila las 12 páginas, comprueba que cumplen los criterios, publica en ui/output las revisadas y regenera estas pestañas. Si algo incumple un criterio, no publica: avisa y para.

Por qué las 12 páginas se parecen entre sí

Esto es lo más importante que hay que entender del proyecto, porque cambia cómo se trabaja.

Al principio, cada criterio de diseño se arreglaba en la página que se estaba mirando. Resultado: la siguiente nacía con el mismo fallo y la revisión repetía el mismo comentario una y otra vez.

Ahora cada acuerdo es una comprobación automática. Hay 27 reglas que se pasan a todas las páginas en cada compilación —que los enlaces vayan en negro, que la tinta se lea sobre su fondo, que los iconos tengan un solo grosor, que el espaciado salga de un token…—. La lista completa, con el motivo de cada una, está en Para dev.

De ahí sale la regla de oro: un arreglo nunca se hace en la página que se está mirando, sino en la librería común, donde llega a todas. Si te ves editando el build.mjs de una página para corregir algo de estilo, casi seguro que estás en el sitio equivocado.

Las tres pestañas

PestañaPara quiénQué hay
PáginasTodosLas 12 maquetas por sprint
Para devGabriela y EduardoLo que está roto en staging, lo que corregimos nosotros y los criterios a mantener al migrar
Para UXCarla e IreneLos 41 puntos pendientes, cada uno con enlace a la sección donde se ve y al wireframe de Figma

Las tres se generan solas al compilar. No se editan a mano: se escriben en ui/output/registro-dev.md y ui/context/registro-ux.md, que son la fuente.

Si algo se atasca