Cómo trabajar
Crear algo nuevo.
Siete pasos, desde el problema hasta el lanzamiento.
- Define el problema antes que la pantalla
- Responde: ¿qué problema resuelve?, ¿para quién?, ¿cómo lo resuelven hoy?, ¿qué sabes por evidencia y qué es un supuesto?
- Define si tiene un objetivo único (inscribirse, cotizar, pagar) o varios (un sitio institucional, una plataforma).
Listo para avanzar cuando el problema, el usuario y el objetivo están escritos, y los supuestos están marcados como tales.
Si pides o apruebas el proyecto: este paso es tuyo.
- Habla con usuarios o mira datos antes de diseñar
- Mínimo: 3 a 5 conversaciones cortas (unos 15 minutos) con usuarios reales, o una revisión de los datos que ya existen: analítica, soporte y reclamos.
- Una conversación de 15 minutos antes de diseñar cuesta menos que rehacer una pantalla después.
Listo para avanzar cuando hubo al menos un contacto real, y los supuestos del paso 1 se confirmaron o se ajustaron.
- Arma con Solar
- Parte por los componentes del catálogo.
- Si Solar ya tiene un componente, úsalo. No uses colores, tamaños ni espaciados fijos: usa los tokens.
- Si a Solar le falta algo, avísalo al equipo de Solar en vez de crear una variante propia.
Si construyes con IA: indícale los recursos de Solar y parte con el prompt «Antes de construir».
PatronesLandings de conversión y Login muestran páginas completas hechas con Solar. Ver PatronesPrototipo no es producciónTailwind por CDN sirve para maquetas y prototipos. Si lo que armaste se va a usar de verdad, pide a un desarrollador que lo pase a un build precompilado de Tailwind y que aloje en el proyecto las tipografías y los íconos antes de publicarlo. - Haz una revisión previa con IA
- Usa los prompts «Crítica de página» y «Accesibilidad».
- Corrige lo obvio. El reporte de la IA no es evidencia: no reemplaza la revisión de personas ni la prueba con usuarios.
- Guarda la lista de lo que la IA no puede evaluar sin usuarios: la vas a usar en los pasos 5 y 6.
- Muéstralo a otras personas
- Muestra el trabajo a colegas e indica qué partes requieren validación.
- Separa la crítica (explorar y mejorar) de la revisión (aprobar). No las mezcles en la misma reunión.
- Pide feedback específico, justificado y accionable.
- Valida con usuarios
- No basta con preguntar si lo pueden usar: pregunta también si les resuelve el problema.
- Técnicas ligeras: una prueba con 5 usuarios, sesiones cortas con personas parecidas a quienes lo van a usar, o un piloto con un grupo acotado.
- Un piloto muestra uso, no utilidad: compleméntalo con conversaciones.
Listo para avanzar cuando hay evidencia con usuarios (ver estados de evidencia). Si no fue posible conseguirla, la decisión queda marcada como supuesto a validar.
- Lanza, mide y vuelve
- Compara el uso real con los supuestos del paso 1.
- Lo que aprendas vuelve a Solar: avísalo al equipo de Solar para ajustar un componente o documentar un problema conocido.
Si construyes un aplicativo interno con IA
- Si maneja datos de personas o de la CCS, pide una revisión de seguridad a TI antes de usarlo.
- No cargues datos sensibles ni diseños no publicados en herramientas que la CCS no haya autorizado.
- Revisa lo que entrega la IA con el mismo rigor que el trabajo de alguien que recién empieza. No aceptes el primer resultado.