Design Operations Guide

Set Expectations

Leadership and Stakeholders

Setting expectations with leadership and stakeholders is one of the hardest parts of the design phase. Since you are making something that is not yet known, estimating time and personnel need is by definition difficult. On the other hand, the authors of this guide know that design teams will need to be able to make some sort of time and personnel estimation for supervisors, partners, and others in order to get the go-ahead to start the design phase. You can use the illustration of the design phase work and the accompanying framework in this section to help you envision the work that occurs in the design phase and to aid your planning.

An illustration of the Design Phase timeline. It is split along a horizontal line to be between Public and Internal facing. Arrows lead between the first, internal stage in which research outputs are considered, then up into a public phase in which existing designs are reviewed. Then back into an internal phase during which the team builds references from their research and existing designs for what they hope to be the design phase's prototypes will be. Those are then synthesized together into testable prototypes. Following that, there's a large, multi-part testing phase, in which the prototypes are tested with participants farther and farther away from the core team. Finally, an iteration that results from that testing goes into the piloting phase.

Click to enlarge the above image

Framework: First Draft Project Plan

Each design phase differs depending on the nature of the product, service, or system, the bandwidth and expertise of the team, access to the participants and stakeholders, and the scope of the project itself. If necessary, create a rough map of each of these parameters to understand your timeline.

Get started on building a timeline for your project by using the timeline framework in this section. To fill out this framework, you will need to map answers to the following questions:

  • Do you have ready access to the stakeholders and participants, or is access less well defined?
  • What is the nature of your opportunity spaces? Are they big and conceptual? Or smaller and tactical?
  • Do you have a team with many conceptual skills and emotional intelligence? Or is your team heavier on technical knowledge?

The project plan you map at this stage should not be understood as perfect or fixed for your project; it is simply a best estimation of how much time your project will need, based on what you know at this early stage. You can use this estimation so you can set expectations with your supervisor, stakeholders, and teammates for the project term. Hint from a design professional: A good rule for estimating project timelines is to take the total amount of time you think the project will take and then add 20% more time to it. This extra padding allows you to absorb the inevitable bumps in the road that come along with creating new products, services, and systems in our complex, multi-faceting work environment.

A framework for a project plan that includes the following items to fill in. 1. Access to stakeholders and participants: they are only you and your team; they are immediately accessbile; they are only accessible through layers of people and systems. Map your project Opportunities and Team Skills in terms of tactical, balanced, and conceptual. Finally, create your own timeline, given what you know at this point. There are two extremes of a line, inside which you can map the timeline. On one end is a short project, at about 4 weeks long. The conditions for this project are: (1) Our opportunity spaces are well-defined. (2) We have immediate and robust access to participants and stakeholders.(3) We have the required conceptual and practical skills on our team to create and test a variety of products, services, and / or systems. On the other extreme is 12+ weeks. The conditions for this project are: Our Opportunity spaces are highly conceptual. (2) We do not have ready access to participants and stakeholders.(3) We need to assess team members’practical and/or conceptual skills to ensure we can generate high-value product, service, and/or system designs.