Cómo diseñar tablas de precios claras

Una tabla de precios útil permite responder a tres preguntas sin abrir una calculadora ni una segunda pestaña del navegador: ¿qué plan se adapta a mi trabajo?, ¿cuánto voy a pagar realmente? y ¿qué ocurrirá si lo elijo?

Parece sencillo hasta que incorporas al diseño los detalles reales del producto. Un plan incluye cinco editores, otro cobra por editor, la facturación anual se presenta como un equivalente mensual y la función que más importa queda enterrada bajo doce marcas de verificación idénticas. Las tarjetas pueden tener un acabado impecable y, aun así, seguir dificultando la decisión.

Los ejemplos desarrollados utilizan Fieldnote, un servicio de colaboración ficticio.

Define la elección antes de dibujar las tarjetas

Escribe en una frase qué decisión esperas que tome quien visita la página. Para Fieldnote, sería elegir un plan de espacio de trabajo para un investigador que trabaja solo, un pequeño equipo de proyecto o una organización que necesita administración centralizada.

Son necesidades operativas distintas. Ofrecen un punto de partida más útil que decidir que toda página de precios necesita tres columnas. Un producto con un único paquete de pago quizá necesite una explicación del precio en lugar de una comparación. Un servicio con productos separados quizá necesite primero un selector de producto. Colocar compras fundamentalmente distintas en columnas contiguas puede dar a entender que son intercambiables cuando no lo son.

Pregunta a la persona responsable del producto qué datos cambian realmente la elección. En nuestro ejemplo, importan los proyectos activos, los editores incluidos, el acceso de invitados y la administración. El almacenamiento también varía, pero es poco probable que determine la primera decisión del público al que se dirige la página. Esta distinción establece un orden: primero mostrar si el plan encaja y después presentar los detalles necesarios para comprobarlo.

Mantén una pequeña ficha de datos fuera del diseño. Registra el nombre de cada plan, su público, la unidad de facturación, la cantidad incluida, el límite, la condición para pasar a un plan superior y la vía de compra. Si la fuente indica que un punto sigue pendiente de decisión, márcalo como tal. Una maqueta atractiva es un lugar especialmente poco adecuado para resolver por accidente una política comercial que aún no se ha definido.

La ficha también evita revisiones incoherentes. Si el equipo cambia el número de editores incluidos, quizá haya que actualizar el resumen del plan, la fila de comparación, la calculadora y las preguntas frecuentes. Trátalos como distintas representaciones de un mismo dato, no como textos independientes que casualmente contienen el mismo número.

Diseño de tablas de precios: primero preseleccionar, después comparar

Las tarjetas de planes y la matriz de funciones cumplen cometidos distintos. Las tarjetas ayudan al visitante a preseleccionar opciones. La matriz le permite contrastar esa selección con requisitos concretos. Intentar incluir todos los detalles en las tarjetas produce columnas largas en las que cuesta localizar las diferencias.

Las recomendaciones de Figma sobre precios distinguen entre una presentación breve de los planes y una tabla comparativa más completa, y aconsejan indicar expresamente las unidades de facturación junto al precio. Es una base útil para la estructura que planteamos aquí. Recomendaciones de Figma para páginas de precios.

En Fieldnote, la tarjeta Solo podría describir el trabajo en proyectos independientes y después mostrar el precio, el límite de proyectos activos y el acceso de invitados. La tarjeta Team podría describir la investigación compartida y después mostrar el precio, los editores incluidos y la capacidad para proyectos compartidos. La tarjeta Organization podría explicar la administración centralizada y la vía de compra a través del equipo comercial. No hace falta imponer una cifra pública inventada a esta última tarjeta si el modelo comercial requiere un presupuesto.

Mantén el mismo orden de información aunque cambien los valores. Si una tarjeta coloca las condiciones de facturación debajo del botón y otra junto al precio, el lector debe buscar qué relación tienen. La alineación se convierte en una forma de explicar: una misma posición corresponde a un mismo tipo de información.

Lee la página de precios de GitHub en dos pasadas

La página de precios de GitHub ofrece un ejemplo real útil de la diferencia entre el resumen de un plan y una comparación detallada. La zona de planes presenta las opciones disponibles y las vías de compra; la comparación de funciones situada debajo ofrece otro nivel de detalle. Los precios de las capturas sirven para ilustrar la estructura de la página; consulta la página en directo para conocer las condiciones vigentes.

Examina las dos zonas con preguntas distintas. En el resumen, ¿puedes identificar qué opción podría servir a tu equipo? En la matriz, ¿puedes comprobar ese requisito que bastaría para descartarla? Esta división resulta útil porque una tarjeta introductoria y una comprobación previa a la contratación no necesitan la misma densidad de información. Una tarjeta que contiene todas las filas de la matriz deja de ser un resumen.

