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.

Agenda una sesión de trabajoSee what we hand over

Qué hacemos

Seis formas que suele tomar este trabajo. La mayoría de los proyectos son varias de ellas.

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.

  1. 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.

    Es un proyecto más chico que un desarrollo, y el correcto cuando los flujos todavía no están resueltos.

  2. 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.

    La pedagogía no cambió. Lo que cambió es que se puede ver.

  3. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  1. 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.

  2. 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.

  3. 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.

    Entrevistas con stakeholders y análisis de flujos primero, y después validación iterativa a medida que se construía.

Preguntas que nos hacen antes de la primera llamada

  1. ¿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.

  2. ¿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.

  3. 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.

  4. ¿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.

  5. ¿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.

Agenda una sesión de trabajosales@onetree.com