Caso de estudio · 2026—presente
Corner Coach — el sistema detrás de la app
Construí un pequeño sistema de diseño para Corner Coach, una app de entrenamiento de boxeo para iOS. Me ayudó a pasar de pantallas sueltas a un producto coherente que se podía construir y mantener en SwiftUI. 93 tokens, 30 componentes y las pantallas que crean.
01 · El objetivo del sistema de diseño
Corner Coach es una app de entrenamiento de boxeo construida en torno a rounds, movimientos y un temporizador que tiene que funcionar con el teléfono apoyado en el suelo del gimnasio.
La diseño y la construyo sin ayuda, así que cada pantalla podría convertirse fácilmente en un nuevo conjunto de decisiones. Sin un sistema aparecen enseguida pequeñas diferencias: una tarjeta es un poco distinta de otra, los botones se comportan de forma inconsistente y la implementación se vuelve un proceso de adivinanza.
El objetivo no era crear una gran biblioteca de diseño. Era construir un sistema acotado que una sola persona pudiera terminar y mantener coherente.
Tenía que ser:
- primero iOS y solo oscuro
- basado en tokens semánticos en lugar de valores en bruto
- explícito sobre los estados de interacción
- lo bastante pequeño para sostener el MVP
- útil tanto en Figma como en SwiftUI
Hoy, el sistema incluye 93 tokens públicos, 24 primitivos privados, 30 componentes, 76 íconos y los cimientos de una biblioteca de 409 movimientos de boxeo.
02 · Principios
Los principios viven en el propio archivo de Figma. Están escritos para quien trabaje con el sistema después: yo, un desarrollador, un agente de código con IA u otro diseñador.
Construir en capas
Los primitivos privados definen los valores en bruto. Los tokens semánticos les dan significado. Los componentes los aplican de forma consistente. Las pantallas se construyen a partir de esos componentes en lugar de redibujarse desde cero.
Compartir un valor no siempre es compartir un significado
Varios tokens usan hoy el mismo valor ámbar, entre ellos action/primary, action/selected, focus-ring y chart/bar.
Siguen siendo tokens separados porque describen trabajos distintos. Un botón primario es una acción. Una tarjeta seleccionada es una elección. Un anillo de foco muestra atención. Una barra de gráfico representa datos.
Si el valor cambia más adelante, puede que esos roles necesiten cambiar de forma independiente.
Los tokens que comparten un valor no son intercambiables.
Diseñar para iOS
El sistema define estados de presionado y seleccionado porque son estados reales del producto en un teléfono. No incluye hover porque no forma parte de la experiencia del producto.
La elevación pertenece a superficies como tarjetas, hojas y superposiciones. Los controles no reciben sombras solo para parecer más importantes.
Mantener honesto al producto
- El contenido debe reorganizarse según los tamaños de texto y los anchos de pantalla.
- Las etiquetas y la estructura deben apoyar al color, nunca reemplazarlo.
- Hay que preservar las áreas táctiles y las áreas seguras.
- Reduce Motion debe tener una alternativa más calmada.
- Los estados del entrenamiento como trabajo, descanso, calentamiento, pausa y completado deben ser explícitos.
03 · Tokens
Cada token se crea en Figma y se exporta al proyecto. Nada se copia a mano de una herramienta a otra.
El sistema incluye:
- 43 colores semánticos para superficies, texto, íconos, bordes, acciones, retroalimentación, fases y gráficos
- 24 dimensiones que abarcan espaciado, radios y valores de layout
- 15 estilos de texto en Archivo, Sora y Barlow Condensed
- Tokens de movimiento y elevación para tiempos, curvas, sombras y degradados
Espaciado con significado
La escala de espaciado es semántica y no arbitraria.
space/5 se usa para contenido apilado. space/6 se usa para los márgenes de pantalla y el espacio entre tarjetas. space/7 se usa dentro de tarjetas más grandes.
Elegir un token de espaciado es elegir una relación entre elementos, no solo seleccionar un número.
Tres tipografías, tres trabajos
Archivo se encarga de los títulos y del texto de display. Sora se usa para el cuerpo de texto y las etiquetas. Barlow Condensed se reserva para temporizadores, contadores y valores numéricos grandes.
Un temporizador y una instrucción no cumplen la misma función, así que no necesitan usar la misma tipografía.
Tokens para el boxeo
El sistema también incluye tokens específicos de la experiencia de entrenamiento.
Calentamiento, trabajo y descanso tienen cada uno su propio acento y tinte. Los mismos tokens se usan en insignias, contadores y pantallas de entrenamiento en vivo, de modo que la fase actual se comunica siempre igual.
surface/card y text/secondary, en lugar de nombrar valores de color en bruto.04 · Componentes
El sistema incluye 30 componentes, de los cuales 29 están implementados actualmente.
Cada componente tiene en Figma una descripción que explica para qué sirve y cuándo conviene usar otra cosa. Eso hace la biblioteca más fácil de usar tanto para personas como para código.
Esto importa porque un agente de código puede conocer cada color del sistema y aun así crear un botón nuevo desde cero. El objetivo es que los componentes disponibles queden tan claros como los tokens disponibles.
Componentes principales
- Botón
CornerButtonStyle— seis tonos, tres tamaños, formas con ícono y formas solo con ícono.- Tarjeta
- Una familia de tarjetas de navegación, seleccionables, de configuración y compuestas.
- Chip
CornerChip— controles seleccionables para filtros, periodos y opciones de selección múltiple.- Control segmentado
CornerSegmentedControl— para dos o tres opciones visibles.- Gráfico de barras
CornerBarChart— para mostrar un valor por periodo.
Botones
Los botones son donde confluyen muchas decisiones del sistema.
El sistema define botones primario, secundario, ghost, de peligro, alternativo y punteado. Cada tono tiene estados por defecto, presionado, deshabilitado, cargando y con foco.
Algunas reglas son específicas del producto:
- El botón alternativo usa el acento de la fase de trabajo porque inicia o reanuda un round activo.
- El botón punteado representa un espacio vacío o disponible, no una acción secundaria.
- Los botones solo con ícono se dimensionan por separado porque cambian su relleno y su forma.
- Los botones no usan sombras. La elevación pertenece a las superficies.
Un componente no está terminado cuando se dibuja. Está terminado cuando sus estados están decididos.
Tarjetas
El componente Card original evolucionó en cuatro familias de comportamiento:
- Navegación — abre otra pantalla
- Seleccionable — representa una elección
- Configuración — controla un valor como los rounds o los ajustes del temporizador
- Compuesta — contiene contenido y acciones anidadas
La misma base se comparte entre las familias, pero cada una tiene solo los estados que realmente necesita.
Esto evita que el sistema cree combinaciones sin sentido, como una tarjeta de navegación expandida o una tarjeta de enlace seleccionada.
05 · Pantallas reales
No son maquetas. Son capturas de Corner Coach corriendo en un simulador de iPhone.
Home, la biblioteca de entrenamientos y el progreso de entrenamiento cumplen funciones distintas, pero están construidos con el mismo sistema.
Home
La pantalla Home usa tarjetas, insignias y un botón primario para ayudar a empezar un entrenamiento rápidamente.
Entrenamientos creados por el coach
La biblioteca de entrenamientos combina búsqueda, menús desplegables, chips y tarjetas de navegación para ayudar a encontrar una sesión.
Progreso
La pantalla Progress usa chips, un gráfico de barras, tarjetas de estadísticas y tarjetas de apoyo para mostrar el historial de entrenamiento.
Cada pantalla es una combinación de piezas existentes, no una colección de nuevas decisiones visuales.
Un componente, distintas funciones
El mismo componente chip se usa en varios contextos:
- Un control de periodo de selección única en Progress
- Un filtro de selección múltiple en la biblioteca de entrenamientos
- Un selector de equipamiento en la pantalla Profile
El componente se mantiene consistente mientras la pantalla define el comportamiento específico.
El contenido puede cambiar bajo un componente
Una tarjeta puede contener contenido distinto sin necesitar una variante aparte para cada situación.
Por ejemplo, la misma estructura de tarjeta puede admitir tanto un estado con datos como un estado vacío. El cuerpo cambia, pero el sistema que lo rodea sigue siendo familiar.
06 · De Figma a un producto iOS funcionando
El sistema no solo está documentado en Figma. Compila dentro de la app.
El flujo es:
- Variables, estilos, componentes y descripciones de Figma
- Un plugin de exportación que produce datos de tokens
- Un compilador de Swift que crea tokens, assets y mapeos de componentes
- Pantallas SwiftUI construidas a partir de componentes con nombre
- Verificaciones automáticas que detectan inconsistencias
Las verificaciones buscan problemas como colores en bruto, números mágicos, fuentes incorrectas y efectos no admitidos.
Los tipos de Swift también dificultan crear combinaciones inválidas. Una fuente ausente se verifica por separado porque un código válido todavía puede renderizarse con la tipografía equivocada.
La cadena de herramientas es deliberadamente pequeña: Swift, Foundation, SwiftUI y un plugin de Figma. Un proyecto en solitario necesita un sistema que sea útil sin convertirse en otro producto que mantener.
Cómo funcionan las verificaciones, y qué afirman y qué no, es un trabajo en sí mismo: un sistema de diseño que compila.
El sistema no es prueba de que la IA escribió buen código. Es una forma de evitar que el código incorrecto pase en silencio por terminado.
La experiencia de entrenamiento individual funciona hoy en el dispositivo, incluidos onboarding, creación de entrenamientos, sesiones en vivo, progreso, compartir, audio y háptica. La experiencia de coach a atleta está especificada, pero todavía no construida.
07 · Resultados y reflexión
El sistema se construyó para un solo producto, así que su valor se ve mejor en el producto mismo.
- Las pantallas se arman con piezas conocidas en lugar de redibujarse.
- Las nuevas decisiones de diseño son más fáciles de revisar.
- Los estados de interacción se definen una vez y se reutilizan.
- Diseño y código comparten el mismo vocabulario.
- El MVP tiene una base estable para el trabajo futuro.
Lo que el sistema todavía debe
El sistema no está terminado, y eso también está documentado.
El trabajo pendiente incluye:
- Reemplazar algunas asignaciones de tokens incorrectas o demasiado amplias
- Agregar un estado deshabilitado al control segmentado
- Alinear algunos componentes con la escala de tamaños publicada
- Mejorar el manejo de sombras internas en SwiftUI
- Pasar Dynamic Type y VoiceOver de principios documentados a comportamiento verificado
- Ampliar la documentación para que otra persona diseñadora pudiera usar el sistema sin pedir ayuda
El sistema se diseñó a propósito para las necesidades del MVP. Su próxima etapa se centrará en la validación de accesibilidad, un contenido más flexible y documentación para futuros colaboradores.
El producto pone a prueba si el sistema es útil. El sistema pone a prueba si el producto estaba realmente decidido.