Product Design in Agile Methodology

DZone 's Guide to

Product Design in Agile Methodology

You can't build an well-designed project with two teams operating in silos. Learn how knowledge-sharing and collaboration are the keys to good design processes.

· Agile Zone ·
Free Resource

The standard design process divides the product preparation period into various phases, which (depending on what methodology was adopted), separates interface design and its implementation. The combination of both phases and the creation of the one team working in Agile methodology allows us to save time, speed up the implementation process and improve the quality of a product's usability. This occurs when the collaborative team is competent in both design and implementation.

Not sharing either knowledge and/or experience during the completion of tasks in both these categories may result in the preparation of an interface whose implementation will cause unnecessary problems for programmers — this is the most likely and easiest problem to avoid. Similarly, the need to modify accepted requirements of a project (due to the change in the scope or mode of application operation) increases the number of iterations and corrections at every stage of the process.

After identifying such issues in previous projects, the importance of including people with project competencies and experience in Agile methodology in the development team is obvious. Working on UX and UI applications in the Scrum formula and its appropriate synchronization with the ongoing implementation at that time guarantees an immediate increase in the success of implementation and improved quality control in the visual layer.

Scrum Methodology in Product Design: What It Looks Like in Practice

The length of the product design sprint is usually adjusted to the length of the standard development sprint. Using the same tools to manage tasks, each planning session defines project goals, their priority and amount in a given sprint for a given number of people in the project team (usually there are 1 to 3 teams, depending on the complexity and development of the project, with competences in analysis, UX, and UI design and independent work organization).

The most important assumption is to plan the work of the product design team at least 1 sprint in advance to that of the development team — to which the planning and backlog grooming is most often used. Thanks to this, everyone gains a wider perspective than just their current tasks, developers gain the possibility to take an active part in the process of usability and interface design, while designers get clear feedback in the context of the feasibility of the developed projects and their usability.

Depending on the complexity of the project, the demo takes place with the help of a clickable prototype or presentation of individual components or views in the presence of the whole team. Tasks that have not been accomplished pass to the next sprint. The main goal is always to provide developers with the materials to work well in advance, including usability testing and gathering feedback from users and customers.

Client-Centric Design Process

Synchronizing the adaptation of Agile methodology to the design process and collaborative work with the development team (but with appropriate methodologies), automatically changes the perception of the entire project. A common definition of a backlog, a lively discussion about functionality and people with different competencies focused on achieving the same goal — providing the best possible quality of implementation — is definitely the recipe for success. This unusual approach allows us to focus on details and individual components of the project at hand, and also ensures that throughout the implementation, the main assumptions are remembered and a wider perspective maintained.

The use of the Agile methodology in the Product Design process also has one additional advantage, which is the close cooperation and frequent testing of the prototype with target users. This is due to the fact that we mainly work on the creation of a UI system that will be easily adaptable for different functional scenarios, and that concentrates on understanding users to solve and satisfy their problems and needs. This approach that focuses on users guarantees that the system we develop will also be easily adaptable in other, alternative applications, should there be a need to develop them (a good example here is LindaAI).

One of the most interesting and effective exercises that should be used in the analysis phase is User Story Mapping — this is regardless of whether we are working on a new product, where we focus on solving real problems of users, or we are working on a new instance of an existing project, where our goal is to make sure that our changes and introduced features have a positive impact on business indicators and user behavior.

This exercise allows us to define:

  • Who is the intended user/recipient of the product;
  • What needs to be done with the product that is being worked on;
  • What is the implementation of key scenarios.

This is done with the help of a whiteboard, sticky notes and the joint work of the entire team. The actions performed by the user of our application are divided into the next steps of the project so that we get accurately mapped functional paths in the product, with selected MVP, division into releases and the ability to easily transfer data from the analysis phase to the backlog. What is more, the effects of our work can also be used to determine the conversion hopper (by identifying the most important activities on the site), control before extending the scope during work (thanks to easy migration to the backlog) and guarantees clarity in the common understanding of the product throughout the team.

Cross-Functional Teams

It is worth noting that project competencies between the development and design teams are purposely reiterated throughout the duration of the project. In the phase of analysis and research, the technical insight of developers is undoubtedly a great value, which at the start, limits the number of potential problems. Most often, immediately after the analysis phase, the level of project work increases, so that the development team has already started with a specific number of ready-and-tested design solutions and that, thanks to the aforementioned synchronization throughout the implementation, the designers can deliver further modules and components for implementation. The intensity of design work usually decreases at the final stage of implementation, where designers can take care of quality control. The whole cycle is repeated for each subsequent release of the product.

We must always be ready to change priorities. The ability to analyze the visual layer and support in improving usability often requires additions to the standard scope of work in a given sprint of time, which will be used to help the development team solve current problems during implementation. Designers and analysts very often have the widest view of the project, so their competences can naturally expand — but we should always be focused on the goals defined within the sprint.

In Espeo we use the following set of tools:

Slack as an everyday and basic communication channel inside the team (except for project meetings)
inVision as the main tool for building prototypes of interfaces and testing them with users
Zeplin as the main tool for the transfer of materials for the implementation of the development team

Summing Up

The adaptation of the project team to Agile methodology and the creation of a collaborative work environment, where there is the smooth exchange of information, had a positive impact on the quality of implementation (not only in the visual layer).

Improving this process is the key to building a complete set of competencies in a team that is able to efficiently deliver well-prepared solutions, focused on meeting the goals set by business and solving problems faced by users.

UX, agile, collaboration, communication, design process, product design, teamwork, user centered design

Published at DZone with permission of Ariel Hajbos , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}