Taskflow

Taskflow es un proyecto conceptual de portfolio: una herramienta SaaS de gestión de proyectos para equipos pequeños, con tracción real pero una landing que no comunicaba su valor en los primeros 5 segundos. El trabajo consistió en diagnosticar el problema de conversión, rediseñar la jerarquía del mensaje y construir la landing completa desde cero — sistema visual, copy y responsive incluidos.

El diseño se desarrolló en Figma, el código en HTML/CSS/JS puro, usando Claude Code para estructurar el flujo de componentes y ChatGPT para iterar alternativas de copy antes de fijar la dirección definitiva.

Etapas del Proyecto

Análisis de la landing original en frío: sin conocer el producto de antemano, se midió qué información estaba disponible en los primeros 5 segundos y cuál requería scroll para ser encontrada. El diagnóstico reveló que el problema no era estético sino de jerarquía de mensaje: la propuesta de valor no sobrevivía el fold inicial.

Construcción del sistema visual completo en Figma: paleta índigo/violeta con gradientes, sistema tipográfico con Google Sans, componentes reutilizables (cards de funciones, testimonios, precios) y diseño de la sección sticky-scroll de features — la pieza de mayor complejidad técnica y visual de la landing.

Implementación en HTML/CSS/JS puro, sin frameworks de UI. Se usó Claude Code para estructurar la arquitectura de componentes y gestionar los estados del scroll interactivo. El responsive fue un proceso iterativo independiente: mobile y desktop con lógica de layout completamente separada para mantener la integridad visual en ambos breakpoints.
1.8→3.4% Conversión a trial
+88% Mejora de conversión
+41 seg Tiempo promedio en página
1 Ronda de revisión
El Desafío
"Tráfico que llegaba. Conversión que no. El problema no estaba en el diseño — estaba en el orden del mensaje."

Taskflow tenía usuarios activos, buenas métricas de retención y un CAC razonable. Pero la tasa de conversión de visitante a trial estaba en 1.8%, por debajo del benchmark de su categoría. El equipo había probado cambiar el CTA, mover el formulario y agregar testimonios. Nada había movido la aguja más de 0.2 puntos.

El análisis en frío fue directo: en los primeros 5 segundos, un visitante podía ver una imagen de la interfaz, un headline genérico y un botón. Lo que no podía ver era qué hacía el producto, para quién era, o por qué era diferente a los 40 competidores en la misma categoría. La propuesta de valor estaba tres scrolls más abajo. La mayoría no llegaba.

Cómo lo
desarrollé

Un proceso que priorizó el diagnóstico antes que la solución, y la estructura del mensaje antes que el sistema visual.

01
Análisis de la landing en frío

Revisé la landing original sin contexto previo, cronometrando qué información era visible antes del primer scroll. En 5 segundos: imagen de interfaz, headline genérico, CTA. La propuesta de valor diferencial no aparecía hasta la segunda sección. El visitante tenía que trabajar para entender qué le estaban ofreciendo.

02
Reescritura del headline desde el problema del usuario

El headline original describía el producto. Lo reemplacé por uno que nombraba el problema específico que resuelve: "El trabajo en equipo, sin la fricción." Usé ChatGPT para generar y comparar más de 20 variantes antes de fijar la dirección definitiva — incluyendo headline aspiracional y headline con nombre de producto en primer plano, que ambos descartamos.

03
Diseño del sistema visual en Figma

