Cómo trabajo

Una nota sobre el papel, antes de los métodos

Cada proyecto que he lanzado empezó en papel. Hay algo mágico en rascar un bolígrafo sobre una hoja y dibujar letras que me ayuda a desdibujar lo que está a punto de crearse y conectar con la materia de un modo más profundo del que puedo lograr en una pantalla.

Mirar Figma o preguntarle a mi agente de turno es una forma nueva de hacer esto, útil a su manera, pero el contacto con el papel y la sensación de tener el control no se sustituyen. Veinte años después, la primera hora de cualquier proyecto sigue siendo boli sobre papel: las preguntas que quiero contestar, las personas para las que creo que estoy diseñando, la forma de lo que estoy a punto de construir. La pantalla viene después.

Lo menciono porque el resto de esta página va sobre métodos y herramientas, y los métodos sin ese paso previo de pensamiento privado son solo frameworks disfrazados de trabajo.

1. Diagnosticar el negocio y el sistema de producto

Antes de los píxeles, la pregunta es qué comportamiento importa. El primer mes de cualquier engagement lo paso escuchando — al CEO, a ingeniería, a los tickets de soporte, a los usuarios cuando los consigo — y anoto lo que oigo en lenguaje llano. Para la semana cuatro suelo tener un diagnóstico de una página: qué funciona, qué está bloqueado, dónde tiene más palanca el diseño y qué debería pasar después.

El output no es un deck de recomendación. Es un mapa compartido. Un equipo que está de acuerdo en el diagnóstico puede no estar de acuerdo en la solución y seguir avanzando. Un equipo que no se ha alineado en el diagnóstico discutirá sobre la solución eternamente.

Aquí también descubro qué no hacer. Esa parte sale de dos sitios — pensamiento profundo en solitario, normalmente en papel, y contraste con el equipo. Restar scope es más difícil que sumarlo; la mayoría de equipos a los que me he unido tenían un roadmap lleno de cosas que nadie podía decir honestamente que pertenecieran.

El ejemplo más antiguo del que estoy orgulloso es el rediseño del cashier en GVC — dos talleres en Tarifa con el equipo cross-brand, un diagnóstico compartido de que el cuello de botella real era la tasa de fallo del primer depósito, y un rediseño que acabó moviendo 4x el valor medio de depósito en quince marcas sin que nadie tocara el presupuesto de marketing.

2. Dar forma a la cosa más pequeña que nos enseñe algo

Las apuestas grandes salen más baratas cuando la primera iteración se gana el derecho a la siguiente. Trato cada build temprano como un test deliberado de una asunción, no como una entrega.

El método con nombre propio que uso aquí es el diseño guiado por hipótesis — afirmaciones de cuatro líneas (Creemos que… Para… Vamos a… Sabremos que es cierto cuando…) que convierten asunciones en afirmaciones contrastables sobre las que un equipo multidisciplinar puede discutir de forma productiva. Aprendí la disciplina a las malas en Fretello, la apliqué durante la reconstrucción del motor de contribuciones de SellerCrowd, y sigue haciendo casi todo el trabajo pesado en el día uno de cada engagement nuevo. El caso de estudio completo cubre el método, las condiciones donde validaría cuantitativa o cualitativamente, y un ejemplo trabajado del prompt de notificaciones iOS de Fretello.

La forma de cuatro líneas importa porque fuerza un compromiso. “Creemos que X” es más difícil de esquivar que “deberíamos pensar en X”. Cuando la apuesta falla, las cuatro líneas son también el post-mortem más limpio que puedes hacer: ¿qué línea estaba mal?

3. Diseñar el sistema, no solo la pantalla

Bucles, incentivos, pricing, comunidad, datos: la pantalla es el extremo visible del sistema. Si el sistema está roto, ningún oficio de píxel va a arreglar el producto. Si el sistema funciona, hasta una pantalla rugosa puede sostener la experiencia.

SellerCrowd es el engagement donde este principio hizo el trabajo más visible. Cuando me incorporé, la comunidad estaba plana — las contribuciones se habían estancado y el instinto estándar de producto era “rediseñar el formulario de contribución”. La palanca real era el sistema alrededor del formulario: a quién se reconoce, cuándo, por qué; cómo el reconocimiento compone status; cómo el status alimenta más contribuciones. Cinco años después, el motor de contribuciones mueve 65x el volumen mensual (360 → 23.770) y 3x el MRR (111K$ → 356K$) con plantilla plana.

