It depends - on the kind product, on the UI, on the kind of requirements for the next sprint, and also on the people involved and their skills. This is definitely not a "yes" or "no" issue.

User interfaces often have a lot of business aspects as well as technical design aspects - that is why there is the word interface in UI. Since it is the role of the project owner to communicate business requirements to the team, and since often communication works best by examples, scetching ideas for the UI, or ideas to change the existing UI for a adding a new feature - by using whatever tools are available - can be valuable instrument for the PO.

The PO just should not be expected to work out all the gory technical details, and he/she should not expect from the team to build his/her suggestions all literally. Ideally, for design of complex UI requirements, you have some UX experts and someone from the "user's" side in the same room for a discussion. And for certain types of software, the PO here can take the role of a "representative user".

However, in a really agile team, the team should work out the form of communication which works best for the given product and/or environment. If letting the PO scetch the UI works for the team, fine. If that is not necessary or turns out to be less efficient than verbal descriptions, then they should use the latter.

It depends on several factors:

• What kind of product it is
• The UI
• What the requirements are for the next sprint
• The people involved and their skills

This is definitely not a "yes" or "no" issue.

User interfaces often have a lot of business aspects as well as technical design aspects - that is why there is the word interface in UI. Since it is the role of the project owner to communicate business requirements to the team and since communication often works best by examples, sketching ideas for the UI or ideas to change the existing UI for adding a new feature - by using whatever tools are available - can be a valuable instrument for the PO.

The PO should not be expected to work out all the gory technical details, and he/she should not expect the team to build his/her suggestions all literally. Ideally, for design of complex UI requirements, you have some UX experts and someone from the "user's" side in the same room for a discussion. For certain types of software, the PO here can take the role of a "representative user".

However, in a really agile team, the team should work out the form of communication which works best for the given product and/or environment. If letting the PO sketch the UI works for the team, fine. If that is not necessary or turns out to be less efficient than verbal descriptions, then they should use the latter.

It depends.

User interfaces often have a lot of business aspects as well as technical design aspects - that is why there is the word interface in UI. Since it is the role of the project owner to communicate business requirements to the team, and since often communication works best by examples, scetching an idea of the UI, or ideas to change the UI for a adding a new feature, by using some drawing tools can be valuable tool for the PO.

The PO just should not be expected to work out all the gory technical details, and he/she should not expect from the team to build his/her suggestions all literally. Ideally, for design of complex UI requirements, you have some UX experts and someone from the "user's" side in the same room. And for certain types of software, the PO here can take the role of a "representative user".

However, in a really agile team, the team should work out the form of communication which works best for the given product and/or environment. If letting the PO scetch the UI works for the team, fine. If that is not necessary or turns out to be less efficient than verbal descriptions, then use the latter.

It depends - on the kind product, on the UI, on the kind of requirements for the next sprint, and also on the people involved and their skills. This is definitely not a "yes" or "no" issue.

User interfaces often have a lot of business aspects as well as technical design aspects - that is why there is the word interface in UI. Since it is the role of the project owner to communicate business requirements to the team, and since often communication works best by examples, scetching ideas for the UI, or ideas to change the existing UI for a adding a new feature - by using whatever tools are available - can be valuable instrument for the PO.

The PO just should not be expected to work out all the gory technical details, and he/she should not expect from the team to build his/her suggestions all literally. Ideally, for design of complex UI requirements, you have some UX experts and someone from the "user's" side in the same room for a discussion. And for certain types of software, the PO here can take the role of a "representative user".

However, in a really agile team, the team should work out the form of communication which works best for the given product and/or environment. If letting the PO scetch the UI works for the team, fine. If that is not necessary or turns out to be less efficient than verbal descriptions, then they should use the latter.