Pide a un posible comprador que elija un plan adecuado y explique el compromiso que implica; sus respuestas permiten comprobar qué comunica el diseño.

Calcula el importe que el lector está eligiendo pagar

Para un ejemplo independiente de cobro por puesto, imagina un servicio ficticio llamado SeatMeter cuyo plan se anuncia a 12 $ por editor y mes, con facturación anual y un mínimo de cinco editores. Un equipo de tres personas no tiene por qué pagar 36 $ cada mes. Según esas condiciones, el compromiso anual mínimo es de 12 $ × 5 × 12 = 720 $.

En este punto suele fallar el diseño de precios, aunque cada cifra por separado sea correcta. La jerarquía visual hace que se recuerde el equivalente mensual y que el pago real resulte casi invisible. Pide a alguien que explique cuánto espera que le cobren hoy. Si responde con la tarifa en lugar del importe a pagar, aumentar el tamaño de la tarifa no resolverá el malentendido.

Evita que una etiqueta de ahorro oculte la base de comparación. Si la opción anual supone un ahorro del veinte por ciento respecto a doce pagos mensuales, indica qué tarifa mensual se ha utilizado. Si una promoción solo se aplica al primer periodo, mantén esa condición cerca del importe promocional. Una etiqueta que parece permanente aplicada a una oferta temporal crea una expectativa que quizá una nota al pie no consiga corregir.

Aplica el mismo rigor a la capacidad incluida. «Cinco editores incluidos» y «mínimo de cinco editores de pago» pueden dar lugar al mismo tamaño inicial de equipo y, sin embargo, describir reglas comerciales distintas. Escribe la regla real en la ficha de datos y asegúrate de que la tarjeta, la matriz y el paso a la compra mantienen ese mismo significado.

El precio por espacio de trabajo sigue un cálculo distinto

Mantén juntos el importe, la moneda, la unidad de facturación y el compromiso. En las suscripciones anuales presentadas como un equivalente mensual, el cargo anual total debe aparecer dentro del mismo grupo visual.

Supongamos que Fieldnote Team cuesta 30 $ por espacio de trabajo al mes con facturación mensual. La oferta anual independiente, también por espacio de trabajo, cuesta 288 $ al año, equivalentes a 24 $ al mes. Una tarjeta anual clara podría mostrar el equivalente mensual como cifra principal y, justo después, una frase que explique que se facturan 288 $ al año. El visitante no debería tener que deducir si puede realizar doce pagos de 24 $.

La diferencia entre cobrar por espacio de trabajo y cobrar por puesto merece el mismo cuidado. «24 $ al mes» es una información incompleta si un equipo de seis personas va a pagar realmente seis veces esa cantidad. Indica si el precio incluye un número fijo de editores, si se aplica a cada editor o si parte de una cantidad mínima. Sitúa esa condición sobre la cantidad en la misma zona que el precio, en vez de dejarla en una ayuda emergente distante.

Si el uso es variable, explica los límites antes de añadir una calculadora. Una calculadora cuya base no sea visible puede dar apariencia de precisión a un precio incierto. Indica qué uso está incluido, qué activa un cargo adicional y si la estimación mostrada incluye elementos opcionales. Si no existe una tarifa estable con la que calcular, explica en su lugar qué información necesita el equipo comercial.

No mezcles varias unidades en una misma fila de comparación. Una celda que diga «10» y otra que diga «Ilimitado» son ambiguas si la fila no indica qué se cuenta y durante qué periodo. «Proyectos activos» no significa lo mismo que «Proyectos creados al mes». Esa diferencia puede cambiar la compra aunque los números parezcan idénticos.

Trata el selector de facturación como un cambio de condiciones

Al cambiar entre facturación mensual y anual, todos los datos afectados deben actualizarse juntos. No se trata simplemente de animar la cifra principal. El total anual, la explicación del ahorro, el texto del compromiso y el destino de la acción de compra deben ser coherentes con el estado seleccionado.

En el ejemplo de Fieldnote, la facturación mensual suma 360 $ a lo largo de doce meses, mientras que la anual cuesta 288 $. La diferencia es de 72 $, es decir, el veinte por ciento del total con facturación mensual. Si el diseño muestra ese ahorro, deja clara su base. Comparar el importe anual rebajado con alguna otra tarifa promocional transmitiría algo distinto.

La opción activa necesita una etiqueta y un estado inequívocos. Dos palabras junto a un interruptor pequeño pueden dejar dudas sobre si la etiqueta de la izquierda describe el valor actual o la alternativa disponible. Un control segmentado con una opción visiblemente seleccionada suele ser más fácil de explicar en un prototipo. Sea cual sea el tratamiento elegido, la selección debe mantenerse al utilizar el teclado y no depender únicamente del color.

