White Label Products

I’ve been very fortunate to have worked in a variety of products and applications. Some of the most challenging products were in fact “White Label Products”, or applications that clients purchase, rebrand and alter according to their needs (customization being a huge sales point for this type of product category). This article aims to shed light on some of the lessons I uncovered while working on this type of applications, and how these considerations can easily be migrated/extrapolated into other product types.

White Label Products. Wikipedia states, “A white-label product is a product or service produced by one company (the producer) that other companies (the marketers) rebrand to make it appear as if they had made it”. This is a type of product, that in the specific case of software solutions showcases two layers of clients/characters for the organization developing it: on one hand, there is the direct client who buys the platform/product/app, and the other layer, is of course the final user who will utilize that same platform/product/app, once it’s been rebranded or customized according to the purchasing entity. Here are some important considerations that I have observed and resonated with me after going through the Design and Development of two types of platforms such as these.

Understand all your Clients — this statement is of course very obvious. However, when working on a white label product, one can fall into the trappings of only focusing on the final user, the one who effectively uses the platform to perform a certain action. It’s fundamental that Designers, alongside their team members on the Design Thinking process, understand how the trifecta of relationships exist, namely between the Design Team, The Purchasing Client and The Final User. As The Design Thinking process unfolds, research is done, the problem is defined, and all the sources of input start being documented, the teams must never lose sight that understanding users implies both the clients who will be massaging that software tool to their branding needs, accessibility standards, localization needs or any factors they deem important, alongside the usability factors that impact the final users who will touch that platform/product/app (this obviously implies, when doing user interviews, in order to understand user journeys, motivations, expected outcomes, the Design team should never be solely focused on one sole user category).

Strategize, Research, Scale — this type of product due to its intricacies, requires a considerable amount of strategy in terms of what can be considered the elasticity of the solution, ie what can be effectively altered/customized, to fulfill the clients needs. This type of strategy typically implies considerations not just for the product/platform that the client and final user will interact with, but also with additional pieces of this puzzle, which include a specific product where the client logs in, and where the diverse variables of the platform/app can be altered (and where the customization by the client is effectively rendered and executed). Going through the research is fundamental, since it informs what the expectations for the platform/product/app are, but as the process continues, through the collaboration with Business (and its requirements), Development (and its bandwidth, resources and feasibility), all these different players (and sources of input) come into play. Scaling is of tremendous importance at this point. White Label Products typically envision/contemplate scaling from the perspective of users (growth and retention), but also due to demands of globalization. In the cases I specifically worked on, localization played an important role on a variety of levels, from the Architecture of the application itself (where user journeys, flow refinements were crucial), UI definition, to granular elements such as font definition (that can be rendered across multi-cultural contexts, while maintaining the UI integrity) and of course, branding co-existence.

Ideate, Test, Iterate — much like the Design Thinking process epitomizes, the solution is only as sensical as what is effectively tested, and in the case of these products, across the different types of users/characters that this product specifically interfaces with. Always remember that different types of characters will focus on different aspects of the platform/product/app, but ultimately, when the previous points have been discussed, when the opportunity arises, test from the early sketching sessions if possible, in order to understand the path you’re on, and be informed by the feedback that is given. Chances are that at times, the types of feedback you collect is even contradictory, since both categories of users may have different intents during the flow of the product. That usually means that enough cases weren’t uncovered during the research process, and what was considered an edge case, turns out to be something quite important, either for a client, or the final users. The ability to test with both user categories is imperative. In the case of the impossibility of that (which I had to deal with as well), either use processes such as FAST (focus, attendance, summarization, translation), where you either use proxies for users or rely on customer support/management teams, to understand these journeys and expectations. In some of these cases, the access to all user categories won’t be as seamless and straightforward, as is the case with the typical app/platform/product.

Document — remember to document all these phases thoroughly. In order for these products to have successful scaling, it’s important that any team that comes in touch with this type of project, understands its genesis, all the variables that were weighed in. Considerations such as Design Systems are fundamental, since they inform what exactly in the product/app/platform retains its integrity, or what exactly can be adjustable by clients (which again, it can range across a broad spectrum, depending on business/sales point of view, but also technical feasibility, branding, among many other factors). Documentation or the ability to document processes, decisions, outcomes, pathways, should be something Designers always keep in the back of their minds, persistently hammering. Documentation allows for effective shareability of processes, findings and hopefully assists in building context and team integration.

Reality Check. White Label Products are immensely challenging. The fact they touch on a multivariate type of users/characters, forces Designers and their teams to contemplate multiple demands, some of which may at times be even apparently contradicting/conflicting. It’s a testament to the flexibility, resourcefulness and credibility of the Design discipline, and of the Design Thinking process, that teams can understand that there isn’t a sole path to get one solution delivered. Being able to identify the paths/scenarios users take, as varied as they may be, is what truly differentiates successful products of this nature.

I’ll conclude with the following quote, from Friedrich Nietzsche on the topic of strategy, which is one of the topics of this article:

“We do not place especial value on the possession of a virtue until we notice its total absence in our opponent.”