Aquí también es donde más empujo de vuelta cuando un stakeholder pide un “rediseño”. A menudo la pantalla está bien. El sistema a su alrededor, no.

4. Prototipar rápido con IA

Claude Code, prompt specs, eval loops. Lanzar producto se ha convertido en una nueva forma de pensar. El coste de averiguar si una idea es buena se ha desplomado.

El portfolio que estás leyendo es en sí mismo un ejemplo trabajado. Construyendo en 2026 recorre las ocho semanas de tardes-noches que lanzaron esta web, el chatbot con mi voz, el cualificador que puntúa cada conversación y el digest que me envía por email solo los leads que merecen mi tiempo. Dos tercios del trabajo fueron decidir qué lanzar, no cómo lanzarlo. El cuello de botella nunca fue el código.

Lo que esto cambia en el modelo operativo: prototipar ya no es una fase aparte reservada a las cosas que ingeniería se puede permitir spike-ar. Es una herramienta a la que recurro dentro de conversaciones de diseño, a mitad de reunión. “¿Y si tuviese esta pinta?” se contesta ahora en veinte minutos, no en tres sprints.

Lo que no cambia: el criterio sobre cuál prototipo construir. Eso sigue siendo trabajo del IC sénior. Los modelos son rápidos y literales; necesitan a alguien en la sala que sepa qué intenta aprender el equipo de verdad.

5. Lanzar, medir, ajustar

El trabajo no se acaba cuando es bonito. Se acaba cuando los números se mueven.

El método con nombre propio en el que me apoyo aquí es SUM, la métrica de usabilidad única — una manera de comparar dos diseños sobre una sola puntuación estandarizada que combina finalización de tarea, tiempo en tarea y satisfacción. Evidencia objetiva barata, rápida, que no depende de instrumentación de ingeniería. El caso de estudio completo recorre cómo lo usé en Fretello a principios de 2019 para elegir entre dos conceptos del Learn Path (The Path vs The Birdseye), y el diseño combinado que acabó lanzándose a producción.

SUM es una herramienta dentro de un hábito más amplio: lanza la cosa, mira la métrica y prepárate para revertir. La versión de cualquier producto que he lanzado y de la que estoy más orgulloso rara vez es la primera versión que dibujé. Suele ser la segunda o la tercera, después de que la primera me contara algo que no me esperaba.

Una nota sobre workshops

Hago muchos workshops. Son cómo diagnostico, cómo doy forma y cómo cierro la alineación del equipo en lo que toca hacer a continuación. El objetivo del workshop, cada vez, es acabar con compromisos — no con alineamientos vagos, ni con un deck bonito, ni con un “esto merece una segunda vuelta”.

Mi libro favorito sobre el tema es Gamestorming. Estaba ahí antes que Design Sprints y seguirá ahí después de Design Sprints — la referencia canónica para facilitadores que quieren diseñar su propia estructura para su propio problema. Tomo prestados algunos ejercicios del canon de Sprint cuando encajan, pero casi nunca corro un Sprint a libro cerrado. El workshop correcto es el que diseño a medida para el equipo que tengo en la sala, usando las recetas de Gamestorming como bloques de construcción.

El movimiento de facilitación más útil que conozco es nivelar voces. Desbloquear un equipo es a menudo tan simple como dar a todos el mismo tiempo para hablar. Eso significa controlar las voces fuertes — la persona más sénior, la más opinada, la más extrovertida — y darle a las más calladas espacio para compartir lo que están pensando antes de que alguien reaccione. La primera vez que haces esto en un equipo acostumbrado a que una persona domine, el cambio de energía es inconfundible. Personas que no habían hablado en tres semanas producen de pronto la observación más útil de la sesión.

Los talleres de Tarifa en GVC, el workshop del Learn Path en Barcelona con Fretello y los workshops del motor de contribuciones en SellerCrowd se construyeron todos así: una estructura a medida, ejercicios derivados de Gamestorming y un nivelado de voces sin contemplaciones. Los tres produjeron compromisos que el equipo mantuvo.