Design Team Goals

The design team has 3 high-level goals:

1. Define the sequence in which we build Chandler by gathering and coordinating input from engineering, design goals and end-users
2. Explore and craft design requirements (@@@ link to higher-level goal e.g. for max. adoption or best experience to our target users)
3. Operationalize such design requirements and communicate them in sufficient detail for engineering implementation aligned with engineering milestones

The first goal is probably more a "product management" function, but product management and design are currently largely conflated together. We may separate the functions in the future.

In coarse-grain, high-level terms, design owns "what" and "sequencing & scoping"; engineering owns "how" and "how long" and we work closely with them.

Current Process and Phases

This is an attempt to make our implicit design process explicit. Currently, we loosely undergo the following phases:

1. Brainstorm: in pretty free-form ways, we discuss the many approaches and scope of a large topic (e.g. communications)
2. Draft: Someone (usually Mimi) organizes the results of the brainstorm. End result is a set of workflow proposals
3. Workflow: We discuss a proposal in terms of user motivation and workflows (steps users can take to satisfy the original motivation)
4. Design Specifications (usually component specs): If we reach agreement on the workflows, we then work on translating the workflows into concrete Chandler affordances in terms of component, interaction and (end-user) content model specifications.
5. Engineering collaboration: we work with engineering (usually apps team) and work on improving (4) (sometimes (3)) until engineering feels it is reasonably implementable
6. Dot release scoping: we work with engineering to figure a subset of (5) that should be implemented in the current or next dot release (currently figuring out how this will work).
7. Feedback: based on engineering milestone releases, we provide feedback to engineering on their current implementations and what is missing or did not follow design intent (not being done much currently)

What goes wrong (currently)?

The above process is idealized. Here is what can go wrong based on past experience sectioned by high-level goals:

Goal 1: [still drafting, TBD]

• We have really only defined 0.4 to any degree. Need to specify 0.5 and ideally up to Canoga
• Need to make feature sequencing and prioritization principles and process more explicit
• Need to communicate and get better (minimally) internal alignment

Goal 2:

• How do we categorize and pick the right topics for brainstorming and discussion?
• How do we track, prioritize and make progress on open issues?
• We sometimes go in circles possibly because from one topic or perspective a workflow or solution is clear, but from another perspective, an alternatie solution is better.
• How do we resolve differences in opinion on the merits of a workflow or solution?

Goal 3:

• How do we keep engineering in the loop without sucking too much of their time or having too many meetings?
• How do we align design results with engineering deliverables?
• How do we track status?
• How do we prioritize our deliverables so as to minimize blocking engineering?
• How do we best communicate design changes?
• How do we best communicate design feedback on engineering implementations?

In general:

• How do we have a process of continual improvement?
• How do we track overall product progress?

Proposals for addressing issues in Goal 3

I don't have concrete proposals for issues listed in goals 1 & 2 yet, but welcome discussions and proposals. I have a rough proposal for goal 3 for discussion.

I believe the key to addressing goal 3 issues is to align our design process a lot more closely to the engineering process now that one is emerging much more clearly. To align with engineering process, I propose we:

• match design and engineering projects as closely as possible
• align milestones as closely as possible
• track status and progress through such projects and milestones
• have clear owners on both design and engineering teams for each project. Allow for different collaboration styles given different owners strengths
• figure out a process to provide design feedback on engineering implementations

Thus, production projects are meant to address goal 3 while exploratory projects are meant to address goal 2.

See also DesignProcessRoles

-- ChaoLam - 17 May 2004