Un problema que llega antes de tener la app terminada

Aunque Caladero, mi app de pesca, todavía está en desarrollo y sin ficha pública en Google Play, ya estoy pensando en los recursos gráficos que necesitará. No porque tenga prisa por publicar, sino porque el icono y las primeras capturas condicionan decisiones de diseño que conviene tomar pronto: paleta de colores, tipografía de la marca, cómo se ve el mapa en miniatura.

Este artículo recoge lo que estoy aprendiendo sobre los requisitos técnicos y, sobre todo, sobre el criterio para no convertir la ficha en una promesa que la app todavía no cumple.

Requisitos técnicos que no dejo para el final

Google Play tiene requisitos concretos de tamaño y formato para cada recurso:

  • Icono de la app: se gestiona como icono adaptativo, con una capa de primer plano y otra de fondo independientes, para que el sistema pueda recortarlo en distintas formas (círculo, cuadrado redondeado, gota) según el fabricante del dispositivo.
  • Gráfico destacado: una imagen horizontal que aparece en la cabecera de la ficha y en algunos listados de la tienda. No es opcional para la mayoría de categorías.
  • Capturas de pantalla: al menos dos, en la proporción y resolución que exige la consola, y coherentes en estilo entre sí (mismo dispositivo simulado, misma orientación, mismo tono de marco si se usan marcos).

Diseñar estos elementos como un conjunto, no uno por uno, evita el efecto de "collage" que se nota cuando cada captura tiene un estilo distinto porque se hicieron en momentos diferentes del desarrollo.

El error de mostrar una función que todavía no existe

Este es el punto en el que quiero ser especialmente cuidadoso con Caladero. La app tiene un mapa con puntos privados, puntos públicos exactos y zonas aproximadas, un sistema de reputación en pruebas y capturas privadas básicas. Pero varias piezas —como la visita al perfil de otra persona o las rutas GPS grabadas— todavía no están terminadas en Android.

Sería fácil montar una captura "aspiracional" mostrando cómo se verá una función cuando esté lista, y ponerla en la ficha como si ya existiera. No lo voy a hacer, y no lo recomiendo a nadie: además de ser una promesa falsa a quien instala la app, genera reseñas de una estrella en cuanto la diferencia se nota, y esas reseñas son mucho más difíciles de revertir que el tiempo que se ahorra maquillando una captura.

Mi criterio, mientras el desarrollo avanza, es simple: cada captura que prepare para publicación deberá corresponder a una pantalla que funcione exactamente así en ese momento, no a un boceto ni a una versión futura.

Cómo estoy pensando el orden de las capturas

Aunque todavía no tengo la ficha final, ya tengo claro el criterio de orden que quiero seguir cuando llegue el momento:

  1. La pantalla que mejor comunica el propósito principal de la app en un vistazo, no necesariamente la más bonita técnicamente.
  2. Una captura que muestre el mapa con los distintos niveles de privacidad de los puntos, porque es la parte que más diferencia a Caladero de un mapa genérico.
  3. Un ejemplo de la función de guardado o de perfil, que dé contexto de que hay algo más que un mapa estático.
  4. Textos breves superpuestos, si los uso, que describan la función sin adjetivos vacíos ("la mejor", "increíble") y sin cifras que no puedo demostrar.

Esta lógica de orden la aplico igual que aplico la de enlaces internos en un blog técnico: lo primero que ve alguien debe responder a la pregunta que le trajo hasta ahí.

Errores comunes que quiero evitar

Algunos fallos que he visto en fichas de otras apps, y que quiero tener presentes cuando prepare la mía:

  • Icono que se ve bien en la vista previa cuadrada pero se recorta mal en la forma circular de algunos lanzadores, por no separar bien las capas del icono adaptativo.
  • Gráfico destacado con texto tan pequeño que se vuelve ilegible en las miniaturas de la tienda.
  • Capturas hechas en un tablet y usadas para representar la experiencia en móvil, sin aclararlo.
  • Uso de mockups con contenido de relleno en inglés ("Lorem ipsum" o textos de ejemplo) que se cuelan sin querer en la captura final.

Herramientas y proceso, no solo el resultado final

Otra cosa que estoy decidiendo con antelación es el proceso para generar estos recursos, no solo su aspecto final. Quiero poder regenerar capturas actualizadas sin repetir todo el trabajo manual cada vez que cambie una pantalla, así que estoy documentando qué dispositivo virtual uso para cada tamaño, qué datos de prueba aparecen en cada captura y en qué idioma se genera cada versión.

Esto tiene una razón práctica: una app en desarrollo cambia de aspecto con frecuencia, y si las capturas dependen de un proceso manual sin documentar, cada actualización de la ficha se convierte en un trabajo desde cero. Prefiero invertir ese tiempo ahora, definiendo el proceso, que descubrirlo tarde cuando ya tenga varias versiones de capturas inconsistentes entre sí y ninguna nota de cómo se generó cada una.

Los límites de este artículo

No he pasado todavía por el proceso completo de subir estos recursos a la consola de Google Play, así que esto no es una guía cerrada, sino el criterio con el que estoy llegando a esa fase. Cuando publique la ficha real de Caladero, actualizaré lo que haya aprendido en la práctica, especialmente si algún recurso resulta rechazado por un motivo técnico que ahora no preveo.

Guía oficial: Diseñar gráficos para la ficha de Play.

Conclusión

Los recursos gráficos de una ficha de Google Play no son un trámite estético al final del proyecto; son la primera y a veces única oportunidad de comunicar qué hace la app antes de que alguien decida instalarla o no. Prefiero llegar a ese momento con capturas honestas de una app más pequeña que con capturas exageradas de una app que todavía no existe del todo.