Transcription
We can continue with more terrible experiences. We will talk about teamwork, how components interact, the roles of analysts and designers, and this will be our case study based on our own experience.
So, let's start. My name is Sograt, and I work at a company called RAVEN SIN as a business analyst. I started in business analytics and gradually grew into my role. Now, I sometimes take on the responsibilities of a product manager. I have been with the company for almost four years.
My colleague, who also works at RAVEN, has been with the company for almost four years as well. Currently, I am part of a team of designers, which includes three other people besides myself. We are working on a medical project, and we are also involved in another project as just analysts and designers.
Our contact information is on the slide, so feel free to reach out to us if you have any questions after our presentation.
Now, why did we decide to touch on this topic? Very often, designers and analysts struggle to agree on their areas of responsibility. I know that there are various disputes about who should do what, and we also started with some minor disagreements on this matter. I think this will resonate with many of you.
The next point is the imbalance of workload between teams. It often happens that the business analyst team is overloaded while the design team has some capacity to assist, for example, the business analysts.
Another issue is that designers are often perceived merely as illustrators. They tend to forget about the UX part and focus solely on visual design. This is indeed a part of a designer's job, and I often feel hurt when the two components are overlooked.
Additionally, a common problem is that design solutions do not meet the set tasks. Designers often like to fantasize and significantly expand the scope, which leads to the need to cut down the work that has been done.
I believe there are various reasons why it is important to discuss the interaction between business analysts and designers. Each has their own perspective, which varies depending on the project.
To add to my current team, we have been working together for about a year. We started with a heavy workload on the design side, and the designers were struggling to keep up. Now, we have managed to balance the process, and we are moving forward in parallel with the business analysis team.
Previously, we faced the issue of design solutions not aligning with the set tasks, and the requirements were not clearly defined. We have since addressed this problem.
We will briefly discuss the structure of our process, how we work through ideas or problems in the project, and outline the responsibilities of analysts and designers at each stage of idea development.
At the end, we will share our conclusions and recommendations.
To provide some context and avoid unnecessary questions, we are developing a medical product for the U.S. market. Currently, our team consists of four business analysts and three designers. The system comprises several modules, one of which already has users and is live, while the others are still in development.
Importantly, the entire product team is located in our country, and we do not have a clear client concept. This means we make product decisions ourselves without needing to coordinate with any third parties.
So, let's start with the first point: everything begins with gathering requirements. Traditionally, the business analyst team is responsible for this, but designers can also get involved at this stage to assist the business analysts.
When it comes to collaborative activities, designers often help us create interview plans and conduct interviews with the target audience. They also assist with competitor analysis, looking at how similar problems are solved in other systems.
Next, we search for information from open sources, such as Google, or review conference summaries. We also engage with other authors to gather requirements, both from internal stakeholders and external ones.
It's worth noting that sometimes the design team takes the initiative and starts working on a solution before the business analysts have fully defined the requirements. They can then forecast what is missing and what needs to be added from a requirements perspective.
We have a clear division of responsibilities regarding who is in charge of requirements, but the business analysts generally lead this effort.
Once we have gathered the requirements, we move on to the next stage: defining the design task. Here, it is crucial to immerse the team in the context and describe the problem.
We find that flowcharts and diagrams work well for this purpose, as do story maps. These tools are easily understood by both the development and design teams, as well as the users.
Another important point is that analysts do not come to designers with solutions; they always present the problem. This is a common issue where analysts might say, "I have everything figured out; just draw a couple of screens," or "I have already designed this screen; just make it look nice."
This raises the question: what do you expect from designers when you come to them with a ready-made solution? Do you want them to just color it in? This is not how task definition should work.
For example, we had a feature for transferring a doctor's appointment. Instead of saying, "I have everything figured out; we need to design this button," we should present the problem: "Currently, to transfer a doctor's appointment, the user needs to open another tab, find an available time slot, and ensure there are no conflicts."
We also provide input data that is important for the doctor to complete their task. Ultimately, we ended up with three solutions that we could review as a design team and choose from.
In this context, we prepare user story maps, activity diagrams, and other artifacts. We always provide context, detailing the case we are working on.
The design team prepares these artifacts, and they can vary in size depending on the functionality we are working on.
I wanted to highlight one example that the design team loves: we describe the logical data model, detailing the objects in the system, their properties, and how they are interconnected.
It is essential for designers to understand not just how the interface works but also how the system operates, what objects it consists of, and how they interact.
There is no strict division here; both designers and business analysts can explain how the system works. For instance, we often use a tree diagram to describe the logical model, which can represent both page structures and object hierarchies.
Moving on to the next stage, where designers are maximally involved, we develop the design concept. This includes a comprehensive description of the functionality to be implemented.
We work on not just mockups but also interactive prototypes, user flows, and information architecture. We also include textual descriptions, tables, and diagrams explaining how the functionality will work.
Designers describe their solutions in words so that any analyst or designer who joins later can understand the context.
Typically, one business analyst and one designer work together on a specific functionality, but this can vary depending on the project.
During the design concept development, the designer frequently returns to the business analyst to ensure alignment with the gathered requirements.
We also strive to test our solutions as we go along. Currently, our primary testing method is corridor testing, and we conduct usability tests whenever possible.
We create testing scenarios that outline the tasks we give to our users. The business analysts play a crucial role here, as they often consult with doctors or stakeholders and can demonstrate design concepts and gather feedback.
I wanted to show an example of how we organize our mockups. We do not create mockups in isolation; the designer addresses the task at hand. We write down the task in text before starting the design process.
In terms of recommendations, we ensure that the proposed solutions are well-documented. The design team often communicates directly with the business analysts during the concept development process.
If there are significant questions, we usually have a call, but for smaller issues, we can resolve them through comments.
The design concept approval stage follows. After completing the previous stage, we present our work to the team, which typically includes the engineering team and representatives from the target audience.
It is crucial to provide everyone with context regarding the problem or idea to receive quality feedback. The team is accustomed to asking questions and first seeks to understand the problem we are solving rather than questioning the design details.
The approval session usually starts with a presentation of the mockup, beginning with an overview of the problem to ensure everyone understands the context.
Once we approve the design concept, we may cycle back to the previous stage of defining the design task if needed.
The next stage involves defining the task for the engineering team, where responsibilities become clearer.
In terms of collaborative activities, we present the solution together, whether it be the designer or the analyst, as we work in the same context and can support each other.
Business analysts create user stories with acceptance criteria, focusing on user expectations rather than specific design elements.
Analysts also handle writing texts for notifications and messages, serving as the source of truth in this case.
We compile a list of notifications and reference them in our requirements. Analysts are also responsible for updating these after the development team reviews the user stories.
Despite the similarities in our activities, analysts prepare user stories while designers prepare mockups. Before handing over functionality to the development team, we ensure all mockups are finalized, with no unresolved issues.
Both designers and analysts are responsible for writing interface texts, and we collaborate closely on this.
We have reached a point where designers can prepare user stories themselves, especially for changes that only affect the interface.
This collaborative effort reduces preparation time and allows business analysts to focus on other tasks.
We always describe the context and provide background information, linking to mockups and detailing the requirements.
In the next slide, you can see examples of our notifications, which help maintain consistency in messaging across the system.
If changes occur, we can quickly identify where the impact lies.
Moving on, we have the development phase, where the development and testing teams can reach out to designers or analysts for questions.
Typically, they approach analysts for logic-related queries and designers for interface-related questions.
If needed, we sometimes arrange joint calls for discussions.
The task is considered ready when the business analysts verify that the requirements align with stakeholder expectations, and the design team checks the implementation against design requirements.
We have a clear division of responsibilities: designers are accountable for design, while analysts handle requirements.
In conclusion, we start with gathering requirements, then move to defining design tasks, developing design concepts, and approving them. This process is cyclical, allowing us to revisit stages as needed.
The next steps involve defining tasks for the engineering team, followed by discussions, development, validation, and verification.
We can cycle back to the requirements stage as necessary.
I think the key recommendations are to agree on areas of responsibility upfront, so everyone knows their roles.
These boundaries should be flexible; if the workload shifts, responsibilities can be adjusted accordingly.
It is essential for both analysts and designers to be involved at all stages of feature development to avoid misunderstandings and distribute the workload effectively.
This mutual understanding allows both analysts and designers to know how the system works and to address questions collaboratively.
Lastly, it is crucial to avoid duplicating information in requirements. We have faced challenges when writing policies and specifications, which complicated making changes.
By not duplicating information, we streamline the process and reduce the time spent on revisions.
Communication is a powerful tool. Analysts and designers can be great allies.
When I ask my team what they appreciate about working together, they often mention how great it is to collaborate with business analysts.
So, good luck with your processes, and remember not to argue with each other. Thank you, everyone! I think the presentation turned out great.