Diseño
Investigación, diseño de producto y código escrito en tu repo.
La persona que lo usa, el negocio al que tiene que servir, y el tiempo y el dinero que hay. Resolver cómo encajan esas tres cosas es el trabajo de diseño.
Qué hacemos
Seis formas que suele tomar este trabajo. La mayoría de los proyectos son varias de ellas.
Investigación con la gente involucrada
Entrevistas y análisis de flujos con los roles que lo van a usar, y con los que deciden qué tiene que hacer.
Prototipos que prueban un concepto
Con la fidelidad suficiente para ponerlos delante de alguien y aprender si se sostienen, antes de que sean un desarrollo.
Diseño de producto e interfaz
Navegación, estructura y sistema visual de la cosa en sí, pantalla por pantalla y estado por estado.
Diseño en el código
Pantallas y componentes construidos en el repositorio en el que trabajan tus desarrolladores, con cada estado definido en vez de descrito.
Trabajo de accesibilidad
Auditorías contra WCAG, e interfaces diseñadas para ella desde el primer sprint en vez de corregidas después.
Design systems
Librerías de componentes construidas en código, para que lo que se diseñó sea lo que sale y siga saliendo.
Cuándo pasa el diseño
Tres momentos, y el trabajo es distinto en cada uno. La pregunta que conviene resolver temprano es en cuál de ellos estás.
- Antes de construir
Averiguar si debería existir
mEMR llegó con un concepto de producto liderado por médicos. Hicimos la investigación y construimos prototipos de alta fidelidad para probarlo antes de escribir una línea de código, aclarando los flujos clínicos y de paciente de los que dependía el producto.
- Durante el desarrollo
Hacer usable un modelo complicado
Teach to One Roadmap se adapta al recorrido de cada estudiante por la matemática de K-12. El modelo se había vuelto más fuerte y la experiencia no había seguido el ritmo: la navegación no era obvia, las opciones se habían multiplicado, y estudiantes y docentes no siempre podían saber en qué trabajar después ni por qué. Rediseñamos la navegación, el sistema visual y la forma en que se muestra el progreso.
- Después de salir
Mantenerlo consistente mientras crece
La plataforma de VisualVault atiende a clientes de educación, salud y sector público desde una sola librería de componentes construida en código. Las decisiones de diseño sobreviven porque viven donde se construye el producto, no en un archivo al costado.
Gobernada y documentada en Storybook, junto al equipo que publica el producto.
Diseñamos en el código
El equipo de diseño trabaja en el código sobre el que van a construir los desarrolladores, con herramientas de IA haciendo el tecleo. Lo que reciben los desarrolladores no es un archivo para interpretar: es la cosa en sí, en el repositorio, con los componentes ya nombrados. Eso cambia cinco cosas.
No hay paso de traducción donde perder cosas
La distancia entre lo que se diseñó y lo que salió es donde los productos pierden forma en silencio: una regla de espaciado que se cae acá, un estado improvisado allá, un componente bifurcado porque el original no terminaba de encajar. Trabajar en el código cierra esa distancia en vez de vigilarla. El líder de diseño decide qué componentes son canónicos y aprueba cada pantalla antes de que pase a construcción.
Estados, no pantallas
Una pantalla es un camino feliz. Un producto también está vacío, cargando, en error, sin permiso y sin conexión. Diseñamos esa matriz desde el principio, porque en código el estado que falta no es una omisión que descubres en QA. Es una rama que alguien tiene que escribir igual, y sale más barato decidirla que heredarla.
El texto de interfaz es parte del diseño
Un resultado que todavía se está procesando. Una receta que venció. Un valor que el sistema todavía no publicó. En productos que cargan información con consecuencias, esas frases deciden si alguien entiende su situación, así que se escriben con la pantalla y no se le agregan después.
Sabemos cuánto cuesta antes de que te comprometas
Una estimación desde afuera de un código es una adivinanza. Desde adentro no. Cuando una pantalla resulta cara de construir, eso se sabe mientras todavía es una decisión, no después de aprobada y metida en un sprint.
Y cuando lo construye tu equipo
Algunos clientes nos traen para las fases de diseño y construyen con sus propios desarrolladores. La salida es del mismo tipo: componentes y estados definidos donde tu equipo puede tomarlos, en vez de una especificación que tienen que volver a deducir.
Diseñar cuando una regla decide una parte
La accesibilidad, el cumplimiento clínico y el acceso por rol no son pasos de cierre. Cambian qué puede ser la interfaz, así que llegan al principio.
Una interfaz que alguien usa estando enfermo
El departamento de farmacia clínica de la Universidad de Michigan necesitaba medir marcha, equilibrio y coordinación de dedos en pacientes en quimioterapia. La app tenía que ser accesible y legible para alguien cansado, incómodo y sin supervisión, y las mediciones tenían que salir en una forma sobre la que un clínico pudiera actuar.
Diseñada para accesibilidad desde el primer sprint, en iOS con Apple ResearchKit y Medable.
Auditar lo que ya salió
Para TGI Fridays hicimos una auditoría de accesibilidad sobre las plataformas de pedidos y corporativa, mientras la misma arquitectura tenía que alojar varias marcas virtuales y ghost kitchens bajo una sola identidad. Una auditoría te dice qué arreglar y en qué orden. Arreglarlo es un trabajo aparte.
Contratada como proyecto propio, no como parte de un rediseño.
Cuando cada rol ve cosas distintas
En el BID, cada rol tiene su propia vista de los mismos datos de préstamo. Eso se decidió con los stakeholders antes de diseñar los indicadores, porque revertirlo después significa rediseñarlos.
Preguntas que nos hacen antes de la primera llamada
¿Y si el diseño no entra en nuestro plazo o presupuesto?
Entonces no está terminado. Cortar alcance temprano sale más barato que que lo corte después quien esté más cerca de la fecha, y es una decisión que te toca tomar en vez de heredar. Eso incluye decirte cuándo algo conviene comprarlo en vez de construirlo, y cuándo una propuesta es más grande de lo que el problema necesita.¿Pueden diseñarlo si lo construye otro?
Sí. Algunos clientes nos traen para las fases de diseño y construyen con sus propios desarrolladores, y es una forma normal de trabajar con nosotros. Lo que cambia es la entrega: en vez de una especificación que tu equipo tiene que volver a deducir, recibes componentes y estados definidos donde tus desarrolladores pueden tomarlos.Ya tenemos una marca. ¿Trabajan dentro de ella?
Sí, y es la única forma en que trabajamos. No tomamos proyectos de marca o identidad por su cuenta. Este trabajo arranca desde una identidad que ya existe y un producto que ya tiene usuarios, donde el trabajo es estructura, jerarquía y claridad, no un lenguaje visual nuevo.¿Hacen auditorías de accesibilidad por separado?
Sí. TGI Fridays contrató una como trabajo propio, aparte de un rediseño. Una auditoría te dice qué arreglar y en qué orden; no lo arregla, y las dos cosas suelen convenir cotizadas por separado.¿Y si la investigación dice que no deberíamos construirlo?
Entonces ése es el hallazgo, y es el más barato que vas a conseguir. mEMR probó un concepto de producto antes del desarrollo y no después, que es justamente el punto de hacerlo en ese orden.
Tráenos esa parte que nadie puede explicar en una pantalla.
En una sesión de trabajo de 45 minutos te decimos qué necesitaríamos entender primero, dónde están de verdad las decisiones de diseño, y si estás antes de construir, adentro o después. Trae la pantalla que tienes que explicar una y otra vez.