Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (7)
Ähnlich wie Everybody Wins: How to Collaborate with Engineers and Product Managers
Ähnlich wie Everybody Wins: How to Collaborate with Engineers and Product Managers (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Everybody Wins: How to Collaborate with Engineers and Product Managers
- 1. Andrew Yip | @ayip Andrew Yip Director of User Experience & Product Management GTxcel @ayip Everybody Wins: How to Collaborate with Engineers and Product Managers
- 2. Andrew Yip | @ayip Overview 1. The job is to build successful products 2. Define the product together 3. Look at all the constraints 4. Tips for reducing conflict with engineers 5. Audience discussion
- 3. Andrew Yip | @ayip My Background ● Studied computer science at MIT ● Worked as a front-end developer for 7 years ● Masters from Bentley UX program ● Now I run UX and Product Management at GTxcel ● Using Agile methods since 2006
- 4. Andrew Yip | @ayip I Products
- 5. Andrew Yip | @ayip - Marty Cagan “The job of the product manager is to discover a product that is valuable, usable, and feasible.”
- 6. Andrew Yip | @ayip Define the product together It’s the PM’s job, but they need input from UX and Engineering to make it usable and feasible. Creative people get frustrated if they think they’re building the wrong product. That includes Engineers.
- 7. Andrew Yip | @ayip The pass-through product manager “So what you do is you take the specifications from the customers and you bring them down to the software engineers?” - Bob Slydell, Office Space
- 8. Andrew Yip | @ayip The pass-through product manager You need to find out where the requirements are really coming from: ● Customers? ● Sales? ● Marketing? Offer to help your PM gather requirements or to wireframe early product ideas.
- 9. Andrew Yip | @ayip The pass-through product manager Have your PM put you in touch with the internal stakeholders driving the requirements. Ask for access to customers to help understand their actual needs. If user research is new to the organization, start small and show results.
- 10. Andrew Yip | @ayip PM is focused on company goals Make sure you understand the business goals and PM metrics for success. Frame your user advocacy in terms of the business goals. It’s tougher if there’s conflict between the business goals and the user goals.
- 11. Andrew Yip | @ayip How to involve engineering Consult the Architect or Lead Engineer early about the product. The Architect is going to be a lot happier if they are part of conceptualizing the product. Other engineers are more likely to buy in if they know the Architect was involved early on.
- 12. Andrew Yip | @ayip How to involve engineering Small changes in product direction can have a big impact on feasibility. The more novel the technology, the more input you need from engineering.
- 13. Andrew Yip | @ayip Look at all the constraints
- 14. Andrew Yip | @ayip Different disciplines tend to have very different criteria for what makes a good solution to a particular problem.
- 15. Andrew Yip | @ayip UX Design Constraints Some examples: ● Discoverability ● Efficiency ● Consistency ● Localization ● Target platform(s)
- 16. Andrew Yip | @ayip Product Management Constraints Some examples: ● Time to market ● Feature trade-offs ● Completeness of product offering ● Competitive landscape ● Future direction of the product
- 17. Andrew Yip | @ayip Engineering Constraints Some examples: ● Performance ● Scalability ● Complexity o Time to implement o Reliability o Maintainability
- 18. Andrew Yip | @ayip That’s going to require a lot of collaboration! If the product is going to be valuable, usable and feasible... we need to consider all three sets of constraints.
- 19. Andrew Yip | @ayip Ask “why?” A lot. You need to get past the initial “No, that won’t work.” Get them to consider their answer and find out why your solution fails according to their constraints. What changes could be made to satisfy their concerns?
- 20. Andrew Yip | @ayip Share in-progress designs Explain your design and the constraints. Especially helpful when you are trying to choose between several options. PM helps you understand relative priorities, Engineering helps you understand relative costs.
- 21. Andrew Yip | @ayip Revealing assumptions Sometimes team members bring their own sets of assumptions to the discussion. Talking through the constraints is a good way to uncover any differences. Revisiting assumptions can help you uncover new solutions.
- 22. Andrew Yip | @ayip It’s not design by committee Great design benefits from having an auteur. So does great software architecture. Resolve disputes with data where possible. Defer to the domain expert otherwise.
- 23. Andrew Yip | @ayip Payoff: A great product team Product + UX + Architect is a really powerful combo for problem solving. All team members seek input from other disciplines early and often. Engineers are excited to ship a high-quality product.
- 24. Andrew Yip | @ayip Tips for reducing conflict with engineers
- 25. Andrew Yip | @ayip Don’t interrupt engineers too often Engineers need to be able to focus for extended periods. The cost of “context switching”
- 26. Andrew Yip | @ayip Adjust your communication style Some engineers want to see a pixel-perfect mockup before they write any code. Others can start with a wireframe and work out the final visual design with you later. Be sensitive to preferences for in-person vs. IM vs. email vs. ticket.
- 27. Andrew Yip | @ayip The right feedback at the right time Functional feedback needs to come early. Visual polish can usually wait until later. You’ll develop a better feel for this over time. Remember to give positive feedback too!
- 28. Andrew Yip | @ayip Handling feedback on your designs Sprint reviews open the product up to feedback from a larger audience. Use these sessions to identify problems. Figure out the solutions later, on your own or in a smaller group.
- 29. Andrew Yip | @ayip Build in time for UI polish Understand the release cycle and get your feedback in at the right time. Establish a strong relationship with QA.
- 30. Andrew Yip | @ayip Prototypes for collaboration Great vehicle for cross-functional collaboration. Particularly useful if technology is novel or you expect a lot of iteration. Provides opportunities to usability test and iterate before building the actual product.
- 31. Andrew Yip | @ayip Get to know your medium People often ask me if they should learn to code… Learning CSS can be helpful for working out the details of front end design. The most important thing you can bring to the table is some understanding of what’s possible.
- 32. Andrew Yip | @ayip Impossible vs. possible Impossible Possible
- 33. Andrew Yip | @ayip Strong personalities Some people are better suited to product definition than others. Find ways to balance strong personalities.
- 34. Andrew Yip | @ayip Get involved in the hiring process Chance to set expectations and assess their openness to collaboration. Look for engineers who are passionate about shipping great products. Make sure you get to interview front-end developers.
- 35. Andrew Yip | @ayip What about usability testing? Covered by people that know more than me… If introducing to org, start small and show results. Get people to attend some usability tests!
- 36. Andrew Yip | @ayip Andrew Yip Director of User Experience & Product Management GTxcel @ayip Thank you!
Hinweis der Redaktion
- I’m going to save some time at the end to take questions and comments from the audience. There’s a lot of experience in this room, and I’m sure you will all have your own insights to share.
- I’m going to frame this talk in the context of building software products, because I’m a product guy. Don’t let that put you off if it’s different from the kind of work you do. If you need to work with these other disciplines at all, much of what I have to say should be applicable.
- This requires input from all 3 disciplines to be successful.
- PM is ultimately responsible for success in all 3 areas. There can be a lot of overlap between PM and UX, but I’m going to pretend they’re more separate for some of this talk. If you have an awesome PM who understands and values UX as a strategic partner, you can probably skip the PM parts of this talk :)You’ll build better products if you do the definition together. Alright, so first I’m going to talk about some ways this can go wrong, where the definition is not collaborative.
- If your product manager is just take the requirements from someone else and passing them on, they’re doing it wrong. Unfortunately this is the way it used to work for one of our products. The company tended to automatically say “yes” to customer feature requests, and those would become requirements without ever going through product definition.
- Start asking the product manager where the requirements are coming from.
- Overall, this is a tough situation to be in. You need to find some allies in the organization that are open to the idea of involving UX in product definition and work from there.
- If the goals are misaligned, appeal to outcomes like satisfaction, net promoter, retention. Severe misalignment could be a sign that product / feature is poorly conceived.
- As I mentioned earlier, the Software Architect is going to be a lot happier if they feel like they are part of conceptualizing the product. I also find that the other engineers are more likely to buy into the plan if they know that the Architect was consulted early on.
- Alright, so you’ve convinced everyone to work together on defining the product, and there’s consensus on the problem you’re trying to solve. Once you get into the specifics at the feature or user story level, there’s opportunity for disagreement.
- This might be the number one source of friction between UX designers and engineers. Well, it turns out that our jobs are actually kind of similar. We all have to solve difficult problems by making trade-offs among a bunch of competing demands. The conflict comes in because each discipline is working with a different set of concerns. Let’s look at some example constraints.
- These are just a few examples of UX design considerations. We make trade-offs between these competing concerns when we create our designs.
- Complexity is an oft-cited concern amongst engineers, and it’s not just because they consider simple solutions to be more elegant. Complexity tends to increase the time needed to build and test the initial solution. It also makes it more likely that this area of the code will develop new bugs when it’s worked on in the future. And there may be fewer engineers on the team that have the skills needed to maintain the more complex code. [Add a slide about code paths?]
- Make sure that everyone knows they can ask you the “why” behind your designs as well. Being open and explaining your designs will help to build trust and understanding.Once you understand each other, you’re more likely to find alternative solutions that satisfy both sets of constraints.
- Now, just because you find out that something is costly to build doesn’t mean you need to abandon it. But you want to make sure that it’s worth the effort. If you have design details that turn out to be expensive to build, that can be a good place to make trade-offs.Being willing to compromise and make trade-offs helps to build your credibility over time. When you need to sell people on the importance of that big redesign, they’ll be more willing to work with you.
- The best solutions often come from getting all three disciplines in a room together. [Add note about some engineers being better at this than others, and about multiple engineers overwhelming non-technical PM and UX]
- Okay, so you’re in agreement on the strategic vision and you’ve worked together to define something that is valuable, usable and feasible. Guess what? There’s still going to be some friction when it comes to execution.
- The first functional demo of the product is the wrong time to sweat details like misaligned fields. Other stakeholders will often latch onto these visual polish problems in early demos. You can help build rapport with your team by pushing back.
- At my current company, I didn’t have a good handle on our release process for my first design project. I missed the boat on giving detailed feedback on the execution before we went into regression. The engineers were annoyed that I was pushing for changes so close to release, and I was frustrated that they were saying “no.” Now I make sure that I do my reviews earlier in the process.
- For instance, when working on a responsive design, it’s helpful if you understand what layouts can be achieved without using Javascript.
- Real innovation happens at the intersection of the impossible and the possible. That’s where you really need the cross-functional collaboration to figure out the solution. But if you’re way over on the possible side, it’s helpful if you as a designer understand the solution space a bit from the engineering perspective. You should know what’s easy and what’s hard with the technologies in your existing products, particularly on the front-end.
- If your PM and UX person lack technical backgrounds, they can be easily overwhelmed by strong-willed engineers. You need to pair them with a lead engineer that is a good collaborator.
- The passion thing cuts both ways. You need to use some caution with the “aspiring designer” type of front-end developer, who may expect to design the UI on their own.