Keeping PMs and designers on the same page

I’ve found that more than anything, “design” is the decisions made in conversations between teammates. To be effective I’ve needed to learn how to stay on the same page as my PM, which means learning how to talk about the project to others in the company. The use of a design brief for each project has become instrumental for me. In effect, it’s the common vocabulary for talking about and evaluating a project.

Product managers are ‘what’ and ‘why’ #

I think in most organizations, product managers are best equipped to be responsible for the ‘what’ and ‘why’ of a project. The ‘what’ should be fairly abstract and not prescriptive in terms of design.

At my company the design brief is a one-page document that captures the ‘what’ and ‘why’, and I’ve found it to be a good rallying point for each project. The ‘what’ is composed by a one-sentence problem statement and select criteria that provide scope, which is what a user should be able to do as an outcome of the project.

Context is also important and something that should be addressed in the brief. Is this project for an experiment? Will these features only be exposed to certain segments of users? Is this project an initial phase of a longer-term project? Understanding context gives me the information I need to decide how and when I can deliver a solution.

Throughout the project and during design critiques, we reference the brief to provide relevant feedback; it helps us stay focused on the core problem and not rabbit hole on details that don’t matter.

Designers own ‘how’ and ‘when’ #

I try to make sure that I work with product managers in a way that I can maximize my contributions:

• I want to manage a design project as efficiently as possible (and not spend 3 months iterating on mockups for a project that should take 6 weeks to build).
• I want to produce interaction design and deliverables that help engineers - build efficiently and without confusion.
• I want to work on projects that improve our product and provide users with a better experience.

When we kick off a project by reviewing a design brief, the PM, stakeholders, and myself are trying to determine realistic expectations for an MVP, which will hopefully prove that a concept is worth future iterations. This meeting should set the designer up for success by identifying scope, time, cost, quality, and risk. When those concerns are addressed and agreed upon, my job is to deliver against those concerns. Once we get to the point where the PM is planning and manage the sprint, I check in with engineers to QA flows against spec and to polish any UI or interaction details that weren’t clearly conveyed in the spec.

There might be nuances that I’ve missed, but this approach to communication has been pretty effective for me, reducing the stress that often comes along with the complexities of building product with larger teams.