Should UI/UX designers work directly with the Product Owner?

Question

I am currently a proxy PO, although my main role is as a Scrum Master but I help the PO with grooming the backlog.

We are developing a start up product - the PO wants me to manage everyone in the Scrum team from top to bottom, this includes the UI/UX designer.

Whilst doing this, I am finding that guiding the UI/UX designer is extremely challenging since the PO wants work done in a very specific way and it slows the process down of getting the designs approved from going back and forth with the PO for approval. Leaving the PO frustrated if work has not been delivered quick enough.

I have suggested to the PO that it is pointless that I work with the UI/UX designer, and it is better if he works with him directly. Given time constraints he is finding it hard to find the time.

What is the best way handle this situation?

Thanks

Answer 1

Leaving the PO frustrated if work has not been delivered quick enough.

better if he works with him directly. Given time constraints he is finding it hard to find the time.

Have you juxtaposed these two items for him and pointed out the contradiction?

It might help to try a very incremental approach. Ask if he can find just 15 min in his schedule to sit with the UX designer; then get the designer to do serious prep for that 15 min so it can be very efficient and a positive experience for the PO. (eg, mock up several options to present to get feedback & start conversation) Then make sure the designer quickly delivers at least some piece of some thing that the PO approved.

That could be evidence for a "bang-for-the-buck" conversation with the PO: "That investment of 15 min of your time produced great results! I think we can build on that, what do you think?"

Working with customers/POs who are overworked/overscheduled can be challenging. I have had good results by demonstrating that I clearly understand and respect their limited availability, and doing everything I can to make sure we use their time as efficiently as possible.

Answer 2

As CodeGnome pointed out in the comments, enforcing the roles and responsibilities of Scrum will go a long way to increasing collaboration between the team.

Although this isn't an answer to your question, first, if you're being asked to "manage" the team, then by Scrum's definition you are not the ScrumMaster. The ScrumMaster's role is to teach the Scrum Team (Product Owner and Development Team) the correct way to do Scrum and facilitate all of the meetings while leaving leading the meetings up to the team.

When it comes to team structure and who collaborates with the product owner, Scrum says that every Development Team should have all of the skills necessary to produce a working product increment. Therefore, a UX/UI designer could collaborate easier with the Product Owner and those writing the code if he/she is working on the Development Team. Moreover, the UX/UI designer, as well as any member of the Development Team, should be talking directly to the Product Owner, without go-betweens.

It sounds like the problem may be that the Product Owner is too busy. As ScrumMaster, it's your job to help this person find out what tasks are important to being an effective Product Owner and then finding ways to delegate work that isn't related to the product to others. As a key member of the Scrum Team, the Product Owner should be available to the team to clarify requirements, such as what the UI should look like, and to answer questions the Development Team has about the forecasted work.

For more information, see the "The Overworked Product Owner" section of "Common Product Owner Traps" by Roman Pichler.

To avoid an overworked product owner, try the following: First, free the individual from all other responsibilities. Start with the assumption that being a product owner is a full-time job, and that one product owner can look after only one product and one team. Second, ensure that the team makes time in every sprint to collaborate with the product owner. Scrum allocates up to 10% of the team’s capacity in every sprint for supporting the product owner (Schwaber 2007).

Answer 3

I think we've all been in this kind of situation before. The proper way to sort this one out is to have the PO work directly with the development team. You'll be out your proxy role and the speed of development should accelerate significantly.

The next feasible option is to have the PO out of the loop completely. That means you'll be the one making the decision about the UI/UX design. You don't have to go back and forth to the PO and the speed of development might accelerate. It's just that there's a high risk of having a disappointed PO because the design doesn't suit his way.

However, if I understand your situation correctly, both of the above options can't be done. In this case, you can try to minimize the iteration in the design development and approval loop. You need to tell the PO to be less specific about the design so that development can move faster. You might even try suggesting a limit of the iteration in the loop. This way the PO (and everyone involved) knows how many times he can provide an input before the design is finalized. If the PO agrees, you won't have to go back and forth as often as before and, hopefully, the speed of development might accelerate.

EDIT: Just to clarify things. I'm all the way with enforcing Scrum roles and responsibilities. That's why I put option 1 and option 2 at the top. However, in occasions where option 1 or option 2 is not feasible, I'd go with option 3.

Answer 4

To me it seems there are 2 tasks here:

1. Managing the UI/UX designer's schedule
2. Approving the UI/UX designer's work

You are being asked to manage the UI/UX designer's schedule - and that includes ensuring the UI/UX design is approved by the PO.

Approving the design is not your job (so it seems), so don't do it. Make sure the UI/UX designer gets the PO's approval in a timely fashion.

If the PO then decides it's your job to approve the UI/UX design, then it becomes your job and the PO is taken out of the loop.