AgencyHub
Un marketplace donde quien compra no es quien paga. Product design de principio a fin: research, flujos, arquitectura de información, UI y sistema de componentes. Diseñador único.
- 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.
Muchas veces la agencia no puede pagar hasta que le paga su propio cliente. Y ese cliente no tiene cuenta ni entra nunca en la plataforma, pero pone el dinero, define los requisitos y valora el resultado.
| Actor | Entra en la app | Qué hace |
|---|---|---|
| Proveedor | Sí | Publica, entrega, cobra |
| Agencia | Sí | Compra, define el precio, revende |
| Cliente final | No | Paga, define requisitos, aprueba |
Cada pantalla tenía que responder una sola pregunta: ¿qué pasa cuando quien paga no es quien mira?
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.
Decisión
El checkout tiene dos finales, no tres métodos de pago.
Un checkout da por hecho que quien compra paga. Aquí la agencia muchas veces necesita que pague antes su cliente, así que tres métodos de pago al mismo nivel nunca encajaron: el payment link no paga nada y crea el estado waiting for client, y el saldo no es un método, es un descuento.
El diseño final tiene dos desenlaces, Pay now y Ask your client to pay, con el saldo como casilla que se resta del total. El botón cambia según el desenlace: Pay $250.00 o Create & Send Payment Link.
Decisión
Cada parte ve su propio precio.
La agencia necesita márgenes que pueda defender. El proveedor necesita que su precio no se infle hasta romper las expectativas del cliente. La transparencia total suena honesta, pero convierte a la agencia en un intermediario con el recargo a la vista.
El proveedor nunca ve el precio del cliente. El cliente nunca ve el coste del proveedor. La plataforma ve ambos, y por eso puede arbitrar una disputa.
El margen vive dentro del checkout: un campo Client price que calcula el beneficio en vivo, "Your cost $400.00 · You earn $200.00", más un margen por defecto en ajustes para no decidirlo desde cero en cada pedido.
Decisión
Un carrito, un cliente.
Si el carrito mezclara SEO para el cliente A con PPC para el B, el payment link se quedaría sin destinatario: un enlace, un pagador. Por eso el carrito se limita a un cliente, elegido al principio y visible en todo momento.
Comprar para tres clientes son tres pedidos: una fricción asumible, porque enviar un enlace de pago a la persona equivocada no se puede deshacer.
Decisión
Una sala, dos identidades.
La comunicación vive en un espacio anclado al pedido. Con tres actores, la pregunta es si el cliente llega a ver al proveedor. Sí, pero como parte del equipo de la agencia: la plataforma no lo esconde, lo reetiqueta.
La agencia se juega la relación con su cliente en ese reetiquetado, así que puede previsualizar la conversación tal y como la ve su cliente antes de escribir nada delicado.
La prueba
La pantalla que lo demuestra todo.
Esto es lo que ve el cliente de la agencia al abrir el enlace: sin cuenta, sin sesión y sin saber qué es AgencyHub.
- Manda la marca de la agencia. Sin navegación ni logo de la plataforma; AgencyHub aparece solo en la letra pequeña del pago, como procesador.
- 600 dólares y ni rastro de los 400. Sin proveedor, sin coste, sin margen.
- "After payment we'll ask a few questions" convierte el silencio en una expectativa para un cliente que no tiene panel donde mirar.
- La fecha de caducidad está a la vista, la misma que eligió la agencia.
Un enlace caducado no es un callejón sin salida: Request a new link avisa a la agencia dentro de la plataforma, en lugar de empujar la conversación al email, donde la plataforma no puede arbitrar.
Estados
Los estados antes que los happy paths.
En un producto donde el pago puede no llegar nunca, los estados son el producto:
waiting for client: comprado, sin pagar, el proveedor no puede empezar- Payment link caducado sin pago
- Carrito sin cliente asignado, con el checkout bloqueado y el motivo explicado
- Cambio de cliente con el carrito lleno
- Servicios del proveedor en borrador, pendientes, publicados y rechazados, con el motivo del rechazo y cómo corregirlo
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 · EE. UU.