Building Jago Visual Language
How we are building the design system for Jago App on Flutter
I’m probably one of many lucky designers who can participate in building a product like Jago, from scratch.
Yup, you heard it right, from scratch.
When I first joined this project several years ago, it was still a concept of a life finance app. None of us had anything in our hands. No clear form of features we want to build. No codebase foundation. No design style guide for our reference. Nothing at all. We obviously didn’t want to just copy and paste some random digital bank app out there, so our sole drives were our leaders’ vision of what the future might be and how this new platform can change people’s lives for the better.
Jago is now one of the fastest-growing digital banking apps with over 3 million downloads in just a year after its launch. Its simple and more intuitive design speeds up multiple processes that used to be a hassle, like registration and loading.
You might be wondering how we come up with the design that your eyes see today in Jago App.
Design is largely about the system
In the early phase, most companies tend to prioritize engineers over designers.
They probably have a complete set of developers, product managers or project managers, and Scrum Masters (if they use Scrum as their software development model). The task of UI/UX design and research usually falls into the hands of freelancers, who follow instructions with limited context.
But that wasn’t how we approached the Jago App.
Since the early stage, designers worked together with product owners to work on three focus areas:
- How do we onboard people?
- What is the experience of our money container?
- How do we design the money movement?
I remembered that we were in a phase of constantly researching what type of users that we should target first, what sort of features will improve their quality of life, then most importantly, why should they use Jago and not other digital banking or financial management app.
Despite each focus that we were assigned to, we agreed that there is one thing that we need to put as a top priority before others:
What are Jago’s solid foundation and visual language?
You know how a foundation keeps a building solid and steady, even when there is an earthquake or storm outside, and how language allows people to understand each other. It is the same for software development, especially if we start with a small team of designers.
We went through many desk and field researches, as well as concept testing to formulate the principles. Honestly, we were very lucky to have enough time and supportive management to do it all.
We all believe that creating innovative products requires an equally innovative approach to how we build them.
Jago’s Foundation
The final results of countless researches and testings were compiled into a brand storybook (we want to call it that way since there is a misconception of “brand” as only logo and font, rather than a story to tell and experience to feel).
It becomes a “bible” for us designers, guiding us on how to start laying the foundation of Jago. We defined our typography, color palettes, iconography, basic components and spacing guides for the app. The foundation allows us to explore our creative solution individually, while still maintaining the visual in the same universe.
The foundation is yet to be perfect and still evolving, as we continuously iterate and review our collective works together.
Common Components and Reusability
After agreeing on the foundation, we created a mini-workshop together with developers.
Yes, we don’t want to work in silos right? The key to achieving a pixel perfect implementation is good communication between designers and software developers.
In this workshop, we displayed and presented the foundation that we have constructed. From this session, I learned the term common components.
Common components refer to a set of components like app bar, buttons, drawer, input fields, etc that has been added to the library. Each developer can reuse the components and build a page faster without having to write the code from square one again (which most of the time results in different design alignments).
We also discussed the POCs (proof of concept) that we have listed beforehand, marked them on a scale of priority and UX impact, and the possibility of implementing them in the design.
A week later, we held a demo session where developers showcased all the common components plus their interactions, as well as the POCs. We also asked them to create a common components library interface in the demo app for us to review and course-correct when necessary.
Traditionally, designers need to check and correct the design screen-by-screen. Now, we only need to maintain the source component, and all the screens will follow automatically. Can you imagine how it would greatly increase our working efficiency as well as deliver pixel-perfect implementation to reality?
Designing for Flutter
You probably have heard about Native, React, or Swift for software development, as they are the commonly used languages and widely known by software developers. But here, we are using Flutter, a software development kit created by Google, as our codebase framework architecture.
Flutter doesn’t come without challenges. First, all developers and product team need to participate in intensive Flutter training; familiarizing ourselves with it, in a very short time. Product designers were also involved and we had several discussions regarding Flutter design with the tech lead.
Using Flutter as our software development codebase impacted our approach to creating the visual design component for the application. Design in Flutter was greatly influenced by Material Design with some adjustments here and there. Google also provided references that guided us in composing the components for our design system.
And then, there are widgets. It can be an app bar, column, container, etc that can be plugged in and played in a Flutter app. Most of the widgets are Android-based, like buttons, bars, dialogue, etc. But there are also widgets for iOS called Cupertino. So Flutter is actually pretty flexible for both platforms, even though it’s built by Google who owned Android.
Since we built our own common components, a lot of the widgets were specifically customized to match the Jago brand and visual identity. In this process, we gathered tons of reviews among us the designers and also get the verification from developers to add it into their library.
To smoothen the review process, there is an entry point in the staging environment app for designers to check all the Flutter widgets and Jago common components. We could quickly fix designs that don’t fit the specification and prevent other developers from using the incorrect components.
Screen Resolution and Page Layout
One question was asked before moving these components into UI design.
What screen resolution should we design for?
It happened to be the most common design question when creating mobile or desktop applications. Well, there is no valid answer to that question; only what we agreed together by the end and, of course, with a strong reason behind it.
So we settled on 375x667 as the most ideal screen resolution for our mobile app design, but that wasn’t without challenges.
The benefit of having one resolution format as a starter is that you get the universal look of the screen design across designers. You can also reuse the components that you already have, like the navigation bar, which was already on the maximum screen width of 375.
This is where liquid components come in handy. Regardless of the width length, it will be automatically adjusted without breaking the sub-components. A liquid component is important to cater for the liquid layout that can stretch to any screen size, depending on the requirement and needs. We always avoided a frozen layout, where the design fits for one size only.
After choosing the standard screen resolution size, the developers raised two major issues:
- How will the design look like for a screen smaller than 375 (like a phone with 320 resolution)
- How will the design look like for a screen larger than 375 (like 390, 414, 428, for iPhone Pro Max for example)
The design team came up with an initiative to create a UI specification guideline. It detailed which part is the fixed element that will always stay the same size; and which part is the flexible element that will automatically readjust depending on the screen size. We created these guidelines for every epic and main component, then aligned with the developers so that we are on the same page.
With this guideline, we avoided tons of unnecessary design work.
Still image vs Motion
If two apps have the exact same functions and features, what make you choose one over the other?
Imagine this, two apps are processing your request. One app just shows a static “please wait” screen, while the other displays a very smooth looping animation. Psychologically, you are more entertained by the animation, which makes the whole waiting experience less boring. Product designers can improve the experience for a case like this by using well-designed animation or motion graphics, making the UI more intuitive and interesting.
Of course, not everything should be animated. We have to pick certain cases, and what will this case impact the customers, and how we can improve the experience. So we have to be selective in using animations in apps.
Designing animation for Flutter might be quite different from the other software development language. First and foremost, we can use LottieFiles as a placeholder for your animation. Since LottieFiles is an open-source platform, you can even use the files for free, as long as you put credit in your application. You can also use Adobe After Effect to create animation and use the Lottie plugin to export your work to JSON format.
Basically, JSON files animation is enough to integrate your animation in your app if you develop your app using react native or similar language. But for Flutter, we have to convert the JSON files to Flare format by using Rive. This is because, in the early development stage, Flare animations is the most compatible with Dart –the programming language used in Flutter.
Yup I know, the whole export and convert process is kind of complicated. But it is what it is. I’m just hoping that Lottie will later provide Flare animation or a plugin to export animations directly to Flare in the future.
Just like the common components, all Flare animations are collected in a library, so the animations stay consistent throughout the app.
Copywriting & Tone of Voice
One of the most important but often overlooked aspects in creating a design system is how to bring communication between humans and machines (application) come to life. It shouldn’t be rigid and lifeless.
Thankfully, Jago already had its personality traits defined since the beginning, through numerous early research. We are approaching the Indonesian mass market, which considers banks as scary, not transparent, exclusive, and complicated. These Personas give us a perspective on how to communicate our value propositions and avoid using technical banking terms as much as possible.
Personality trait is a very important aspect to consider in finding Jago’s voice. It is the key differentiator to other financial services out there, so we can also stand out, and show clearly who we are, and we are not.
Jago emphasizes diversity and multicultural openness. We have people from Indonesia, Singapore, India, and other countries working together with the same vision; crafting what we call a life financial solution for all. The diverse team requires us to use two languages in the Jago App: Indonesian as the primary language and English as the international language.
Integrating Jago’s voice tone into the interface design itself was a huge project. Here the good collaboration between product designer and product writer is the key to successful product/feature communication to the customers. No designer should use “Lorem ipsum dolor sit amet…” anymore. We have to put a real text, test it, and iterate quickly. Using real text also helps product writers in understanding the context and simplifying content or information so it becomes easier to digest by the customers.
It is essential for product designers and product writers to collaborate in building a good user experience, component, and UI on a bigger scale.
The end?
Well, after all of the work, what do we call the design system? And is it the final and ultimate guide?
The answer is… we have yet to give it an official name. We still address it using a nickname that we haven’t properly thought through. Our consideration is, the work is still far from done. There is plenty of room for learning and growth, the style might evolve as we continuously review and iterate the system.
We will continue creating an identity of our own. So, stay tuned for more updates on our journey in building Jago!
Like what you are reading? And are you up for building a system or digital product completely from scratch? Then grab your spot in our team!
