Motivation

• This page attempts to clarify the roles of people in the design team
• We want a process that keeps Mitch and Mimi actively involved and contributing to the design of Chandler, while allowing Mimi autonomy and responsibility for the UI Design and providing Chao the right leverage to drive forward ProductManagementJobResponsibilities responsibilities.

Proposal

Design Roles

• Conceptually we divide up design process into two phases: Exploratory and Production akin to ExploratoryProject and ProductionProject. [@@@ reconcile this with Mimi's DesignProcess. Right now, it seems mostly orthogonal]
• In Exploratory Phase:
  • Chao coordinates with Mitch and Mimi to prioritize the topics for discussion
  • We brainstorm the topics together (different topics can be led by different people). Goal at the brainstorm phase is to:
    • get a common sense of what the scope and dependencies of the topic entails
    • explore different directions we can take, and get a rough idea on the prioritization of these directions
    • agree on terminology and taxonomies where applicable. Highlight ones we are not comfortable with
  • Mimi works closely with Mitch to arrive at proposals around the scope of the topic we brainstormed
  • Mitch reviews Mimi's proposal to ensure
    • integrity of the product consistent with his design sensibilities and vision for Chandler
    • this is the right approach we are taking, given the multitude of ambitions we have i.e. the proposal won't close off important options we want to keep
  • Product mgmt (Chao at this point) reviews Mim's proposal to
    • figure out how it fits within the product schedule and the goals for each release
    • propose how the proposal can be phased in
    • provide and coordinate a first check with engineering reality. Mitch may play a role here too, wearing his head of dev hat.
  • Proposals will undergo multiple review cycles
• In Production Phase:
  • Chao works with Mitch, Mimi and engineering to arrive at a high-level candidate list of features for the Dot Release. This is similar to the process we arrived with ZeroPointFourPlanning
  • Mitch reviews and does final sign off on the candidate list
  • Lisa drives detailed workplan. Katie, Lisa and Chao work on scheduling details.
  • For UI components, Mimi works with Chao and proposes dot release feature list
  • Chao works with Lisa and Katie (who coordinates with other engineers) to arrive at a detailed dot release feature set. Mitch reviews and does final sign off.
  • Mimi works closely with engineers to work out nuances of proposal. Chao helps unravels thorny issues and helps speed process along
  • Design team reviews milestone builds and provides feedback to engineers on unexpected behavior. (Feedback process is currently ad hoc. Not sure if we need a more structured or coordinated process yet)
  • We use milestone reviews to track and measure development progress and highlight inter-group production issues that aren't being resolved
• Because we believe in iterative cycles, often a production project will surface issues that lead back to rethinking about one or more exploratory project proposals. Resolving such issues is not easy and there is no cut and dry answer. Chao is responsible for driving the resolution of these issues. Roughly, Chao undertakes the following process
  • • Is this really a rethink of an exploratory proposal?
    • If it is:
      • what should we do for current dot release?
        • should we delay this feature pending resolution?
        • should we cut this feature from this dot release?
        • should we come up with a compromised solution just for this release that is still compatible with eventual proposal?
      • In parallel, Mitch and Mimi should collaboratively arrive at an answer to the question: without dot release pressure, what is the right thing to do?
    • if it isn't:
      • continue following production project process but give Mitch a heads up

This the state of how I see things in June 2004. As Mitch mentioned, our goal as an organization is to drive decision-making down to the level who actually do stuff. So, we have a long-term goal to create simple, lightweight processes such that individual contributors take on more and more decision-making responsibilities over time.

-- ChaoLam - 10 Jun 2004