{"id":8627,"date":"2017-04-24T14:00:07","date_gmt":"2017-04-24T13:00:07","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=8627"},"modified":"2017-04-24T11:35:37","modified_gmt":"2017-04-24T10:35:37","slug":"product-powerful-partnership-design","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/product-powerful-partnership-design\/","title":{"rendered":"How Product Can Create a Powerful Partnership with\u00a0Design"},"content":{"rendered":"

In each entry in this \u201cconversation\u201d series I talk to a designer\/product manager\/engineer on a topic. I want to make basic practical skills education transparent and free.<\/em><\/p>\n

Today I\u2019m talking to<\/em> Ryan Scott<\/em><\/a>, a senior product designer at DoorDash, about how product managers and designers should work together to create desirable products that solve business needs.<\/em><\/p>\n

What\u2019s your experience working with\u00a0Product?<\/h2>\n

I\u2019ve been lucky to work closely with Product at some very different companies. I was Director of Product at a start-up that launched at TechCrunch Disrupt and was acquired by Docker. As a product designer at Salesforce I worked with a team of product managers to build and launch the Salesforce Analytics Cloud.<\/p>\n

DoorDash is my first experience with a hyper-growth consumer brand. I joined the design team two years ago when there were eight engineers, three designers, and no product managers. We\u2019re now a team of 70 engineers, 13 designers, and six PMs.<\/p>\n

How is the relationship between Product, Design, and Engineering unique at DoorDash?<\/h2>\n

At DoorDash Product, Design, and Engineering make decisions together as peers. Product Managers are experts on business needs. Engineering Leads are experts on technical feasibility. Design Leads are experts on the customer. We believe these three perspectives are equal parts in determining what products to build and features to prioritize.<\/p>\n

What is DoorDash\u2019s development process\u00a0like?<\/h2>\n

The whole team is responsible for identifying problems. Product Managers work with Ops to understand our markets around the country. Engineers analyze bug reports, crash reports, and performance analytics. Designers speak regularly with customers to understand their wants and needs.<\/p>\n

When we identify a meaningful problem the team brainstorms solutions and discusses trade-offs. We consider anticipated business impact, complexity to build, and what will create the best user experience.<\/p>\n

<\/div>
<\/svg><\/div>

\"We consider anticipated business impact, complexity to build, and what will create the best user experience.\"<\/p><\/span><\/blockquote>\n

Visuals help make abstract concepts more tangible, so I start mocking up solutions very early on. I get feedback on visual design and usability from other designers. Feedback from Product and Engineering is usually more focused on making sure edge cases and technical constraints are accounted for.<\/p>\n

Depending on the project we may do a round of user research for further validation. Many times we launch features behind an experiment on one platform to quickly get feedback from users. We assess stability, viability, and desirability constantly as we ramp new features.<\/p>\n

What do designers expect from a\u00a0PM?<\/h2>\n

It\u2019s important that PMs represent the business impact while continuing to see the big picture. Business impact is only one part of the pie. PM\u2019s need to be able to facilitate a meaningful conversation about the tradeoffs of business needs, user needs, and technical feasibility.<\/span><\/p>\n

Product Managers should work with Engineers and Designers to create the team\u2019s roadmap. Engineers and Designers should be able to look at the roadmap and know what projects are coming up next and why they\u2019re important.<\/p>\n

Finally, Product Mangers can play a big role in facilitating organization and clarity. PMs at DoorDash help keep projects moving forward by making sure everyone knows the next steps and have clear action items. Designers and engineers spend more time focused on execution. PMs need to effortlessly alternate between the big picture and small details.<\/p>\n

<\/div>
<\/svg><\/div>

\"PMs need to effortlessly alternate between the big picture and small details.\"<\/p><\/span><\/blockquote>\n

How do PMs earn the respect of designers?<\/h2>\n

So many companies don\u2019t know how to effectively utilize designers. Great designers incorporate visual design, interaction patterns, usability conventions, competitive analysis, user feedback, human psychology, and even the physiology of the eye or brain into their designs.<\/p>\n


\n\"\u201cHey Designer, we\u2019ve decided to build this thing, can you make it pretty?\u201d<\/em> is the worst way to utilize your design talent. Don\u2019t treat design like a service. It\u2019s a waste of time and money to hire experts only to have them work in a very narrowly-scoped role. The company should hire designers they trust to provide expert opinions. PMs should make sure everyone understands the problem and then engage designers in a meaningful partnership to reach solutions together.\"<\/span><\/p>\n

How should a PM ask for last-minute design iterations?<\/h2>\n

Last-minute changes can be disruptive. They usually represent a failure earlier in the process (the right stakeholders weren\u2019t involved, the team overlooked an important detail, people are nitpicking little details, etc). <\/strong>Keep these to a minimum.<\/p>\n

<\/div>
<\/svg><\/div>

\"Last-minute changes can be disruptive.\"<\/p><\/span><\/blockquote>\n

When it does come up, it\u2019s important to know when to give and not<\/em> give last-minute feedback. As the expert on the business\u2019s needs, a good rule of thumb for Product is to give feedback when it\u2019s relevant to the business problem at hand. A productive conversation for a PM to have with a designer is: \u201cThe label on this button may not be clear to users, which could negatively affect our primary KPI.\u201d<\/em><\/p>\n

Nitpicking over details that won\u2019t materially impact the product\u2019s success will slow down the release.<\/strong> It\u2019s not productive to give feedback on subjective preferences. Trust your design partners to make these decisions. \u201cI don\u2019t like this drop shadow, let\u2019s try ten more versions\u201d<\/em> isn\u2019t the right elevation of feedback for a PM to provide.<\/p>\n

How can a PM productively critique a\u00a0design?<\/h2>\n

Giving good feedback is often about understanding the context behind why a designer made certain decisions or tradeoffs. Seek to understand these reasons before giving feedback.<\/p>\n

\"I\u2019d recommend becoming familiar with native and web patterns. Google\u2019s Material Design<\/a> or Apple\u2019s iOS Human Interface Guidelines<\/a> are good places to start. They contain standard conventions that designers use regularly, so it\u2019s helpful when PMs know where those decisions are coming from.\"<\/span><\/p>\n

People often think the foundation of design is art (subjective), but great design leans into human nature by embracing psychology and physiology (objective). Many design decisions leverage how the brain interprets information, color, motion, etc. I\u2019d highly recommend product managers read the Universal Principles of Design<\/a> to familiarize themselves with the science behind design.<\/p>\n

\"Finally, product managers should ground their feedback in how the design may or may not solve the business need. There are sometimes tradeoffs between what\u2019s best for the business and what\u2019s best for the user. Balancing those two needs will lead to desirable product and a more successful business. PMs should be able to see both perspectives and discuss tradeoffs to strike the right balance.\"<\/span><\/p>\n

How do designers or PMs justify redesigning a page or\u00a0feature?<\/h2>\n

I\u2019ve seen designers, engineers, and PMs be tempted to recreate a product from the ground up. It\u2019s exciting to shape the direction of a product and feel like you left your mark. However, this isn\u2019t always the right strategy. It\u2019s important to know when to be evolutionary<\/em>, and when to be revolutionary<\/em>.<\/p>\n

<\/div>
<\/svg><\/div>

\"It\u2019s important to know when to be evolutionary, and when to be revolutionary.\"<\/p><\/span><\/blockquote>\n

Evolutionary<\/strong><\/p>\n

Optimizations may be all that\u2019s necessary when a product is already successful. Refinements are also less likely to risk existing success. An evolutionary approach may also be right if an underlying key differentiator or principle hasn\u2019t changed. Simplicity and utility were differentiators that helped catapult Google to success. In 20 years, the appearance of Google\u2019s landing page has barely changed because the desire for simplicity and utility has remained constant. A major overhaul could have violated the core principles that contributed to the company\u2019s success.<\/p>\n