Built a Figma template for white-label app branding

Equeo is a mobile employee-learning platform. Its app ships under each client's brand: in the App Store and Google Play it looks like the client's product, not Equeo's. Clients can customize colors, button corner radii, logos, backgrounds, and the app icon.

The process was linear: a designer prepared the materials, the client approved them, engineering assembled the app, then store screenshots and publishing followed. Any delay at the first step moved the entire chain, and that first step always belonged to the designer.

Materials lived in separate projects: screens, iOS and Android assets, web, and certificates. The approval presentation was assembled manually in another tool, icon sets for different sizes through an external service, and colors were applied screen by screen. On some days, four or five new clients arrived at once.

Replace repeated manual preparation with one template where a designer inserts the client's colors and logo, while the presentation and assets are produced automatically.

• Customization was limited to what the platform supported: colors, button corner radii, logos, backgrounds, and the app icon. The template could not expand that set.
• The application worked with styles only, not variables, so the template had to be built around styles.
• Client functionality varied by plan and enabled modules. Keeping every possible screen in the template made no sense.
• iOS and Android were separate development teams with different internal processes.

Branding is the substitution of values into a fixed set of parameters. So the template works as a source of values rather than a collection of mockups: the designer changes parameters in one place, and everything else follows from them.

Style names came from alignment with engineering: together we defined the colors required and agreed on their names. The iOS and Android teams built a plugin that read those values directly from the Figma file through its API.

The implementation differed between the teams. On Android, the data went straight into the build, so a preview of the app with new colors was available quickly. On iOS, some steps remained manual. I only knew the technical setup on their side from the teams' descriptions.

Engineering no longer needed a separate color list: it received the values itself, under the same names the designer saw.

A dedicated area labelled “These elements are edited for the client” uses arrows to show what each master controls: the app icon, notification icon, navigation and authorization logos in two languages, the side-menu background, and authorization backgrounds for phone and tablet. All other pages are labelled “do not change”.

The splash screen crops differently depending on screen height. That went unnoticed with solid backgrounds. But with people in the image, heads or legs could be cropped on some devices. Sometimes the team caught it in QA; sometimes the client did.

Together with engineering, we introduced authorization_background and authorization_background_splash parameters with top, center, and bottom values. They define the edge from which an image is rendered and therefore what gets cropped. A separate optimize parameter disables compression for images with prominent gradients where compression created artifacts.

The config text sits in the file itself, next to where a designer inserts the background. The plugin reads it from Figma and passes it to image settings, so the system knows how to position an image and whether to optimize it. Engineering introduced the parameters; I documented the rules for choosing their values in the template.

iOS did not need this mechanism: an image meets the top and bottom edges of the screen and crops at the sides, while the layout keeps important elements inside the safe area.

The file does not include every feature of the application - just one main screen per section. That is enough to show what the branded product will look like.

The screens were designed once. A 13-slide presentation, App Store screenshots for iPhone X, iPhone 6, and iPad, Google Play screenshots for phone and tablet, and English versions for both stores are all based on those same screens - technically, their instances rather than separate mockups. Because the application was cross-platform, the web version received the same changes automatically, with no separate work.

Previously, icon sets for different screen sizes came from an external service: upload the source, receive an archive, then sort it manually. In the template, one icon source produces every size required by iOS and Android. Frames are named after their destination paths, such as res/drawable-xxhdpi/ic_notification, and export settings are predefined. Select the set and export it in one action into the finished folder structure.

Automation covers the typical case: the client's brand guide follows the template, and a side-menu or splash-screen background is a raster image inserted once and reused wherever needed with size adjustments.

Some clients supplied brand guides in an open format, with vector graphics unrelated to the template or their own logo-use rules. A designer could not simply drop in a file: each use had to be checked and adjusted to the client's rules. Complex vector graphics, such as patterns, directly increased the time required.

A logo could not follow one fixed rule either: insert the source at 32 px high, check it on a real screen for centering and visual size, then export it to the admin panel. Client marks have different proportions and requirements, so one fixed scaling rule does not cover them.

Certificates used one template for different cases: three completion types - program, learning path, and test - in two languages, while the platform populated the fields. Otherwise, certificate branding would have become a separate task.

Based on my own measurements while using the template:

• Preparing materials dropped from 3-4 hours to one hour for a typical client.
• The approval cycle went from one or two days to a single pass.
• On days with several new clients, materials could be prepared for four or five clients instead of one or two.
• Two external tools left the process: an icon-size generation service and presentation software.

The template outlived my role: another designer still uses it.

Exporting presentations from Figma remained a limitation. A full-size PDF could reach 300 MB, which is impractical to send to a client. Third-party compression created artifacts. The workable workaround was to export slides as PNGs and reassemble the presentation from images - manually doing the very work the template was meant to remove. I estimate this added around 10% to the cycle, but I did not measure it.

The issue was not the mockups but Figma's export behavior, which could not be fixed inside the template.

Some manual color work could be eliminated entirely. The template uses styles because the app only supports styles. But Figma could define two or three client base colors, with all 29 styles taking their values from those through variables. Preparation would then become entering a few values rather than editing each style separately.