Cambia el control mientras miras un plan situado más abajo en la página. ¿Sigue siendo evidente qué periodo de facturación se aplica? Repetir una etiqueta de facturación junto a una comparación larga puede resultar más útil que un control que ha quedado muy arriba, fuera de la vista. La repetición está justificada cuando evita que el precio pierda su contexto.

Decide también qué debe permanecer estable. El orden de los planes y los límites de las funciones no deben cambiar simplemente porque el visitante modifique la frecuencia de facturación, salvo que cambie la oferta real. Una reorganización inesperada dificulta comparar ambos estados y puede dar la impresión de que el servicio ha cambiado mientras se estaba leyendo.

Construye filas que permitan una comparación honesta

Cada fila debe plantear una pregunta y responderla para todos los planes. «Capacidad de proyectos» puede contener una cifra. «Acceso de invitados» puede indicar «Incluido» o «No incluido». «Soporte» necesita una descripción si un plan ofrece atención por correo y otro incluye una persona de contacto asignada. Una marca de verificación por sí sola no puede expresar esas diferencias.

Utiliza la misma unidad y el mismo grado de precisión en toda la fila. Si la columna Solo dice «Tres proyectos activos», no escribas «Mucho espacio para crecer» en Team. La segunda frase elude precisamente la comparación para la que existe la tabla. Coloca el lenguaje promocional en la explicación que la rodea y el límite real en la celda.

Distingue la ausencia de la incertidumbre. Un guion puede significar que algo no está disponible, no se aplica, no se ha publicado o equivale a cero. Utiliza palabras explícitas cuando la distinción importe. Si eliges un símbolo compacto, deja claro su significado y asegúrate de que las tecnologías de apoyo también lo reciben. Un comprador nunca debería tener que adivinar si una celda vacía representa una limitación o un error de publicación.

Los nombres de las funciones también deben mantenerse estables. Llamar «Carpetas compartidas» a una misma capacidad en el primer plan y «Espacios colaborativos» en el segundo puede aparentar una mejora que no existe. Cuando una capacidad cambie realmente, describe el cambio: más miembros, un historial más largo, otros permisos o un compromiso de servicio distinto.

Agrupa las filas en torno a preguntas reconocibles. Fieldnote podría utilizar secciones de trabajo en proyectos, colaboración y administración. Las agrupaciones deben ayudar a encontrar una respuesta, no reproducir el organigrama interno del equipo de producto. Si el comprador piensa en cómo compartir el acceso, haz que esa información sea fácil de encontrar, aunque varias áreas de ingeniería sean responsables de las funciones que lo permiten.

Ten cuidado con «Todo lo incluido en el plan anterior». Acorta una tarjeta, pero obliga al lector a buscar en otro lugar para entender un nivel superior. Eso puede ser aceptable en un resumen breve. En una matriz suele ser más útil repetir el valor real, porque así cada fila se puede comparar de forma independiente.

Ofrece una recomendación con fundamento

Un plan destacado debe explicar para quién encaja. «Para equipos que comparten investigación entre proyectos» da una razón para considerar Fieldnote Team. «La mejor relación calidad-precio» pide al lector que acepte un juicio sin conocer su fundamento. «El más popular» es una afirmación sobre un hecho y necesita evidencia; no debe utilizarse como adorno para sustituir una recomendación.

Utiliza el énfasis para ofrecer un punto de partida sin dificultar la lectura de las alternativas. Un borde más marcado, una pequeña etiqueta o un cambio discreto de fondo pueden conseguirlo. Agrandar tanto la tarjeta central que cueste revisar las condiciones de las tarjetas vecinas es un mal intercambio. El usuario sigue necesitando comparar la opción destacada con las demás.

Comprueba la página sin ese resaltado. Si la oferta deja de entenderse, el énfasis estaba asumiendo demasiado peso explicativo. Los nombres de los planes, las descripciones de sus públicos y las diferencias visibles deberían permitir una elección razonable antes de que el color añada prioridad.

Resuelve las pantallas estrechas sin ocultar las contrapartidas

Apilar las tarjetas de planes es sencillo; conservar la comparación es más difícil. Cuando cada plan ocupa una pantalla distinta, recordar si el primero incluía una función pasa a formar parte de la tarea. No des por hecho que una disposición vertical limpia hace que comparar resulte fácil de forma automática.

Si hay pocos planes, conserva el mismo orden de funciones en las tarjetas apiladas. Para una matriz más larga, considera una comparación adaptada al ancho reducido que permita seleccionar dos planes, o una tabla con desplazamiento horizontal y una orientación clara. La opción adecuada depende de si los visitantes leen principalmente un plan o comparan varios valores concretos.

