How PD works in Agile team
PD (Product designer) is very important role in software development. They will provide detail requirements specification and business workflow, UI workflow. In traditional software development process, PD will prepare the detail requirement design document before develop team start to make software design. This kind of process will work pretty well if the requirements are clear and relatively stable. Also, there are enough PD resources to make the complex documents. But most of time, we cannot figure out the whole requirements clearly at the start stage. And the scope change is often happen. Another factor is that PD always need to work on more than one product and it is very difficult for them to spend much of time to work out a detail design document. So, what can we do to deal with this kind of issues?
Agile provides a methodology or framework for the team to develop software under the situation of changing scope. By focusing on high value requirement, separating the long lifecycle to be several short iterations and guarantee fully-test in each iteration, it can provide high-quality and expected software to the client. In this kind of framework, how PD works in the team? How they collaborate with others?
To answer this question, the first thing we need to consider is what kind of responsibilities PD will take? From my personal view of point, it is requirements clarification. All of the works of PD actually provide a very detail information to the team about requirements. So, it seems that PD should be better to work with product owner to figure out the scope. The team structure may like this (Figure 1).
Figure 1
In this structure, PD will be the assistants of product owner and help him/her to make the requirements. The product owner will setup product backlog and PD will provide relative design for each user story. The design may include UI, workflow and etc. During the Sprint planning meeting, team will work with PO and PD together to make Sprint backlog. And product designer could show any kind of design to the team to give detail information about the user story. It could be a flash, a MS visio doc, a PPT, a hand-drawing paper, or just write/draw on whiteboard and take a picture. PD can also help to answer any team's questions about requirements during the Sprint implementation.
This kind of process won't ask PD to complete all of the detail design for the whole requirements from the beginning. PD needs to finalize the design for the coming Sprint. That means PD's work will be ahead of team's work at least one Sprint. They can also work with a separate Sprint. The collaboration with Team just like Figure 2 showing.
Figure 2
The benefits of this kind of process are
- Setup very clear responsibilities to each role;
- PD can focus on high priority requirements design;
- Complex design documents are not required and it will enable PD to consider real value things;
- Collaboration between PD and team is smooth and close.
Another very value thing of this process is that, after each Sprint, PD will get a workable software to do the user acceptance test. It will be very efficient way for PD to validate the design. And any issues caused by incorrect design can be found at very early stage. And the issue can be fixed in the following Sprints. This is also very helpful to provide high quality software. :-)
