/ Assumptions.
An application to manage and monitor the status and labour intensity of the bank's implementation teams.
The main goal of the DevOne application was to provide bank managers with an efficient way to monitor the statuses and workload of implementation teams. The problem the application addressed was the lack of a tool to support workload management of the bank’s product teams. Without a solution that allowed monitoring of statuses and employee workload, there was significant chaos in planning specific actions, resulting in inefficient use of resources during both new implementations and maintenance of existing products.
The application’s concept was to reflect the information and statuses contained in Jira in the form of accessible charts, diagrams, and tables. The application’s interface was meant to enable efficient browsing of resources in search of the necessary information, which had previously been difficult due to Jira’s limitations. This solution enabled, among other things, tracking test progress, deploying new functionalities, and identifying potential delays in banking projects. The monitoring covered all roles in the bank — from developers to testers to business analysts.
The application also offered the ability to flexibly search for needed information with filtering and comparison options across teams, departments, divisions, and even sectors.
/ DEVONE APP
The process of designing a product
/ Discovery Stage
The development of the DevOne application began with initial meetings with the Head of IT, during which the general idea and main assumptions of the application were presented to me. We then held a business workshop where, using the Kick Off Canvas tool, we defined business goals, assumptions, hypotheses, and technological constraints. Although the project initially seemed simple and easy to understand, the discovery workshop helped organize the existing information and identify unknowns that emerged at this stage.
As part of the workshops, we also planned a survey study among our target group to deepen our understanding of the needs and problems faced by managers in their daily work. Unfortunately, due to the tight schedules of the bank’s managers, qualitative research in the form of IDI interviews was not an option. We started the survey by holding a meeting where we developed the research questions. I then prepared the survey in the Webankieta tool and sent it to the individuals indicated by the CTO. After two weeks, we analyzed the responses and drew conclusions together with the product team during a workshop.
/ Define stage
In the next stage, a design workshop was held during which we discussed and analyzed all the information we had, including the data collected during the research. We clearly defined the problems and needs of our users and formulated the final assumptions for the application. Thanks to the presence of developers, we were also able to immediately discuss the technological limitations of these assumptions. During brainstorming sessions, we generated functional maps that the application should include, and with the support of a systems analyst, we developed initial user stories.
To better visualize what we wanted to achieve, I used the technique of quick sketching of the general structure of the application and data charts during the session. This helped me avoid design errors and better understand the assumptions and technological constraints. I then conducted desk research using industry sources on web application design and tools for visualizing and processing large amounts of data. I looked for examples and best practices in building applications using advanced charts, diagrams, and tables. I also included UX sources that presented methods for ensuring high usability of such solutions.
/ Develop stage
Based on the collected materials, I designed low-fidelity wireframes covering all use cases. I continuously consulted the views with the product team, discussing the charts used for data visualization. After completing the initial wireframes, I began designing the high-fidelity version — starting with the general structure of the application and component layout, and ending with detailed data visualizations: charts, tables, and diagrams. The design had to comply with the bank’s Flame Design System. In most cases, I had to create new components from scratch using existing tokens. I consulted each designed element with the Design System team to ensure compliance with the standards.
In later stages of design, the system was extended with tools for generating charts in the new standard, which significantly improved my work. I consulted each view with the product team and made necessary adjustments on an ongoing basis. When designing certain functionalities, we held live workshops where we systematically made changes to the design.
/ Deliver stage
After completing the design, the wireframes were handed over for implementation. I actively collaborated with developers, explaining the behavior of components, animations, and transitions. The biggest challenge was presenting the behavior of the designed charts and diagrams — the prepared variants and desk research examples proved helpful.
As development progressed, I tested the successive views and verified their consistency with the wireframes, reporting any discrepancies directly to the developers. After the application was deployed to the production environment, we planned short usability tests with IDI interview elements to identify any interface errors. These tests were conducted in a hallway testing format with members of the bank’s product teams. I prepared the test scenario, recruited respondents, and then conducted the tests during which participants completed specific tasks in the application. Finally, I analyzed the recordings and notes, and compiled conclusions and recommendations in the form of a Miro board.
The research findings were discussed during a workshop where we identified the necessary changes and needs resulting from the interviews, and then generated ideas for new functionalities. I designed a set of modifications and new features, which were then handed over for implementation.
After making the application available to the management staff of our department, we began receiving suggestions and ideas for new features through private channels. All proposals were discussed during meetings and verified for technological feasibility. A breakthrough moment was the application’s release to the entire bank’s management. Soon after, we received numerous opinions about discovered bugs, improvement proposals, and needs stemming from the specifics of work in different departments.
After implementing further changes and functionalities, we began measuring user satisfaction. I designed a survey to measure satisfaction in order to collect information on how the application performed in daily use. I selected the appropriate research method, developed the questions and rating scale. I prepared the survey in Webankieta and sent it to managers at various levels. After several weeks, I analyzed the results and prepared a report, which we then discussed with the product team.
Based on the research results, which showed a high level of satisfaction, we planned the implementation of minor, cosmetic changes.
/ Summary
Working on the DevOne application was demanding mainly due to the need for clear data representation in the form of charts and tables that would be understandable to non-technical users. The lack of components in the Design System also slowed down the pace of design work. Although there was a temptation to skip user research, conducting it — both during discovery and post-implementation — helped avoid major design errors. Despite difficulties in recruiting respondents, the research had a significant impact on the final quality of the solution, which was confirmed by the satisfaction survey results. The involvement of developers from the early design stage allowed for a better understanding of technological constraints and contributed to faster generation of accurate ideas, which was important when working with large data sets. Many of their suggestions perfectly addressed the identified needs and problems. The DevOne project taught me close and effective collaboration with the development team, which translated into the quality and efficiency of my design work.