10 Lessons on How Collaboration between Designers and Analysts Improved Project Quality
Have you ever been in a situation where a project has started, but the analyst and designer work at different paces without a clear mutual understanding? Have you wondered if your specialists know what the other side is doing or how their way of working fits together?
Such situations can cause confusion and raise the question of whether they even talk to each other at all. We, too, have occasionally faced these problems. Here, we describe how we resolved such a situation in one of our projects.
In the summer of 2022, we began working with a client to develop an integrated e-commerce and self-service environment. The client sells digital products to businesses. The end client can assemble the required product from multiple sub-products (as customers’ needs vary), which adds a certain amount of complexity.
As our client was operating in a technically complex and high-security field, it posed high expectations for the Trinidad Wiseman team. Our task was to understand the current situation and needs and design a new platform based on user needs. The project involved an analyst (AN), user experience (UX) and user interface (UI) designers, developers, and a tester from Trinidad Wiseman.
Growing Pains
In the project's first phase, the analyst and the designers reviewed the existing system documentation. They also interviewed the client's internal stakeholders to create an overview of the current situation and gather as much input as possible on expectations and needs.
Although it is said that getting started is half the battle, the beginning did not go smoothly. The project, which started in the summer, coincided with the holiday period for Trinidad Wiseman and the client, which did not make it easy to keep the planned pace of the interviews.
The planned schedule began to slip; however, every cloud has a silver lining. The Trinidad Wiseman research team evolved a need to get acquainted with all the planned tasks to cover for each other during the holidays. Getting to know each other’s tasks allowed everyone, including AN, UX, and UI, to learn and develop their skills and better understand each role's tasks and task sequences. Additionally, it helped build trust among each other.
Lesson 1: Understanding the roles and tasks of team members builds trust and enables better planning.
Another major obstacle related to information flow soon became apparent. Whereas holiday coverage was eventually successful, communication problems between the design team and the analyst started to occur. Weekly team meetings clarified project developments, but for the rest of the week, specialists tended to talk past each other.
This likely happened because most of the week, everyone dealt with their tasks independently. Communication was individual, one-on-one, and there was no need to burden everyone with all the details. This led to misunderstandings, duplicate activities, and rework. Therefore, we decided to approach collaboration differently to improve teamwork.
Lesson 2: Limited communication within the team leads to inefficiency—to solve this, it is worthwhile to try out alternative ways of exchanging information.
Effective Methodologies
The first simple and effective method we decided to try was regular joint meetings of UX, UI, and AN, where we shared our main challenges, generated ideas, and sought solutions to problems.
We also created clearer boundaries between each other's tasks. Initially, the workflow looked like this: AN and UX worked through the task, prepared the new logic, and then passed the information to the UI designer. However, we soon realised that this way of passing information created many questions for UI, requiring AN and UX to spend extra time explaining and redoing the work.
Therefore, it was logical to involve the UI designer from the very beginning of the analysis process, when the new logic is developed. This ensured smoother and faster communication, collaboration, and design process. Since both AN and UX/UI processes involve similar thinking and methods, collaboration between these roles helped speed up the overall workflow.
Lesson 3: Analysis and design are strongly interdependent workflows. Collaboration must occur both during information gathering and solution generation.
Before the prototype was completed, we gathered input through interviews to understand who the main users of the self-service are and created personas characterising these user groups. These descriptions were created with the involvement of AN, UX, UI, the product owner, and the client's sales manager. Creating personas helped ensure that the entire team (both Trinidad Wiseman and the client) understood who we were creating the platform for.
We identified several user groups and used an importance matrix to prioritise them, helping us determine the users most involved with self-service. The process allowed us to focus and find solutions to the users’ most urgent problems.
Lesson 4: Persona creation allows the team to identify the user for whom the solution is created and internal communication about these personas helps the team stay focused.
After analysis and after the views had been designed, we created a prototype that enabled us to get feedback on the user journey from both the product owner and other client employees. Additionally, we conducted prototype testing with end clients, i.e., the companies purchasing the product. The feedback collected helped us identify whether we had covered the needs of the target group in the prototype and allowed us to identify any remaining bottlenecks.
Lesson 5: Formatting individual views into a comprehensive prototype enables to test and receive better feedback on both design and analysis.
In conjunction with describing user groups, we mapped out self-service user journeys together with the product owner. The information gathered during interviews helped us better understand the user experience, their needs, and challenges at different stages of the journey. Thus, simplifying these stages became easier.
Lesson 6: User journeys reveal new nuances for system design.
The project was also made smoother by the client's product owner, who put aside most of his other tasks and focused on this project. He always promptly answered questions and found solutions. While the product owner and the rest of the client's team were initially somewhat sceptical about the need for certain information gathering, they soon changed their mind.
Lesson 7: The client side’s product owner is of critical importance in every major development project, and active participation provides him with valuable learning opportunities.
Learning Points
Some of the most challenging moments in the project were undoubtedly the holiday periods and team members falling ill. In development projects, the analyst is usually the one who communicates with various stakeholders, including the development team, product owner, and designers. Therefore, her absence makes the workflow more complicated.
We solved this situation through interdisciplinarity and, if necessary, the involvement of an additional analyst. In the analyst's absence, our designers readily worked independently and communicated more actively with the product owner. If UX/UI was absent, the analyst who dealt with prototyping replaced them.
Lesson 8: Interdisciplinarity allows short-term coverage of absent individual team members, but larger absences require additional resources.
After the preliminary analysis, it became clear that the actual scope of the project would be larger than initially planned. This created internal team tensions, and client concerns about extending the deadline, forcing them to revise their plans. This led to clear restrictions on what we would and would not address within the scope.
Many questions and ideas arise in an agile development process. However, if all these solutions are taken into scope, the budget will be exceeded, and the project will run over time. This created a learning point for the entire team to say “no” at the right time to stay within the project scope.
Lesson 9: Adjusting the scope is OK, but learn to say “no” at the right time.
Another learning point was that since the developers did not start working on the project at its beginning, it was later challenging to get designers and developers on the same page. To improve collaboration between the front-end developer and UI, we started conducting regular UI design demos. The goal was to explain design decisions and answer developers' questions.
Lesson 10: Do not delay involving developers, as technical constraints also impact analysis and design.
Conclusion
The project required us to do thorough work to understand the client's business and services. A constant barrage of questions became a daily routine, helping us continuously acquire new knowledge about this complex and intricate business.
Although many learning points were mentioned, this does not mean that we faced insurmountable difficulties in executing the project. Rather, as traditional methods did not work in such a complex project, we had to step out of the box with our agile approaches to organise smoother collaboration.
Thanks to the supportive attitude of team members, open communication, and trust, our analysis and design work began to function better during the process. Regardless of whether we worked alone, with the entire team, or in smaller teams, we always ensured that information flow was constantly maintained.
You can find other exciting articles about the methodologies and approaches of design and analysis in our blog:
Prototyping is More Than Just Folding a Paper Plane
Service Design and the Role of User Journey