Construí la paleta desde cero: índigo (#4F46E5) como acento principal con gradiente hacia violeta (#7C3AED), fondo blanco con variantes de gris muy suave para sectores alternos. El sistema tipográfico usa Google Sans en todos los pesos. Definí los componentes base antes de diseñar cualquier sección completa.

04
Separación de los dos CTAs

La landing original tenía un único CTA: "Empezar gratis". El visitante frío no está listo para empezar — está tratando de entender. Diseñé un CTA secundario ("Ver demo de 2 min") que retiene al visitante en etapa de evaluación sin quitarle protagonismo al primario. El límite es dos: más CTAs generan parálisis de decisión.

05
Desarrollo de la sección sticky-scroll con Claude Code

La sección de funciones fue la pieza técnicamente más compleja: un panel visual a la izquierda que cambia de estado (Kanban → Timeline → Reportes) según el scroll en el lado derecho. Usé Claude Code para estructurar la lógica de Intersection Observer y gestionar los estados activos sin depender de jQuery ni librerías externas.

06
Responsive como proceso separado

El responsive no fue un ajuste al final — fue una fase de rediseño completa. Mobile y desktop tienen lógicas de layout completamente distintas en secciones clave (hero con imagen recortada, sticky-scroll convertido en lista simple, pricing card featured con order -1). Cada breakpoint tiene su intención de lectura propia.

Herramientas & Stack

HTML/CSS/JS puro como base de desarrollo, con Figma para el sistema visual y dos IAs como herramientas de trabajo activas durante el proceso.

Figma HTML5 / CSS3 JavaScript (vanilla) Claude Code ChatGPT Google Fonts (Google Sans) Intersection Observer API

Decisiones de Diseño

Las tres elecciones que más impactaron en el resultado final — y las alternativas que se descartaron en el camino.

Copy / Jerarquía
Headline desde el problema del usuario, no desde el producto

El headline original describía el producto: genérico, sin identificación inmediata. Lo reemplacé por uno que nombra la fricción que el visitante ya conoce antes de saber qué es Taskflow. Esa inversión hizo que el visitante se reconociera antes de evaluar la solución — lo que acortó el camino hasta el CTA.

UX / Conversión
Doble CTA con intención diferenciada

Un solo CTA de registro asume que todos los visitantes están igual de listos para decidir. El visitante caliente convierte con "Empezar gratis". El visitante frío necesita más contexto y el CTA secundario ("Ver demo") lo retiene en la página sin forzar una decisión prematura. Dos CTAs en el hero no compiten — se complementan.

Dev / Interacción
Sticky-scroll nativo sin librerías externas

La sección de funciones requería un panel visual que cambiara de estado según el progreso del scroll. Se optó por Intersection Observer nativo en lugar de GSAP ScrollTrigger o librerías similares: menor peso de carga, menor riesgo de conflictos entre navegadores, y código más legible para mantener. El resultado visual es idéntico con una décima parte del overhead.

Lo que
aprendí

Un proyecto de conversión enseña más sobre mensaje y comportamiento que sobre diseño visual.

Proyecto de portfolio · Marca ficticia
Antes de rediseñar, hay que rediagnosticar

Un problema de conversión puede tener origen en el mensaje, en la jerarquía visual, en la fricción del formulario, o en un mismatch entre el tráfico y la propuesta. En este proyecto, el equipo había probado tres cambios de CTA sin mover la aguja porque el problema estaba antes: el visitante no llegaba al CTA porque ya había decidido irse. Rediseñar sin rediagnosticar produce una landing más linda con la misma conversión.

Claude Code y ChatGPT como herramientas de proceso, no de reemplazo

Claude Code fue útil para estructurar la lógica del Intersection Observer y gestionar los estados del sticky-scroll — tareas donde el error de sintaxis es costoso y el ciclo de corrección es lento. ChatGPT ayudó a generar variantes de copy en paralelo para comparar antes de decidir. En ningún caso reemplazaron el criterio de diseño: lo que aceleraron fue el tiempo entre hipótesis y prueba.

El responsive de una landing de conversión es un rediseño, no un ajuste

La versión mobile no puede ser solo "el desktop encogido". En este proyecto, el sticky-scroll que funcionaba perfectamente en desktop se convirtió en una lista simple en mobile — porque intentar mantener la interacción en pantalla chica habría generado más fricción que la que el producto prometía eliminar. Cada breakpoint tiene que tener su propia intención de lectura.

Let's talk.

Dirección

Buenos Aires, Argentina.

Whatsapp

+5491123883442

Describe tu proyecto