Construye una app desde cero en Figma con Bravo Studio

En esta ocasión quiero hablar directamente a aquellos diseñadores UX-UI de la sala. A los de las esquinas también, acercaos. Esto os va a hacer explotar la cabeza.

Si no eres diseñador, pero te gusta hacer tus pinitos con esto de las interfaces, lo que vamos a ver aquí también te va a cambiar la vida. Literal.

Porque, ¿qué me dirías si te cuento que ese diseño de una app, que tenías guardado en el cajón, puedes llevarlo a la vida sin una sola línea de código? Sin plantillas, widgets, elementos predefenidos… Desde cero. Totalmente personalizado.

Las reglas del juego han cambiado y, seguramente, ya sepas qué es esto del NoCode. Pero hoy quiero hablaros de una herramienta brutal. Es Bravo Studio y, cuando la conozcas, va a pasar a liberar tu imaginación.

¿Quieres conocerla? Pues vamos allá.

‍

El funcionamiento de Bravo es sencillo. Tú tienes una idea de app. Diseñas la interfaz en Figma o Adobe XD y preparas el backend en Airtable, Xano, Backendless o Notion, entre otras.

Ambas cosas, diseño y backend, las metes en la coctelera que es Bravo y sale tu app. Lista para subir a las stores de Android e iOS.

¿Parece sencillo? Lo es. Pero claro, como todo en esta vida, dependerá de lo que quieras complicarte.

Vamos a ver ahora qué vas a aprender en este curso.

‍

Vamos a conocer cómo funciona Bravo. Será una aproximación completa a la herramienta. Desde la idea inicial, pasando por el diseño (que haremos en Figma), la elaboración de la base de datos en Airtable, las diferentes llamadas API y la conexión de todo en Bravo.

Lo haremos mediante el diseño de una app para un restaurante. Te cuento la premisa:

Imagina que eres el dueño de una cadena de restaurantes de hamburguesas de autor en tu localidad y cuentas con varios locales (ojo, ya aquí estaríamos hablando de palabras mayores, de negociazo en mayúsculas).

Resulta que quieres dar a conocer tu carta, quieres facilitar información sobre ingredientes y alérgenos y quieres mostrar tus datos de contacto. También te gustaría informar a tus clientes de promociones, novedades en la carta, horarios especiales… En definitiva, quieres llevar un paso más allá tu ficha de Google My Business.

Pues bien. Esto es lo que vamos a diseñar. Desde el primer icono, hasta una app que podría subirse, sin ningún problema, a las tiendas de aplicaciones de Apple y Google.

Para ello vamos a conocer:

• Cómo debemos diseñar en Figma. Spoiler: la casa, siempre bien ordenada; Figma, también.
• Qué es un container y cuáles son los diferentes niveles jerárquicos.
• Las etiquetas en Bravo y la magia que desencadenan
• Pasaremos nuestro diseño de Figma a Bravo Studio y probaremos la primera versión de la app en nuestro móvil.
• Definiremos la base de datos en Airtable
• Conectaremos nuestra base de datos con Bravo Studio y configuraremos las diferentes llamadas de listado de elementos y detalle.
• Enlazaremos los datos de nuestra base a los elementos del UI de nuestro diseño.
• Conectaremos notificaciones a la app para informar a nuestros usuarios.

Completo el tema, ¿no? Pues todo esto lo vamos a hacer, paso a paso, montando nuestra app para la cadena de restaurantes que regentamos.

Si tú eres dueño de una, estás de de enhorabuena. Cuando acabes este curso, podrás lanzar tu app y darle a tus clientes un servicio mucho más premium. Eres libre de calcar lo que vamos a ver aquí.

¿Empezamos?

‍

Vamos a dar por sentadas ciertas bases antes de comenzar. Si estás aquí, es, en cierto modo, porque ya sabes manejar Figma o XD. Al menos los fundamentos básicos.

Si no es así, no te preocupes. Vamos a ir viendo técnicas y herramientas a lo largo del curso y, para trabajar con Bravo, serán más que suficientes. Pero te aviso (y quien avisa no es traidor): esto no es un curso de Figma.

Sentados estos principios, lo primero que debemos entender es cómo se estructura la información en Figma para que el diseño se ejecute en Bravo. La base de todo son los container.

En Figma, estos container son frames y los hay de diferentes niveles. Vamos a verlos:

En el primer nivel, estaría el top-level container. Esto se refiere a un frame que representa la pantalla que estamos diseñando. Sería como el Body de una web. Dentro de este frame, que representa el tamaño de una pantalla (iPhone, Samsung…), iremos incorporando las diferentes secciones.

