Creating a mobile app using a no-code Figma-friendly builder
I have tested Bravo Studio, a no-code app builder, and created a mobile app in 3 days just by using Figma and Airtable.
First, some context
It all started as an artistic initiative. I have been inspired by Mike Joyce’s Swissted project and had been wanting to create something of my own for some time now. As a big fan of metal music, I saw an opportunity to do something similar in this particular genre. I used RollingStone magazine’s The 100 Greatest Metal Albums of All Time as a starting point for my project, but I removed some entries, added new ones and came up with my own top 100.
But how do I proceed from there? I did not want to “copy” Mike Joyce’s project, although I very much liked his style. While thinking about the choices to make to start my project, I have been spending a lot of time reading about recent improvements in AI. And I have been particularly fascinated by Stable Diffusion. As you may or may not know, Stable Diffusion is a deep learning, text-to-image model that learned to create images from noise. For each image used by the model, an iterative process was applied which consisted of progressively adding noise to it and learning to reverse the process until there was too much noise to continue. Applying this process to millions of images gave the model the capacity to create a new image from a simple prompt. Only a machine could proceed like this, right?
However, I was inspired by the process and created one of my own. I decided to take the album covers of my top 100 and for each of them, proceed as follows:
- blur the image until shapes are barely visible;
- define the colors I will use from this result;
- recreate a new visual from these simple shapes, either by cleaning the result or following my inspiration in the moment.
I applied this process to the 100 album covers of my selection and came up with a result I considered interesting enough to be showcased. But how? How could I interest people in discovering this project in a non-boring way? This is precisely when I decided to combine this result with a musical experience. And there I had my project: build a mobile app that would showcase redesigned album covers of my top 100 while listening to actual music.
Then, a framework aligned with my skills
Months ago I attended a meetup on no-code, and I remembered being particularly impressed by a live demo of Bravo Studio. The agency that presented its return on experience highlighted the following features:
- Natively integrated with Figma and Airtable;
- A simple process: just tagging frames in Figma and binding data in BS;
- No code required;
- 10 times faster than building an app the regular way (coding).
I was already keen on testing BS when I watched a video of BastiUI (a French UI designer making nice videos on YouTube and streaming while working on actual projects for clients) showcasing BS and demonstrating how to build an app from scratch in a matter of hours! Then it was decided.
Using a non conventional workflow to design the app
I knew I wanted to display my top 100 covers and I knew the app had to broadcast music. But I also knew that I had to explore BS and that I should anticipate that there would most likely be a lot of rules and constraints to make it work. So I decided to proceed iteratively in some kind of test-and-learn process to combine discovery, learning, designing, building the app. I know this is not the typical way to design an experience and an interface. But I also know that if I start with a design I would most likely have to change a lot of things to make it work properly.
I had some directions set from the start: I wanted to use the fonts and colors of my company brand (homopixelus), keep things as simple as possible and think MVP to avoid falling into the classic trap of a never-ending project.
Creating the database
First things first. I created a playlist on Spotify. Using an API gateway and spotify API, I extracted the data I needed. Then using Excel and PowerQuery, I created a table with all the required information: artist, album name, link to an image of the cover, release date, etc. The order of tracks in my playlist was the same I use to create my redesigns of covers. As I did it with Figma I used a naming convention that allowed me to export images that could easily be reconstructed based on the order of the album within the Spotify playlist. And there I had my database ready.
From then on, I created a first screen on Figma to test the generation of a simple list of covers in BS. Success. OK, moving on.
Defining the scope and the key features
The mission of my app was to showcase my work of design on my top 100 album covers and provide a musical background while browsing and discovering the covers. As an MVP I thought of the following screens and features :
- A simple splash screen with a logo and a name;
- An introduction to explain my project, something simple, quick and easy to read and understand;
- A list of the covers as a vertical scroll or grid of cards;
- A search feature on the artist, album name, release date, etc.;
- A sorting feature on the artist name, the album name, the release date, ascending and descending;
- A link to the Wikipedia page of the album, the music video on YouTube of a track of my selection, a link to Spotify to the same track;
- A about page about my project and my process;
- A about page about me and my background.
Using the Spotify API
Initially, I wanted to use the Spotify API to create an automatic broadcast of music while browsing the covers. While testing the integration in BS I discovered Spotify API to be (in my understanding) an API to control remote device. In other words, I could only control the Spotify app on the smartphone if it was launched and active (used within the last x minutes). Although I succeeded in properly integrating the Spotify API with BS (including authentication of the user) I eventually gave up on it because I considered it was too distant from the use I initially imagined.
Planning and designing
Before starting the design, I wanted to have a good knowledge on BS features and main principles. Therefore, I quickly read the online documentation, reviewed some examples available on Figma and made the following assumptions (to be mostly proved right later on) based on my comprehension:
- Responsiveness will be dealt automatically as long as I respect some simple tagging instructions and key principles to build my screens ;
- The links in the app between pages and elements will be identical to the ones defined in m y Figma prototype (simple and easy) ;
- A list of cards is designed as one element to be automatically replicated by BS according to the query I would use to bind data to the element in BS (basically the list I defined in Airtable) ;
- The search feature seems to be really simple and powerful and should not be a concern ;
- Sorting basically requires an Airtable query for each possibility of sorting with the equivalent in terms of screens and prototyping in Figma (probably the messier feature to implement in my experience).
I then used all these constraints to design and build my screens in Figma. The learning curve has been very short and effective. In a matter of hours I had a v0 of the app ready and more or less working. From then it was mostly about adjusting the design to optimize the resulting experience. Fortunately the process is quick and easy in BS:
- Click in BS to sync your project with Figma ;
- Refresh (if not automatically refreshed) in the BS app to see the changes.
It would be difficult to imagine something simpler!
Of course, there are some limitations but the opposite would be surprising. Here are some of them I have observed:
- Space between elements, sizes of texts and this sort of things sometimes produce unexpected behaviours, especially on devices whose DPR (Device Pixel Ratio) are low (when nowadays it is often around 3 if not above) ;
- Shadow effects follow unexplicit rules that can be tricky to predict: whether you put the shadow on a frame, a form, a frame within a frame, the result can be pretty different ;
- Auto-layout is missing and while it is understandable it is greatly missed ;
- Responsiveness is a maze, most likely because I still lack experience in building apps with BS ? ;
- Managing spacing and padding of a dynamic list appears to be difficult because you cannot anticipate how BS will render the result as it depends on the viewport of the device.
Should I do it again would I do things differently? Probably now that I have a better understanding on how things work, what seems to be possible and not (yet) possible, tagging, binding, API, etc. But mostly I expect to be more efficient and effective. The lesson learned is to keep things simple, be disciplined in the way you structure your screens and frames. The good news is probably than the simpler it is the better experience for the users, isn’t it?
About the backend
I only used 2 APIs: Spotify and Airtable. And, as mentioned above, I eventually abandoned Spotify integration. There were both easy to integrate and use as long as you take the time to understand the specs and requirements of the collection of available requests. I found BS’s interface quite easy and efficient to use. Compared to an API gateway all the main features are available while being simpler. In my experience it should cover most of the common requirements and expectations.
But again, I did not implement advanced features that could make things complicated. I suppose adding a like or favorite feature, ratings and comments, user profiles, transactional operations, etc. would require more advanced skills and experience.
Publishing the app
I do not own a Mac and I do not own an iPhone (I know, am I really a designer? …^^) therefore I decided to give up on publishing the app on Apple’s App Store. I suppose I could have tried to install a macOS virtual machine, use the iPhone of a friend, etc. but I considered I had already proved my point by releasing the app on Google’s playstore.
One thing to keep in mind when you decide to push the button, whether it is the app of a large company or an app to test and try built by a freelance designer, the process is identical. Indeed, you need to build a dedicated page on your confidentiality / privacy policies, prepare screenshots of the app, a description, etc. In the end it takes a few hours to initiate the publishing process and 3 extra days to get the approval. BTW, Google provides a report of all the tests that were conducted and I must say it is quite impressive although being simultaneously depressing. There are a lot of warnings regarding accessibility I chose to ignore to avoid redoing the whole process again and again. Again, my initial intention was more a less a proof of concept for me and a way to determine the required effort to build an app using BS should the need raise in the context of a mission for a client. And on those terms I consider my initiative to be successful.
Overall feedbacks
Now that my project is over I must say it has been fun, relatively easy and smooth, and overall a great experience. Before starting I was skeptical about the nocode app builders. In the end, of course there are some limitations but BS proved to be a good tool, mature, easy to use, and the company seems to invest in adding new features on a regular basis. My overall feeling is I found it easier to build an app with BS than building a website with Webflow. There are no copy-paste, only synchronization, data is dynamic and linked to an actual database. API are easily integrated. I do not know about security and all the aspects a company could require and expect to release an app to their customers. But this last concern aside, I would highly recommend Bravo Studio to any designer who uses Figma and wishes to release mobile apps on their own. Last, I consider the subscription to be reasonable given the value it helps create (19€/month).
My final thought would be that I feel like having added a new skill in my resume and I am not afraid of mobile apps anymore. And I am now thinking of what could be my next app! ;-)
