Design Manager's Workbook

👈🏼
Back to home page | Next article 👉🏼
💡
I have been managing design projects for small, mid and large scale companies since 2012. This document covers my notes, tips and tricks that I have gathered over many years. Please feel free to suggest modifications, and ask questions.

What is a design manager?

Key responsibilities:

Project management:

Why is a design manager needed?

Imagine an execution, without at least some amount of planning. You are imagining a high failure rate, slow improvement and a badly designed product.

A design manager ensures all the designers are on the same page, are aware of the scope, constraints, and everything that already exists.

Daily client communication, daily design reviews, weekly/bi-weekly feedback sessions, etc are some mechanisms to ensure that the project goes smoothly, and the design team is able to deliver a product with the utmost quality.

How to become a design manager?

As a design manager, you are not only required to help clients/stakeholders with planning and executing the design project, you are also expected to build a good level of personal and professional understanding with your peers.

Being good at any kind of management, starts with building empathy.

To build empathy with a client, a manager should understand the following aspects:

To build empathy with a designer, a design manager needs to understand:

As a design manager, you also need to ensure that you are praising in public, and criticising in private. A clear call-to-action oriented discussion should always be preferred, over vague, opinionated or accusatory discussion. Always remember, nobody does their job badly by intention. People make mistakes, just like we do, and it's very human-like to not realize one’s mistake, unless it is pointed out by someone else.

Setting up success criteria:

It is extremely important to call out and document the most important aspects of a design engagement, and how to measure the success.

Success criteria can be different for different phases of the project:

  1. Pre engagement
  1. During engagement
  1. Post engagement

Defining pre-engagement success criteria:

Understanding the requirements: 

  • What is the product?
  • Who are the users of the product?
  • Nature of the product - responsive web? Native mobile? Native desktop?
  • Do we have a product requirement document in place? If no, put one together. A rough one counts. (Good source: http://ibmypdesign.weebly.com/i-develop-a-design-specification-which-clearly-states-the-success-criteria-for-the-design-of-a-solution.html)

Understanding the constraints:

  • What are the timelines?
  • Any tech-stack preferences?
  • Are we designing from scratch? Or we need to build on top of something existing?

Understanding the people:

  • Who are the key stakeholders?
  • Who all are going to be the part of the design reviews and sign off?
  • What will be the availability of all the stakeholders, required to give a sign off?

Understanding the tools:

  • For project planning (ex: Confluence, JIRA, Trello)
  • For daily communication (ex: Slack, MS Teams, Email)
  • For reporting (ex: DSRs)
  • For delivery (ex: Google drive, dropbox, OneDrive)

Defining during-engagement success criteria:

Designer allocation:

  • Does the designer(s) have the required level of experience?

Onboarding designer(s):

  • Do they know what the product is?
  • Do they know who the stakeholders are?
  • Do they know all the collaborators (other designers, PMs, devs, etc)?
  • Do they know all the constraints?
  • Do they know the timelines, if any?
  • Do they know the nature of the product (web/responsive web/native)?
  • Do they know all the required tools (Confluence, JIRA, Trello)?
  • Do they have access to the requirement document?
  • Do they have access to the use case document?
  • Have they been introduced to the client formally?
    • If not:
      • Schedule an introductory call between all the designers and stakeholders

Organising files:

  • Do we have an agreed-upon folder structure to store files?
  • Do we have a version control mechanism, to keep track of changes?

Documenting design process:

  • Do we have major milestones identified?
  • Do we have weekly plans created and shared?
  • Do we have an agreement between the client and the designer for the weekly deliverables?

Internal design reviews:

  • Do we have daily design review sessions in place?
  • Do we have a clear call to actions coming out of these reviews?
  • How are we documenting these review sessions?

External design reviews:

  • Do we have daily/alternate days/weekly calls scheduled with the stakeholders/client?
  • Do we have a clear call to actions coming out of these reviews?
  • How are we documenting these review sessions?
  • MOMs are being shared with the client and designers?

Feedback mechanism:

  • Do we have mechanism(s) to gather feedback?
  • Do we have a mechanism(s) to track the status of each of the feedback?

File storage:

  • Do we have a file-sharing mechanism in place?

Change requests:

  • Do we have a mechanism to identify a change in scope?

Status reporting:

  • Daily status reports communicated to the client?
  • Daily status reports being sent out to the client and other stakeholders?

Running as per plan:Do a weekly check to get answers to the following questions:

  • Are we as per schedule? What are the areas of optimization, to help us run ahead of schedule?
  • Are we running behind the schedule? What are the blockers or things that are dragging us?
    • Create a list of things that are getting delayed
    • Create a list of reasons why any of the design deliverable/plan is delayed
    • Create an action-plan against each of the causes of delay.
      • If the delay is because of an unavoidable situation such as unplanned leaves or unavailability of any of the stakeholders, communicate the delays, reason of delays, and the adjustment to the plan that you will have to make
      • If the delays are because of avoidable circumstances such as planned leaves, technical issues, etc; communicate the same to the entire team (designers, developers, client), and indicate the impact of the delay on overall delivery timeline
  • Are we running ahead of schedule? Where is the celebration? :)

Conduct casual catch ups:

  • Schedule a casual catchup, once every 3 weeks, between the client, the designers, and any other stakeholders
    • Check with the client, designers and stakeholders first
    • Schedule a no more than 45 minutes meeting
    • You’re the master of this meeting, drive through awkward pauses
    • Keep the agenda open - discuss family, life, non-work related stuff
    • No minutes of meetings!

Escalation handling: The most effective way of handling escalation is over communicating. In order to over communicate, ensure that you have an answer to the following questions:

  • Do we have a retro call scheduled with the client every 2 week (or every week)? Key questions to ask during a retro:

Defining post-engagement success criteria:

Organising the final deliverables:

Other important points


👈🏼
Back to home page | Next Article 👉🏼