Estas secciones que están dentro del top-level son containers y en ellos vamos a ir introduciendo los diferentes elementos que conformarán nuestro diseño. Estos pueden ser:

⁃ Estáticos: tal como los vemos en el diseño se mostrarán en la app final. (Ej: títulos, botones, menús…

⁃ Dinámicos: estarán conectados con una base de datos y mostrarán un campo concreto relacionado. (Ej: textos, imágenes, títulos dinámicos…)

Tenemos cards donde mostrar información, títulos, imágenes, botones, mapas… Lo que queramos. Estos elementos irán dentro de estos containers para que Bravo pueda trabajar con ellos.

Ya sabemos cómo funcionan la organización que necesitamos. Ahora vamos a complicarlo un poco más con las etiquetas.

De momento no vamos a entrar en detalle con ellas, porque las vamos a ver a fondo en otra lección. Sólo quiero que aprendas la más importante de todas: [container]. Como ves, la etiqueta se compone de una palabra entre dos corchetes. Así será la estructura para todas las etiquetas de Bravo, aunque con variantes.

Dentro de los container tenemos, además, varios tipos. Vamos a verlos, de nuevo, con nuestro esquema.

En el primer nivel vemos un tipo de container, en este caso [container:top-bar] Esto quiere decir que todo lo que esté dentro de ese container se mantendrá fijo en la parte superior de la pantalla. Aquí podemos meter nuestros menús de hamburguesa, el logo de la app, un botón recurrente… Lo que quieras que se quede siempre quieto en la parte de arriba.

Más elementos. En este caso un slider. También, la sección lleva la etiqueta [container] pero ahora acompañada de :slider y el tipo de visualización que queremos, por ejemplo default.

El siguiente container lleva una etiqueta de [container] a secas y, como ves, no ocupa el ancho de la pantalla. Esto es porque este container va a mostrar un listado de elementos y queremos que lo haga a doble columna. Por ese motivo, sólo colocamos el primer elemento de ese listado, le otorgamos la etiqueta al container y, posteriormente en Bravo, indicaremos que ahí tiene que mostrar un listado de elementos sacados de nuestro backend. Lo veremos pronto, no nos anticipemos. Este listado, evidentemente, también puede ser a una columna y ocupar todo el ancho de la pantalla.

Como ves, dentro de cada container metemos los elementos que consideremos. Asegúrate bien  que en el índice de elementos que ves a la izquierda están todos dentro de ese container y que, además, están bien nombrados.

Consejo: todos los elementos deben tener nombres lo más descriptivos posibles, te dejo a tu elección la nomenclatura. Pero, ahora bien, es fundamental que marques de alguna manera qué elementos van a ser dinámicos, porque luego, a la hora de coserlo todo en Bravo, el lío puede ser monumental.

¿Y dónde colocamos estas etiquetas? Lo hacemos en el índice de elementos que tenemos a la izquierda.

Insisto. Para los del “en mi desorden mando yo” o “yo es que soy muy anárquico, pero trabajo solo y da igual”. No, no da igual. Trabajar en Figma te exige que seas lo más ordenado posible. Si vas a trabajar con Bravo, mucho más.

Puede ser, por ejemplo, que veas que un elemento está dentro de un container mientras trabajas en el canva y luego, cuando llegas a Bravo y quieres visualizar la app, ese elemento no aparece, da error o, simplemente, se ha ido de vacaciones a otro lugar de la pantalla. Este error, tremendamente común, es porque, a veces, cuando movemos los elementos, los sacamos de ese container dentro del índice de la izquierda. Mucho ojo con eso, puede ser un auténtico quebradero de cabeza.

Ya conocemos la organización de los elementos. Ahora vamos a empezar a diseñar.

‍

‍

Nos metemos en el ajo. Vamos a diseñar la primera pantalla de nuestra aplicación.

Recordamos. Queremos hacer una app de una cadena de restaurantes.

Lo primero que vamos a hacer es definir ciertas cosas que nos van a hacer la vida mucho más sencilla. Vamos marcar los tamaños de letra que vamos a usar, las tipografías, los colores y cualquier cosa que vayamos a reutilizar varias veces.

Por ejemplo. Si hago una card y esa card se va a replicar en varias pantallas, la agruparé, la convertiré en un componente y la podré usar varias veces, simplemente copiando y pegando. De hecho, al copiar y pegar, se genera una variante de ese componente que podremos editar, por ejemplo cambiándole el título, el color… si así lo deseamos, sin tocar el original. Útil, ¿verdad?

También será tremendamente útil que configures un grid para ubicar los elementos y alinearlos. A mí me gusta diseñar con grids de 6 columnas, con un margen de 16 px y un espaciado entre columns (gutter) de 8 px.

Cuando tengamos todos estos elementos diseñados y determinados, vamos a empezar con las pantallas. La primera, la Home.

‍

‍

Vale. Esto ya empieza a coger forma. Tenemos parte de las piezas del puzzle. Ahora las vamos a meter en sus correspondientes containers.

Empezamos creando un frame para nuestra pantalla. Lo haremos utilizando el icono o pulsando la tecla F. En la parte derecha nos van a salir diferentes tipos de pantalla. Nosotros vamos a elegir el tamaño de un iPhone 11 Pro/X.

Lo primero que vamos a hacer es la sección Hero de nuestra Home. El Hero es la parte superior de cualquier app o web.

Este Hero va a contener nuestro logo y el icono del menú de hamburguesa. Nada más. Colocaremos, por ejemplo, el logo a la izquierda y el menú hamburguesa a la derecha. ¿Por qué? Pues por una cuestión meramente estadística: hay menos zurdos que diestros (yo soy zurdo y esto me jode), pero si queremos facilitar la navegación, debe de ser así. De todas formas, te invito a que hagas pruebas de usabilidad de tu app con posibles usuarios. Vas a flipar con las conclusiones que puedes llegar a sacar cuando sales de tu cabeza y entras en la de otros.

El Hero queremos que sea una topbar, así que utilizamos en el container la etiqueta [container:top-bar].

Ojo. Cuando hagamos scroll, las diferentes secciones se mostrarán por debajo de esta topbar, por lo que te recomiendo que pongas un relleno de color a este container, en las opciones del frame en la parte derecha.

Seguimos. Después del Hero vamos a poner unos botones para que el usuario elija la carta del tipo de comida que quiere ver. Estos tres botones son elementos estáticos, y enlazan con cada una de las cartas de alimentos. Están formados por una imagen y un texto. Para que todo esté perfectamente alineado, utilizaremos el AutoLayout de Figma.

En este caso, te pregunto: ¿necesitamos poner la etiqueta [container] en el frame que va a albergar esos botones?

La respuesta es no. Al no contener elementos dinámicos, Bravo no necesita que le indiques. Si quieres hacerlo, puedes, lógicamente. De hecho es una buena práctica que te acostumbres a poner esta etiqueta. Pero en este caso, necesario no es.

Tampoco es necesario que lo hagamos en los títulos de cada una de las secciones. Mi recomendación es que, de hecho, separes los títulos de los container. En este caso, tenemos el título de “hamburguesas destacadas del mes” junto a un botón de “ver todas”. Ambos elementos conforman, ellos solos, un container al que no le pondremos la etiqueta porque tampoco vamos a conectarlo con nada.

Lo siguiente será precisamente, la sección con las hamburguesas destacadas del mes. Lo haremos con un slider y utilizaremos el tipo default [container:slider:default]. Sólo diseñamos el primer elemento de ese slider porque el resto lo vamos a sacar de un listado dentro de nuestro backend.

Cada una de las cards que contendrá este slider contiene una imagen de la hamburguesa, su nombre, una muy breve descripción y su precio.

Para insertar una imagen tenemos que hacerlo a través de un rectángulo al que le daremos el relleno de tipo imagen. Este rectángulo con imagen podemos escalarlo. También podemos usar una imagen con canal alfa, en png, para que aparezca sin fondo. No hay problema.

Tampoco hay problema para conectar esta imagen a un campo de nuestra base de datos. En el caso de este slider será así. La imagen vendrá determinada por el backend. Luego lo vemos.

Por último, vamos a hacer un listado con los restaurantes que tenemos en la ciudad. Lo haremos poniendo en un lado una imagen y en el otro el nombre del restaurante y su ubicación junto a un botón de reserva. De nuevo, utilizaremos el AutoLayout para que todo esté bien alineado.

El botón de reserva, al ser pulsado, nos abrirá el número de teléfono del local y nos dará la opción de llamar. Por que funcione, este elemento llevará la etiqueta [action:phone]

Ya tenemos nuestra primera pantalla, nuestra Home. Sencillo, ¿verdad? Vamos a meterle más chicha.

‍

Con la Home diseñada, ¿te gustaría ver lo que has hecho en el móvil? Vamos a empezar con el proceso de Bravorización de nuestra app.

Para ello, nos vamos a Bravo, y pulsamos en crear una nueva app. Nos pedirá el enlace de Figma, lo copiamos y lo pegamos aquí. Tras unos segundos, veremos nuestra pantalla en Bravo. Si hubiese algún tipo de error, la herramienta lo detectará y te ofrecerá un mensaje en la parte superior. Mola mucho porque, si pulsas en Fix, te va a llevar al elemento exacto de Figma que está dando la lata.

Lo siguiente que necesitamos es instalar la app de Bravo Vision en nuestro móvil. Hacemos login en nuestra cuenta y ya veremos la app en ella. Entramos y, desde ya, podremos ir viendo y probando los cambios que vamos metiendo a nuestro diseño.

Esto es brutal porque, cuando ya tengas más avanzada tu app, te va a permitir invitar a usuarios early adopters que te van a dar el primer feedback de tu trabajo. Ya sabes: idear, diseñar, probar e iterar.

‍

‍

Después de esta parte, lo mismo te entra el hambre. Espera un segundo antes de ir a picar algo a la nevera.

En este caso vamos a diseñar la pantalla en la que listaremos las hamburguesas que tenemos en la carta. Para ello, de nuevo, vamos a tener tres secciones claramente definidas: el Hero (Top-Bar), el título de la página (“Nuestras hamburguesas”) y un listado con todas las hamburguesas que tenemos en el menú.

Lo primero, la top-bar. En este caso no vamos a poner el logo. En su lugar pondremos un botón con una flecha hacia atrás para determinar que desde ahí retrocedemos. Este icono puedes hacerlo tú desde cero, si te sobra el tiempo. Si no es el caso, te recomiendo que utilices un plugin de Figma que se llama Iconify y en el que puedes encontrar miles de opciones. Al seleccionar el icono que quieres, lo introduces en el container que quieras y verás que está dentro de otro frame. Utiliza ese frame para escalar el icono y colocarlo donde quieres. Así todo estará más ordenado.

En este punto, entra en juego otra etiqueta [action:goback] Podemos ubicarla en ese frame que contiene todo el icono. Esta etiqueta nos llevará a la página que habíamos visitado justo antes. Pero ojo, y esto es un problema de Bravo, no siempre funciona bien. Hay veces que, de manera incomprensible, no te lleva hacia atrás y, simplemente, no pasa nada. Ante estos casos, debemos plantear la necesidad de conectar, en el prototipado, esta flecha con la página que consideremos. Pero, claro, esto no hará una navegación natural. Tenlo en cuenta.

Bien. Ahora vamos con otra de esas funciones que son todo un must: el buscador. Diseñaremos un cuadro con el icono de una lupa y un texto placeholder que indique la acción de buscar.

Para que funcione necesitamos poner estas etiquetas en la capa de texto[component:input-text][

action:filter] Verás que aquí tenemos dos etiquetas en una. Te explico. Lo que le indicamos a Bravo es que ese texto será sustituido por lo que busque el usuario y que, mientras escribimos, busque entre todos los elementos de la página y filtre. Repito: todos los elementos de la pantalla, dinámicos y estáticos. Es decir, lo que va a buscar es coincidencias entre lo que hemos escrito y todo lo que hay en la página. Por eso no es un buscador como tal, pero nos puede valer.

No es un buscador como tal porque no está haciendo la acción de buscar sobre nuestra base de datos. Para hacer esto nos tendríamos que ir a un nivel algo más avanzado. Lo explico en el proceso de creación de Safe Scooter.

Una última cosa y muy importante sobre este buscador. La etiqueta siempre debe ir en un container top-bar. Inapelablemente. Si lo ponéis en otro lado de la pantalla o en otro container que no sea top-bar, no va a funcionar.

Terminada esta top-bar, seguimos con el diseño. El siguiente container incluye el título. Ya hemos visto que aquí no necesitamos marcar nada, a no ser que el texto sea dinámico. No es el caso. Por tanto, seguimos.

La última parte de esta pantalla es el listado de las hamburguesas. En este caso, y a diferencia del listado que teníamos en la Home, vamos a hacerlo a dos columnas. ¿Cómo? Muy sencillo: el container no puede ocupar de ancho más que la mitad del ancho de la pantalla. En este caso, mucho ojo con los diferentes tamaños de pantallas para los diferentes dispositivos, pueden jugarte una mala pasada.

Bien,ahora colocamos los elementos. En este caso, la card llevará una imagen de la hamburguesa, su nombre y su precio.

Insisto. Debes de dejar un margen en el container para que no termine de tocar el centro de la pantalla. De este modo nos aseguramos que no va a descuadrarse el diseño cuando lo rellenemos con datos dinámicos.

‍

Vamos con otra página de lista. En este caso, mostraremos todos los restaurantes que tenemos. Para ello, lo de siempre: una sección como top-bar que contiene el botón de menú y de ir hacia atrás, un título de la sección y la propia sección de listado.

Aquí, antes del listado, vamos a poner un mapa en el que, en base a las coordenadas que le fijemos en el backend, nos va a mostrar los resultados con marcadores.

El listado de restaurantes ya hemos visto cómo se hacía en la Home. De hecho lo vamos a copiar y pegar desde ahí. Pero, ¿y el mapa?

¡Ah, amigo! Los mapas me flipan. Es un elemento visual tremendamente atractivo y que va a darle un plus a tu diseño. Sin duda.

¿Cómo se configura? Muy fácil. Hacemos un rectángulo y la damos la etiqueta de [component:map] Evidentemente lo metemos en un container con su correspondiente etiqueta [container]

A esta etiqueta podemos añadirle más cosas. Por ejemplo, si queremos que el usuario pueda mover el mapa y hacer zoom a través de él, la etiqueta pasaría a ser asi: [component:map:interactive]

Si además queremos que esté centrado en unas determinadas coordenadas fijas, debemos añadirle [component:map:40.417179575849254:-3.7031078792149326:16] El número del final, en este caso el 16, marcaría el nivel de zoom que queremos aplicar al mapa.

Mucho cuidado. A la hora de la usabilidad, debes pensar en facilitar el scroll del usuario. Si este hace scroll sobre una superficie del mapa y el mapa es interactive, lógicamente lo que se moverá es el mapa. Punto de dolor. Te lo digo porque todas estas cosas restan amigabilidad y crean fricción. Si quieres que el usuario haga scroll en la pantalla, plantéate si es necesario que el mapa sea interactive.

Por último, si queremos que nuestro mapa tenga un marcador determinado, podemos diseñarlo en una página aparte y utilizar la etiqueta [asset:marker:default] De este modo, siempre que no indiquemos lo contrario desde el backend, el marcador que se vea en el mapa será ese. Una cosa importante: las medidas de este marcador deben de ser pequeñas para que no se descuadre.

‍

Ojo, porque si has llegado hasta aquí, ya tienes unas bases muy sólidas para ir diseñando lo que quieras y necesites. Estás en el buen camino, mi pequeño o pequeña padawan.

Ahora vamos a conocer las páginas de detalle y un elemento que es una cucada: los modales.

Aquí no vamos a tener listados. Sólo necesitamos containers que van a albergar diferentes datos dinámicos.

Por ejemplo, vamos a hacer la pantalla de detalle de cada hamburguesa. Esta va a contener el top-bar correspondiente con la navegación y un container en el que vamos a poner parte de los datos del plato y la descripción. Esta descripción llevará la etiqueta de [flexo] Esta etiqueta sólo puede ir en un elemento de texto y sólo en el elemento texto que esté situado en la parte más inferior de un container. Lo que hará esta etiqueta es adaptar la extensión del container al texto que pongamos. Muy útil para textos largos.

Además, en otro container tendremos dos botones que mostrarán la información de ingredientes y de alérgenos. Estas dos cuestiones las vamos a abrir en modales.

Pero, ¿qué es un modal? Es una pantalla que se abre deslizándose y que ocupa un porcentaje X de la pantalla, manteniendo debajo la pantalla de la que veníamos. Ese modal se cierra deslizándolo hacia abajo.

¿Cómo lo haremos? Crearemos una página aparte y en ella, en el container top-level, le indicaremos la etiqueta [page:modal:50%] Como ves, en esa etiqueta hay un porcentaje. Este señala cuánto va a ocupar este modal en la pantalla.

En nuestro caso, el modal de los ingredientes ocupará un 50% y el de los alérgenos un poco menos, un 40%.

Dentro de cada modal pondremos un texto que se rellenará desde el backend.

Bueno, ya tenemos esto súper encarrilado.

Otra de las páginas que diseñaremos será el detalle de cada restaurante, donde incluiremos, por ejemplo, la imagen del mismo, su nombre, su dirección, los botones a las diferentes cartas de alimentos (que podemos copiar y pegar desde la Home) y un botón de reserva que nos marque el teléfono del restaurante, igual que en la Home.

‍

Vale. Ya tenemos prácticamente l