AgencyHub
Un marketplace de dos lados donde las agencias compran servicios white-label a proveedores verificados. Esta versión del caso recorre cómo trabajo realmente: las preguntas que hago, el orden en que las hago y los artefactos que produjo cada una.
- Rol
- Diseñador UX/UI
- Periodo
- 2020 - 2024
- Alcance
- Marketplace, checkout, pedidos y herramientas para proveedores
El Desafío
Las agencias crecen diciendo que sí — y cada sí es un riesgo que absorben solas.
Las agencias digitales crecen diciendo que sí. Cuando un cliente pide SEO y la agencia solo hace ads, la agencia tiene tres opciones: contratar, rechazar o buscar un socio white-label. La mayoría elige socios, y la mayoría los encuentra a base de prueba y error. Cada colaboración fallida cuesta dinero dos veces: lo que se gasta de más y el cliente que se va.
La apuesta de AgencyHub era que la verificación podía ser una función del producto en lugar de una lucha en privado. Para que eso funcionara, el producto tenía que servir a dos partes con necesidades opuestas: los proveedores quieren publicar rápido; las agencias quieren fiarse de lo que encuentran.
La confianza es el producto
Toda la propuesta de valor es que las agencias dejen de verificar proveedores por su cuenta. Cada decisión de catálogo y de publicación tenía que defender esa promesa, incluso a costa del crecimiento.
Tres actores, una transacción
El pago puede venir de alguien que no es el comprador y que nunca inicia sesión. Los pedidos, las notificaciones y el checkout heredan esa complejidad.
Un solo diseñador, todo el producto
El marketplace, el carrito, los pedidos y las herramientas del proveedor tenían que salir juntos. Un sistema de componentes compartido no era una preferencia: era la única manera de llegar.
Why — ¿qué problema estamos resolviendo?
Antes de dibujar nada: ¿este producto merece existir?
Cada proyecto empieza con la misma disciplina: escribir el problema hasta que deja de ser vago. Si el planteamiento no puede nombrar quién pierde dinero y por qué, el diseño que sigue es decoración.
Who — ¿para quién diseñamos?
Dos usuarios con incentivos opuestos, y un tercero que nunca inicia sesión.
Las user personas aquí no fueron una formalidad. La agencia y el proveedor quieren cosas contradictorias del mismo catálogo — rapidez para publicar frente a confianza en lo publicado. Poner nombre a esa tensión desde el principio fue lo que permitió tomar las decisiones difíciles que vinieron después.
Reframe — ¿cómo podríamos hacer de la confianza una funcionalidad?
Convertir el desafío en preguntas contra las que el equipo pudiera diseñar.
Las notas de How Might We convierten quejas en briefs de diseño. Las útiles no son las obvias: '¿cómo podríamos hacer de la verificación una funcionalidad de la plataforma?' convirtió la confianza de un coste de soporte en el núcleo del producto.
When & Where — ¿por dónde se mueve realmente el dinero?
Mapear el recorrido expuso el flujo que nadie había contemplado.
Recorrer ambos lados de la transacción de punta a punta reveló el problema de diseño que definió todo lo demás: la agencia compra, pero su cliente muchas veces paga. El user flow hizo visible ese desvío antes de que existiera una sola pantalla.
What — ¿por qué no basta un marketplace existente?
Estudiar lo que existe antes de decidir qué construir.
Los lightning demos son la investigación más rentable que existe: una hora mirando cómo Fiverr, Upwork y otros marketplaces resuelven la publicación, la confianza y el checkout — y ser honesto sobre por qué ninguno funciona cuando el comprador revende.
Solve — ¿cuál es el mínimo de pantallas que sostiene el trabajo?
Primero papel. La fidelidad se gana, no se asume.
Bocetar rápido es la forma más barata de descartar malas ideas. El marketplace, el carrito y el checkout se dibujaron en papel, se discutieron, y solo las mejores ideas pasaron a wireframes de alta fidelidad.
El Sistema
Un solo sistema para todo el producto.
El marketplace, el carrito, los pedidos y la tienda del proveedor comparten una misma librería de componentes y las mismas reglas de layout. Siendo el único diseñador, no era una cuestión estética: era la única manera de que las cuatro áreas del producto salieran con un diseño consistente.
Esa misma librería resolvió también los casos especiales del producto —un pedido esperando a que pague el cliente, un servicio pendiente de aprobación— sin tener que diseñar componentes nuevos para cada situación.
How — ¿cómo sabemos que funcionó?
Un diseño no está terminado cuando se lanza. Está terminado cuando se mide.
La versión honesta: me fui antes de que las métricas maduraran, así que esta sección no reclama nada que no pueda respaldar. Muestra lo que se lanzó y el plan de instrumentación que usaría para juzgarlo.
El diseño hizo posible un comportamiento nuevo: una agencia puede vender un servicio que no presta, con el pago, los requisitos y la entrega gestionados por la plataforma en lugar de hojas de cálculo y correos.
La verificación pasó de ser una lucha privada de cada agencia a una funcionalidad de la plataforma. El control de aprobación es la promesa de confianza del producto, garantizada por diseño.
Las cuatro áreas del producto se lanzaron a partir de una sola librería de componentes, diseñada por una sola persona.
Qué mediría a continuación
Si continuara este trabajo, instrumentaría las dos decisiones más arriesgadas: cuántos checkouts terminan en un enlace de pago, que muestra si el flujo del tercero es demanda real, y cuánto tarda la aprobación de proveedores, porque la confianza solo es una funcionalidad si no estrangula la oferta.
El Framework
Las preguntas que llevo a cada proyecto.
Este proceso no es específico de AgencyHub. Es una secuencia de preguntas que aplico a cualquier problema de producto — porque un proceso repetible es lo que hace transferible el criterio de diseño entre proyectos.
Por qué
Entender el objetivo.
- ¿Qué problema estamos intentando resolver?
- ¿Cómo beneficia este producto a los clientes?
- ¿Qué oportunidad de negocio crea?
Quién
Definir a la audiencia.
- ¿Qué grupos tienen motivaciones muy distintas para usarlo?
- ¿Cuáles son sus puntos de dolor y sus emociones?
- ¿Cuál es su motivación de fondo para resolver el problema?
Cuándo y dónde
Mapear el contexto de uso.
- ¿En qué momento del día del usuario aparece el producto?
- ¿Qué tiene que ser cierto justo antes y justo después de cada interacción?
Qué
Listar y priorizar ideas.
- ¿Qué podríamos construir para cubrir las necesidades del cliente?
- ¿Qué existe ya y por qué no es suficiente?
- ¿Qué idea tiene la mejor relación entre esfuerzo e impacto?
Resolver
Hacerlo concreto.
- ¿Qué tareas debe completar el cliente para tener éxito?
- ¿Qué enseñan cuatro bocetos rápidos antes de la alta fidelidad?
Cómo
Medir el éxito.
- ¿Cómo sabríamos que la solución funcionó?
- ¿Qué métrica expondría primero la suposición más arriesgada?
Siguiente proyecto
InstallPros