5

Is it typical that a Product Owner (or even a BA) creates a high-level prototype/wireframe of a system based on the requirements document to ensure that the requirements are clear enough to start working on user stories for the UX & development teams?

I am currently being 'promoted' from a developer to UX designer and tasked with creating mock-ups direct from a requirements document, but the document is unclear on several aspects and have spent most of my time thus far doing what I would consider more PO/BA work of clarifying basic things in the requirements document. I am aware that this process is iterative and the UX/dev teams will probably need to discuss/clarify items during design & development, but is there some sort of 'minimum viable requirements' stage the PO is expected to deliver before this happens and how is this determined?

Edit for clarification: prototype here refers to a high-level visual aid created in something like Sketch, rather than a first revision implementation in code. In addition, in my example, no user stories exist, only a raw, incomplete requirements document.

Improve this question
1
  • Every company is different. In general, though, yes, at a minimum sketches or line drawings are made before any code is written.
    – Robert Harvey
    Commented Mar 12, 2019 at 14:54

5 Answers 5

Reset to default
6

I would say no. Considering that the PO should focus on defining business value. Having the PO creating prototypes kind of influences the teams development in technical terms. I think it is important that the business value is well defined, so that the team can implement it. Also, the act of creating a prototype is a learning experience, to figure out how to implement the business value, maybe even what the business value is. It would be a missed opportunity for the team not to do the prototyping. The interface between the team and the PO is the user story and the defined business value. Having the PO do the prototyping kind of softens that up.

This sounds to me like the PO used to be a developer, I've had that experience.

It is my believe as a scrum master, that the PO should NOT develop. Focusing on defining business value and maintaining a backlog is the product owners way of communicating with the team. (of course verbally all the time too, after all we are using agile principles)

Improve this answer
4
  • Just to clarify that in my situation, the PO isn't saying they should create the prototype. It is more me asking as a UX/UI developer what I should be expected to consume to create my own mockups - is this a requirements document, user stories, or both - and in what state should these deliverables be in before being handed down from the BA/PO? My thinking that a PO delivering a prototype would ensure the requirements are in a decent state for the design & development teams to further refine.
    – doogiehowserone
    Commented Mar 6, 2019 at 11:15
  • I think the user stories should be enough. I can't emphasis enough that whatever you produce, should fulfill a business value. (I've used that phrase a lot). How you do that, is up to you. You have to find that solution. By defining that business value, you can work story by story and create sort of a business value stream. If your solution is sufficient, the PO will tell you.
    – HankTheTank
    Commented Mar 6, 2019 at 12:19
  • 1
    Ah ok - I think the crux of the issue is that no user stories have yet been generated and I am the one who is refining the requirements and almost implicitly writing the user stories from the mockups I am tasked to create, rather than the other way around with the PO creating the stories first. I suppose I can phrase it another way: is it acceptable for me to push back on creating mockups without explicit user stories (crafted by the PO) in place? (edit: thanks for the input)
    – doogiehowserone
    Commented Mar 6, 2019 at 12:22
  • 1
    I know that "process". It is certainly not best practice. Nothing speaks against creating user stories in the team, including the PO. but at the end, it's the user stories that you have to fulfill. Like: I as a user want to be able to export our bla into a csv file so that I can import it into Excel. How you achieve that is your problem. By specifying WHAT instead of HOW, you can implement the minimum viable approach, and deliver some actual value fast and sufficient.
    – HankTheTank
    Commented Mar 6, 2019 at 12:27
3

The PO should do whatever is necessary to ensure that the story is clear enough and well-defined so that the team can work on it. If that means screenshots of similar products, wireframes, doodles drawn on the back of a napkin, a wall of text, or whatever, so be it.

This will depend quite heavily on the complexity of the product / feature, as well as the experience of the team. The PO's vision of how the feature will look / work will also play into this. A way for the user to input a Yes/No choice can be implemented dozens of ways, so if the PO has a specific idea in mind, a wireframe or mockup can aid in that clarity.

And, it will almost certainly be an iterative process (at least to start). The first go around at the story may be completely unclear to the team, so some details are added or clarified. The second go around is still a bit unclear, so the PO adds a mockup, and then it becomes clear enough for the team to score and work on.

All that said, what matters in the end is the acceptance criteria. Mockups and screenshots can help guide development, but the team may use a different approach to satisfy the acceptance criteria than what the PO had in mind.

Improve this answer
3

No the PO shouldn't be drawing designs and really you don't want them to.

For example, lets say im the CEO and I want a website to sell the company's widgets god dam it!! It's a small company so I am the PO on the project. There are two ways I can go

  1. Specify only high level business requirements and let the experts fill in the details

    • Requirement A. This site Has. To. Sell. Widgets!
    • Requirement B. You can only have £100 per annum for hosting!

  2. Specify exactly what I think will make a good site for selling widgets

    • Requirement A. part 1 section iii : The site must have the company logo in gif format with animated flames. it must fill the users entire screen
    • etc ...

With method one I trust the marketing and UI guys to come up with amazing flaming gif ideas that are proven to sell the most widgets

With method two I don't really need the marketing and UI guys. Any fule kno flaming gifs are the best and the devs will make it exactly to my specifications while charging me a daily rate.

Improve this answer
3

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.

Improve this answer
3

As the Product Owner is typically on the business side of things, he likely wouldn't be able to produce any code in any way, perhaps not even an elementary frame, but he shouldn't be expected to.

You can ask him to draw lines on a board (or into something like Visio), but asking him to do any technical work doesn't make sense. However, you could develop 'paper prototypes' together on a board with you drawing what you understand and him correcting you according to what he meant or his preferences.

Improve this answer
1
  • Not wrong, but I guess you missed the edit to the question.
    – Doc Brown
    Commented Mar 6, 2019 at 16:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.