Case Studies

An application for everyone, i.e. the process of creating a white label product

produkt White Label

In June 2019, for one of our clients  we had the opportunity to design the White Label platform – one that can be easily and quickly adapted to the needs of any individual customer. Learn the process of preparing and creating a new version of the White Label product.

White Label product platform
Cooperation period
June 2019
Number of sprints
Number of people in the project

Project context

At the very beginning of cooperation with client we were aware that we had to focus strongly on analysis. This is the key in creating White Label products. The previous version of the app was created “quickly” for the needs of the currents needs to service corporate clients. It was based on one of the trends in design – material design, but designed without much analysis.

Our goal was to develop a complete Design version of the CRM System for customer management in capital markets  within 3 weeks.

Problems within the project that we encountered:

  • limited time,
  • advanced terminology and processes within the system,
  • app displayed only on a specially prepared environment,
  • limited access to the target group.

Get our 30+ Lean Canvas and Templates!

Sign up now:

    I agree to the processing of my personal data by Project: People Sp. z o.o. for the purpose of marketing communication in accordance with Privacy Policy

    Sprint 1: Workshop & analysis

    Stationary workshop at the client’s organized to learn about his needs

    The start of the project began with a flight to the customer’s headquarters. Due to the complex terminology of the project, it was crucial to know the work environment, and it’s direct contact that allows to establish better relationships in the project that promote mutual understanding.

    A kick-off workshop always plays a key role for us, and we stick to it when we design a White Label product. During the workshop, we reviewed the application. We ranked the flow from the most important to the least important and analyzed individual user paths.

    The next stage consisted of quick interviews with users. It was during these conversations that it turned out that people using the program worked on two 27-inch monitors, supported the process using salesforce (customer service tools) and another internal platform. Much of it! So we figured out daily routine to know how the rebuilt tool should fit into their daily work mode.

    Finally, together with the Product Owner, we set the priority of user paths and sketched the first Low-fi screens, in line with the methodology of creating a White Label product

    During the workshops we have determined:

    • priorities of work in individual flows,
    • common expectations for the project,
    • cooperation principles: daily daily routine and design review once a week,
    • version acceptance model.

    During the interviews we have obtained input for further work:

    • resolution (full hd) and toolbox,
    • errors unnoticed by superiors,
    • better understanding of the tool,
    • user expectations.

    In this phase we used such tools & working methods as: individual interviews, Daily Routine, Live tool tests, a sheet of paper and a pencil 🙂

    Analysis of existing data

    After the workshop and returning to the office in Krakow, all cooperation took the remote form. We have started analyzing informations received and collected from the client.

    Knowing the priority tasks for users, we began to wonder: how users can accomplish them? Why the current information architecture in the implemented tool doesn’t work? Which functions the users use most often and which unnecessarily take up screen space?

    That was the way we designed the architecture of information and prioritized specific actions in individual flows. As a result, we have precisely specified all requirements for the White Label product :).

    In this phase we have determined:

    • list of screens and statuses needed in the project,
    • functionality prioritization,
    • app visualization and user flow.

    The information architecture was created using the tool. The use case – sample paths of using the product by users – was created using Excel. 🙂

    produkt White Label

    Sprint 2: White Label product for developers

    Once we had all the information we needed, we could move on to design. Due to the short deadline for commissioning the project, the client decided to skip the mockup phase, which resulted in designing the final design right away.

    One of the main assumptions of the project was to prepare it in a simple way, which means to create a White Label product. But before designing – it’s worth considering the following questions.

    Questions to consider:

    • How will this tool be customized?
    • How to make the tool look “nice”, regardless of the color chosen by the client?
    • How to customize fonts and typography to make them flexible?
    • What about potential data modification?
    • Should the accessibility rules for people with disabilities, e.g. the visually impaired be considered?

    Now it’s time to start working – designing the style guide (composition and style principles), on which we have established a few principles of the White Label product.

    • The user can edit only 2 colors in the application.
    • When the programmer receives the colors defined by the client, on this basis he will “recalculate” the colors used in other places, such as the background. He will operate with the opacity value and therefore, the application will always look right (regardless of the colors, the color palette will be similar).
    produkt White Label


    • So-called Fixed colors have been defined – colors that will be permanent, regardless of other changes made to the project.


    • Fonts were based on Ratio 1.618. The basic size is 16px. Each subsequent size is a multiple multiplied by the ratio.
    produkt White Label


    • Accessibility rules for the visually impaired have been set as well. This means that individual colors are supposed to have a certain contrast.
    • We’ve also created general interaction rules and rules for reporting error status and success.
    • We have also designed common rules for clickable elements, which means everything that’s clickable has got a specific color and icon.
    • We also predicted the behavior of buttons and inputs in the native, active, focus and filled state.
    produkt White Label

    Of course, the proposed style guide was at an early stage. However, it was necessary to start with him, since our sprint was ahead of the Front-end Developers sprint by a week. In the later process, some elements changed, but general issues regarding the principles of creating a White Label product remained as planned.

    Tools used:

    • Sketch,
    • Invision,
    • Sheet of paper, pencil.

    Sprint 3: Design and Guerilla Tests


    When we know what we are doing and with what components, we must finally design some screens. 😉 It would seem that if everything is ready to create the White Label product, then making individual elements should be just a formality.

    produkt White Label

    However, as it happens in the project, when visualizing subsequent screens, new challenges and opportunities might be encountered. We started designing screens from the first element in flow, which was the stage when the user enters the application. Problem? The client pushes to start designing from the most important element. That’s why we have explained the logic of such action to him:

    In natural flow, the user will never see the “most important” screen first. Therefore, his experience begins much earlier, even before this screen. The patterns that we will develop on previous screens (e.g. we will teach the user that the green color with the icon on the element with the shadow is something clickable) directly translate into subsequent screens.

    That’s why we designed the first version of the search, then the search results, and finally a single user page. After the design was completed, the screen was passed to the Product Owner and Head of Product who verified, together with the target group, how the screens were clicked (understood). In this way, we iterated up to 7 versions of the most important screens to make sure that users not only fully understand, but also will use the appropriate functions.

    Guerilla Tests

    After designing the overall flow, we invited actual users of the tool for testing. We wanted to validate how we solve their problems using new design. We checked on an ongoing basis how they understood individual elements. This involved quickly testing individual items by showing them different alternative versions and questions about how they understand the design.

    This step took the longest of the entire process due to the time consuming design. During subsequent iterations, the style guide was modified, which was constantly updated. Of course, this process generated improvements for developers. However, each change was consulted with Front-end Developers in order to implement it correctly. In this way, the customer saved because he avoided the costs associated with corrections that would take place after the end of the project.

    We work lean. Let’s keep in mind that the process of improving the application, according to this methodology, may last indefinitely. As the application is MVP, we have, in advance, established a satisfying moment for each stakeholder who was the moment of completion of the work

    During this stage:

    • we designed more screens,
    • we have made corrections and ongoing updates based on observations and feedback from users.

    Tools used:

    • Sketch,
    • Invision,
    • Zepplin,
    • Live tests,
    • Guerilla tests.

    Sprint 4: Implementation

    The implementation took place simultaneously with our works, starting from the second sprint. After putting the file and organizing Zepplin (a tool for cooperation with developers), we were constantly supervising and consulting the level and quality of implementation. For example: when there were doubts about the length of the animation or the length of loading the search results, we made some minor improvements in the design.


    Project summary – in numbers and more

    The application development process took three and a half weeks. Were all the goals achieved? Of course not. This was too short a time to be sure that nothing has been missed.

    However, the goal set at the beginning of the workshop, namely the design of the White Label product, was achieved. The completely unused application turned out to be a solid foundation for development. Technical elements, which will be used in further works, have been thought out. Moreover, the application was created in accordance with User Centered Design.


    Number of screens


    weeks for design preparation


    people in the design team

    Tools, methods and techniques used in the project

    • Individual interviews,
    • Daily Routine,
    • Live tool tests,
    • Excel,
    • Sketch,
    • Invision,
    • Zeplin,
    • Live tests,
    • Guerilla tests,
    • sheet of paper and pencil.

    Case study isn't enough?

    Would you like to learn about the whole process and how we could carry it out in your organization?

    Let's talk

    Project team, i.e. who was responsible for what

    Author of the Case Study

    Tomasz Osowski Lean UX & Service Designer w Project: People
    He helps companies create an excellent user experience while ensuring the profitability of their business. His job is to create products and services that are in demand and satisfy both the consumers and business owners.

    Certified Business Coach, Personal Development Coach, and Certified Design Thinking Moderator. Tomasz is also an entrepreneur sincerely in love with Lean methodology. He always works to get a product to market as quickly as possible with the least capital outlay.

    He has cooperated with companies such as T-mobile, Ecard, inPost, ING, Nationale Nederlanden, Brainly, Publicis, Netguru. Organizer of DesignWays Conference.