User Experience in Agile Approach – The Way We Work

The Factoring system is developed in an agile and highly iterative manner, and the approach to its design has a comprehensive dimension. It involves close cooperation in the form of workshops to exchange knowledge with the client, the product owner, the analysts, the production team, as well as usability tests allowing for a quick verification of design hypotheses.
 
Our team believes that product designing is not only the job of the designer. The best effects in terms of user experience design, understood as the aspect of a product that describes the needs, usability, functionality, and accessibility, i.e. all the properties that make our client (or our client's client) move around the system without stumbling, achieve their goals and perform tasks smoothly and successfully, can be achieved only by involvement of all stakeholders in the creation process.

This is where all agile working methods come in handy. Not only do they allow us to quickly see the first results of joint work, but they also enable efficient sharing of business and technological knowledge within the team.

Good UX, good design, and good products start with gathering appropriate people who share a common goal, and with a concept developed by the UX designer with the participation of stakeholders at a very early stage of the project. This is where different assumptions, visions, and above all, different experiences meet. Contrary to appearances, it is not only creativity that is crucial here, but also a kind of courage to experiment. It is not only about skilfully copying known solutions, just to cover the desired functionality of the system, but also to try something different, assuming that it will allow us to achieve a more accessible and intuitive product. What we deliver, what quality it is, affects our client's work, so it is natural that we want to make it as good as possible.

To start with, the business needs and the scope of the next sprints are discussed within the team. Then workshops take place to exchange knowledge and develop a preliminary concept. The concept is verified by the Product Manager, and then, after modification (if any), it is presented and discussed during a meeting with the Client and verified during tests with the end user. Parallel to the progress of work, the backlog of tasks is maintained and clarified. Designing must stay ahead of development so that it does not hold up the project at any stage. Hence - as designers we take on tasks for a sprint that cover the full business process, which are then divided into smaller Stories at the implementation planning stage. UX/UI projects are prepared in two versions - the product one, built using the Comarch Design System, and then the target version implemented at the client's site, based on guidelines provided by stylguide. Working with the Design System allows for skipping the lo-fidelity design stage - mockups that illustrate the target system architecture and its near-final appearance are seamlessly delivered. This approach allows for much clearer and more specific feedback from Stakeholders, Project Managers, Product Owners, Analysts, and iterations on the project run much more efficiently. It also allows us to evaluate feasibility of the project by the development team and to prepare an initial quotation of its implementation at the early stage. Basing the entire product on Comarch Design System allows the product version to be quickly and seamlessly translated into the version implemented in the client's branding.

But let's get back to experimenting. It is not uncommon to start with the expectation of just a light system/application redesign, especially since we often assume that users have learned the system they have been using for years - they have their habits. Change, on the other hand, generates concern because of the learning curve and time required to master the system again. At this point, however, the designer proposes sometimes quite radical changes, a completely new approach to the system architecture and the way of navigating it. Of course, it is not the case that we, as designers, are never wrong, and that after delivering a new version of the system, it might turn out that users prefer to have more information on the screen, and their tables with horizontal layout should scroll almost endlessly. At this point, in order to dispel these uncertainties as quickly as possible, the designers prepare a prototype of part of the system and hand it over to the Research Laboratory to crash-test the experimental vision with the target user, even before the implementation is in advanced stage. The Testing Laboratory adapts the appropriate methods. In the case of Factoring, a task-based testing involving specific tasks in the system was used along with a semi-structured in-depth interview to obtain information on the respondent's daily responsibilities, including the most frequent operations in the factoring system and previous experience of using the current factoring system and other systems.

The survey was carried out in two iterations and although it revealed some mistakes, it also proved that the right direction was taken. The mistakes pointed out by the respondents were prioritised and then corrected in the further design work. During the design process we also use other research tools such as in-depth interviews, focus groups and quantitative surveys. They are necessary when we need to gain knowledge about the nature of the user's work, their needs or problems.

The work model adopted in the project requires high flexibility and lack of resistance to frequent iterations and the resulting corrections, and sometimes even large changes. They are particularly frequent at the beginning of the project, when we are just working out the concept of the system. With time, when the whole team has a common idea of what is being produced, this work goes much more smoothly and the design results correspond more and more accurately to the common expectations. Although this is not always an easy delivery method and it involves absolutely all stakeholders, it gives the best results that are welcome by customers:

I would like to write about a new feature in the new system. The shortest way possible to write this is: WOW !!!

I started to understand factoring!

As soon as I would like to point out some missing features, I immediately find a solution. A lot of intuition and understanding, it is certainly done from the customer perspective, a very good direction.

UX/UI Manager at Comarch