Un acordeón puede reducir la longitud inicial, pero también oculta información. Mantén las limitaciones esenciales y las condiciones de facturación fuera de las secciones contraídas. Si una persona tiene que desplegar todos los planes para descubrir cuál incluye acceso de invitados, el acordeón solo ha repartido el mismo esfuerzo entre más interacciones.

Cuando utilices una tabla de datos real, conserva sus relaciones estructurales. El tutorial de tablas del W3C explica cómo deben asociarse las celdas de encabezado y de datos para que esas relaciones estén disponibles para las tecnologías de apoyo. Una cuadrícula de textos alineados visualmente no es una implementación equivalente. Tutorial de tablas accesibles del W3C.

Prueba la versión estrecha con una comparación concreta: encontrar la opción más económica que admita seis editores y veinte proyectos activos. Esos requisitos inventados revelan si el diseño conserva la información necesaria para elegir. Comprobar únicamente que la página cabe dentro del área visible no responde a esa pregunta.

Haz que la acción corresponda al siguiente paso

El botón debe describir la acción inmediata que el visitante puede realizar de verdad. Iniciar una prueba, crear un espacio de trabajo gratuito, seleccionar una suscripción de pago y contactar con ventas son pasos distintos. Reutilizar «Empezar» en todos ellos produce una fila de botones uniforme, pero deja poco clara la interacción.

Coloca las condiciones importantes cerca de la acción correspondiente. Si una prueba requiere un método de pago, dilo antes de que la persona continúe. Si un plan para organizaciones empieza con una conversación, evita un botón que sugiera una compra inmediata. El objetivo es establecer una expectativa precisa, no explicar todo el proceso de compra dentro de la tarjeta.

Ten en cuenta a quienes ya tienen una suscripción. Una tabla pública de precios genérica puede enviarlos a un proceso de registro duplicado. La implementación final del producto quizá necesite un estado que indique el plan actual o una vía hacia los ajustes de la cuenta. Aunque el prototipo no implemente la lógica de cuentas, documenta ese estado para que el diseño no se evalúe únicamente con visitantes nuevos.

No utilices un botón desactivado para representar cualquier opción no disponible. Si el acceso depende de una condición de la cuenta, explica esa condición. Un control desactivado sin explicación no permite al usuario saber si se trata de un límite, un error temporal o una regla deliberada.

Las tarjetas capturadas de GitHub muestran esta distinción de forma concreta. Team ofrece «Continue with Team»; Enterprise ofrece tanto una prueba como el contacto con ventas. La segunda tarjeta representa dos vías para contratar el mismo plan, no dos funciones diferentes de ese plan. Durante la revisión, sigue cada vía y comprueba qué información debe aportar el visitante a continuación. Un color uniforme en los botones puede conservar el ritmo visual de la página mientras sus etiquetas siguen describiendo con precisión el siguiente paso.

Revisa el borrador con tareas de decisión

Una revisión visual resulta más útil cuando cada persona tiene una pregunta que responder. Asigna a una el escenario de trabajo individual y a otra el de un equipo en crecimiento. Pídeles que elijan un plan y expliquen qué datos les han llevado a esa elección. Su razonamiento revela ambigüedades que podrían pasar inadvertidas con una petición abierta de comentarios.

En Fieldnote, una tarea podría plantear el caso de un investigador con dos proyectos y varios invitados. Otra podría incluir seis editores y una tercera requerir administración para toda la organización. Incluye un escenario que deba descartar el plan destacado. De lo contrario, la revisión solo comprobará si funciona el énfasis visual, no si la comparación permite llegar a una conclusión distinta.

Después, pide a cada persona que indique qué importe se cobra de inmediato y qué compromiso de facturación adquiere. Una respuesta incorrecta es un problema aunque las palabras correctas aparezcan técnicamente en algún lugar de la página. Mueve o reescribe la explicación en función del malentendido, en vez de añadir automáticamente otra nota al pie.

Revisa también la tabla con un valor deliberadamente incómodo: un nombre de función largo, una función no disponible o un plan cuyo precio se negocia. No son excepciones de diseño infrecuentes que puedan dejarse para el desarrollo. Determinan si la estructura comparativa puede representar la oferta real.

En OpenDesign, una vista previa HTML puede servir de apoyo para esta revisión visual. Los comentarios permiten señalar un grupo de precios que induzca a error o una fila de comparación que pierda la alineación, y los cambios concretos de texto o estilo pueden mejorar la presentación. Aporta como contexto de diseño los datos aprobados de los planes. Verifica los cálculos de facturación, las condiciones de acceso de las cuentas y el comportamiento de compra en el flujo implementado.

Antes de entregar la página, contrasta todos los precios y límites visibles con la ficha de datos. Comprueba ambos estados de facturación, todas las acciones de compra y el diseño estrecho. La tabla estará lista cuando un lector pueda explicar con precisión una elección adecuada y sus condiciones, incluidos los casos en que el plan destacado no sea el correcto.