3

We have several development teams, a Product Owner team and a Design team.

The PO team generally works with the design team whilst writing the user stories and acceptance criteria and then typically developers start getting involved in building it.

The problem we have found is that sometimes the PO doesn't think design needs to get involved and does not involve design and it goes right through development without design being involved.

Does anyone have a solution, reading material or ideas of how we can solve this problem.

I am thinking design needs to be working alongside front end developers but need some advice.

Improve this question
3
  • Why does your first example not involve developers until after the design either? How would you consider implementation feasibility of your design without consulting them at an earlier stage? The product owner shouldn't be dictating which depts. do what that should be a matter of policy that both are represented through planning stages.
    – JamesRyan
    Nov 17, 2015 at 11:37
  • Hi James. Thanks for your comment. Unfortunately I can't understand what you are saying. Could you perhaps rephrase?
    – TheLearner
    Nov 17, 2015 at 11:53
  • I am saying the PO shouldn't say who gets involved. Everyone should be involved by default.
    – JamesRyan
    Nov 17, 2015 at 12:37

4 Answers 4

Reset to default
1

This is probably THE scenario most of the designers already have been confronted with at least once in their career. Even if it appears to be a relatively small issue, I think it is not. What I found is that there are several topics that are not so clear on the first hand. Some or all of the following scenarios can be hidden in this issue:

  • PM/PO has to be productive and has to hand over results for justification
  • PM/PO has (no) design background and thinks she can decide visual directions on her own, because it is only "a small issue"
  • Development team does not only want to execute but be creative themselves
  • Designer is not good / not communicative / takes too much time / does not deliver the right results for some tasks / ...
  • ...

What I want to point out, is that often feelings are involved, desires to participate in some kind of way. The only (and believe me if I tell you that I quite tried some solutions) permanent working solution for that problem that I found was:

All tickets that involve visuals need eyes from a designer. All tickets that also involve development require eyes of a developer. Not at the end, but at the very beginning.

With this, the PO can decide how much work at max has to be done, the designer can decide if she needs to be involved, the dev can decide if the concept can be executed and how much time she has to allocate. With this you can manage expectations best.

If you, on the other hand, are not doing this, you give the PO/PM the task to decide which visual is "good enough" - and this is not part of her expertise, since, well, she is no designer. If you decide on features that you want to do and never asked a developer, you might run into investing design time for a feature that can never be executed.

So if you are using JIRA/Trello/Asana or any ticketing tool alike: Always include a step after the briefing, where some design team lead decides: "This is a design topic" or "This is no design topic". With this, everyone can be sure that all relevant personell has seen the issue, whilst respecting each ones expertise. And it is not even much more work to do (2-4min per ticket regularly)

Improve this answer
0

One model you can consider is stakeholders are the Design team's users too. Treat them like users. Make them the centre of your thinking and use the same sort of tools to create a great colleague experience. To get CX and UX right you need to include the Colleague experience; if your colleagues aren't supporting design you will not be able to deliver great experiences for users.

You will likely find that the attitude towards design in the organisation is top down. Educate your key stakeholders and let the value trickle down. - According to Forrester (CXEU2015) 90% of CFOs think that Customer and User experience teams are cost centres. Part of your team's job is to show how you create value and profit.

Improve this answer
2
  • When you say stakeholders, are you referring to the POs?
    – TheLearner
    Nov 17, 2015 at 12:02
  • While you are right in some way, I am not thinking the same. While yes, the stakeholder / PM / PO is responsible for the project and has to have some kind of affinity to designing it, he/she is not an expert in neither dev nor design nor marketing, which is why she has a team of experts around her to fulfill the tasks. A PO should decide on priorities, loads, take a role of steering. She can never know if the designer would have said "did you mention to use the grey line that we had in the other design?" - and bam, we have a styleguide issue by just jumping over the designers.
    – Jan
    Nov 17, 2015 at 12:44
0

I have been through this period while I was the PO/PM for a renowned brand. There were this problem where teams didn't have the tenacity to talk to each other (attitude problems/work pressure/lack of time) although cross-functioning was an absolute necessity because of the demand to work in a collaborative environment. Mails, meetings, con-calls didn't solve the issue. The primary sufferer was the Product team who was answerable to the management for the ROI every feature implementation yields. I, after consultation with the management came up with the following processes:

  1. PO used to upload the main planned project doc in the internal knowledge base and suggestions were sought from all stakeholders (Tech, design, ops, support). TLs used to revert with suggestions/queries/reviews in forums or digitally sign the master doc as a sign of acknowledgement/acceptance.
  2. If needed mails or meetings were held at definite intervals to sort out any issues, PO being the convener.
  3. Best practices docs needed to be digitally signed by every stakeholder (along with PO) to ensure that the internal policies were maintained properly.
  4. Few other key steps were also taken which need not be discussed here.

Slowly and steadily the once separate team became a cohesive unit which ensured that the UX, CX, Tech issues are sorted out prior to the implementation stage.

After a couple of months, an internal study revealed that the other stakeholders including design team (who might have been neglected) have made some key contributions/value-additions (in the form of suggestions) in the planning stage itself thus improving the overall UX and CX.

What I would suggest you is to create an architecture of participation and create a seamless platform internally in the form of internal employee friendly policies so that none holds absolute authority to bypass others. Let ego gets defeated so that collaboration wins! And let brownie points gets equally distributed.

Improve this answer
0

  1. Involve every discipline at the discovery and definition stages. Make it clear that collaboration is expected from all parties.

  2. Inject yourself into every product meeting. If they won't put you on the list, just show up. Very few people have the social courage to actually kick you out.

  3. Bring value. Just as you'll value input from engineering, they'll begin to value the insight you bring.

  4. Get out together. Do team lunches or beers or mountain climbing. Whatever the group can connect over.

The whole thing is a process of socialization. They won't involve you if they don't understand how you'll make their product better.

Improve this answer

Your Answer

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

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