/ Assumptions.
An app for reviewing a bank customer's financial capacity and issuing a credit decision for a loan product application.
The Pif Paf application is a back-office solution that supports the sale of credit products. It is specifically designed for a target group of credit analysts within the bank. The development of this tool was part of the manual decision-making project in the cash and consolidation loan process. A manual decision in credit products allows customers applying for a loan to receive a higher amount than what is initially calculated by the bank’s automated systems based on their creditworthiness.
The primary goal of the Pif Paf application was to enable analysts to examine the current financial situation of applicants for cash or consolidation loans, review information and data collected from various banking systems and external sources related to creditworthiness and history. Most importantly, the application was intended to allow analysts to assess credit applications and make appropriate credit decisions.
This solution also included mechanisms that reflected the corporate structure, enabling task delegation between employees and the ability to escalate a request to a supervisor or credit analyst manager. The application also solved the issue of scattered systems and data sources that previously required the use of multiple applications to verify an applicant’s creditworthiness and issue a decision.
/ PIF-PAF APP
The process of designing a product
/ Discovery Stage
The first step in designing the solution involved initial meetings with the Product Owner, during which we discussed general assumptions and ideas for the application. We also outlined the next steps necessary to create the application.
Together with the full product team, including business stakeholders, we conducted business workshops. Using the Kick Off Canvas tool, we structured the available information about the project, including business goals, assumptions, hypotheses, identified needs, and technological constraints. With the help of the Value Proposition Canvas and simple personas, we documented what we knew about the target group—credit analysts. The participation of their director in the workshop supported this process.
We reviewed the current tools used by analysts—banking systems and applications for monitoring creditworthiness and decisions. The next step was my deep-dive analysis of the current systems used to manage credit information and review loan applications. Through sessions with the director of analysts and system analysts, I gained insight into how these applications worked internally and understood their goals and architecture, which gave me a broader perspective of the environment in which we were designing the new solution.
Despite the participation of analyst representatives in workshops, we planned qualitative user research in the form of in-depth IDI interviews to better understand the needs and challenges analysts face in their daily work. We aimed to explore their tasks, workflows, obstacles, and gaps that affect their efficiency.
The research started with a business meeting where we defined goals and prepared an initial list of questions for the scenario. I then developed the full research scenario. Participants were recruited through appointments with candidates selected by the analyst manager. The interviews lasted about an hour. I moderated the sessions with the support of other UX designers who took notes. After the sessions, I analyzed the recordings and notes, and prepared insights in the form of a report and a Miro board, which we reviewed with the business team.

/ Define stage
After completing the user research, we moved on to design workshops. During these sessions, we developed a cohesive concept for the application and updated our canvases with new information obtained from the research, including the needs and problems of the target group. The research helped us understand the analysts’ work style and their biggest challenges. One of the most frequently mentioned issues was the fragmentation of systems and information sources, often forcing analysts to switch between many screens to find necessary data.
During brainstorming sessions with the product team, we created a map of key features the platform needed to address identified needs and problems. The participation of system analysts allowed us to cross-reference these features with the bank’s technical limitations and clearly define what could be delivered.

/ Develop stage
In the next phase, analysts and the Product Owner began writing functional descriptions and user stories. I actively supported the team in this process, which helped me better understand the application’s operation and improved the design process. Based on these descriptions and user stories, I created user flow maps. Given the low complexity of the functionalities, this task was relatively straightforward. The diagrams covered all use cases and user tasks.
Next, I conducted desk research on trends and best practices in web application design, analyzing sources like Dribbble, Behance, and Medium. I also reviewed competitor solutions in the banking sector, such as Millenium, mBank, and ING, as well as tools outside the sector like the accounting software wFirma, iFirma, and iFakt. These sources provided valuable insights into designing interfaces for large-scale data entry and editing.
I then created low-fidelity wireframes to visualize the general application structure without focusing too much on interface details. Later, I began working on high-fidelity wireframes, first laying out the basic element structure and gradually moving toward detailed designs.
To ensure nothing was overlooked, I relied on previously prepared materials—user stories, user flows, and low-fidelity mockups. I used the current version of the Flame Design System to design the views, which allowed me to utilize existing tokens and components. However, I had to design many components from scratch, as the library did not include the necessary elements for back-office solutions. I based the development of new components primarily on best practices sourced from industry references and major design systems such as Material Design, Carbon, and others. Every new component was consulted with the team responsible for the Design System to ensure compliance with the bank’s design standards.
The proposed views were reviewed during meetings with the product team. Some functionalities were even designed live during dedicated workshops, which sped up the refinement of complex functions and improved understanding of assumptions and constraints.

/ Deliver stage
After the mockups were approved by the product team, I initiated usability testing with users. I started by preparing research questions and a scenario, then recruited respondents from among selected credit analysts. I created a clickable prototype that covered the flow of a positive credit decision. The usability tests lasted around 30 minutes. Afterward, I analyzed the recordings and notes and compiled a report with recommendations. The findings were discussed during a workshop with the product team.
I then implemented the changes based on the usability issues identified and consulted the updates with the team for approval. Once accepted, I handed over the final mockups to the development team. I actively supported developers by explaining component behavior, animations, and screen logic. Since implementation was handled by an external company, I conducted a Figma training session covering developer tools and an introduction to the Flame Design System documentation.
After deployment, I supported the team in identifying and resolving bugs to ensure the product aligned with the designed views. At the end of the project, I helped create training materials for new analysts, including a clickable prototype in Figma, product documentation, and instructional videos.
/ Summary
In summary, designing the Pif Paf application was a challenge both in understanding the internal banking systems used by a niche group of employees and in mapping the application structure within demanding business requirements and technical limitations. Understanding the processes related to calculating creditworthiness and making decisions was crucial in building a solution tailored to analysts’ specific needs.
Although the project involved a typical back-office product, applying user research techniques enabled the design of a high-quality interface. This likely improved the experience for bank customers by reducing the time required to process loan applications and allowing for a more precise analysis of their financial situation.