No one team should have all that power: Understanding who owns design in the product development process
•Download as PPTX, PDF•
0 likes•315 views
Recommended
Recommended
More Related Content
Similar to No one team should have all that power: Understanding who owns design in the product development process
Similar to No one team should have all that power: Understanding who owns design in the product development process (20)
No one team should have all that power: Understanding who owns design in the product development process
- 1. No one team should have all that power Understanding who owns design in the product development process Monet Spells
- 2. A Little About Me Professional Background - Computer Science + Web Development - Product Manager at a NYC start up - User Experience Designer - Studying Human-Computer Interaction Hi, I’m Monet! I live in Atlanta. I do UX, with a smile.
- 3. Who Owns Design? So...how do teams share ownership of design? Developers? Designers? Marketing? Stakeholders? Product? Everyone owns design.
- 4. Traditional Design Approach A traditional design approach focuses on users and design as important, but distinct, entities. “No one [team] should have all that power.” - Kanye West Users - Begins with users or design - Bridges, like product managers QA Developers Support Product Design Designer s Stakeholder s Marketing
- 5. Design-Driven Approach A design-driven approach focuses simultaneously on users and design, understanding that they balance and guide one another. - Begins with users and design - All teams are guided by design Designer s MarketingDevelopers QA Support Product Stakeholder s Users Design
- 6. Lessons Learned Align on a vision, mission, and goals Eliminate bottlenecks for efficiency sake (More time for champagne!) Always consider the user’s experience Empower everyone to contribute to design
- 8. Thank you! monet.spells@gmail.com | @OhMonet
Editor's Notes
- KW:don’t read from the slides
- K: "better collaborate on design" K: could ask more questions here...
- K: Start with your experience, not the definition...this is your definition, so it’s based on you rexperience K: Bridges are technically a good thing...but they COULD create a bottleneck, IF a company relies too heavily on any one team (e.g. product) K: Your story isn’t weaving in well enough...when you mentioned “...from here we grew” i forget who “we” are
- K: Not sure I agree with the HR example...
- K: either mention mission/vision/goals on slide 4 when you speak to it, or tell a story here about how PP incorporated these concepts to become design driven