Plan Design Project Intermediate

Plan a Design Project (Intermediate)

This assumes you already know the basic phase structure (research → design → system → application → documentation). At this level, the challenge isn't knowing the phases — it's handling what breaks the plan: unclear scope, dependencies you didn't see coming, and stakeholders who change their mind mid-project.

Map dependencies, not just phases

Before committing to a timeline, identify what each phase actually depends on. Research doesn't just take "a week" — it depends on having access to real users or data. If that access isn't confirmed yet, that's a risk to flag immediately, not something to discover once Week 1 is already underway.

Ask for each phase: what does this phase need from outside the design work itself (stakeholder input, technical feasibility check, content, access to users)? List those as dependencies, not assumptions.

Scope control

Projects rarely fail from lack of effort — they fail from scope quietly growing without the timeline growing with it. At the start of each phase, explicitly write down what's in scope and what's deliberately out of scope for this pass. When a new request comes in mid-phase, check it against that list before agreeing to add it — if it's genuinely important, it can go into a documented "next phase" list instead of expanding the current one silently.

Risk flagging

For each phase, name the one thing most likely to cause delay or rework, and what you'd do if it happens. Common ones:

• Research phase: low participant turnout, or research revealing the original problem framing was wrong.
• Design phase: stakeholder disagreement on direction, or technical constraints not surfacing until development starts.
• System phase: existing brand/design system conflicts with new decisions.
• Application phase: inconsistent screens revealing the system wasn't actually complete.

Naming these upfront doesn't prevent them, but it means you're not blindsided, and you already have a next step ready.

Adjusting the plan mid-project

When something shifts — a deadline moves, new information changes the problem — don't just tack changes onto the existing plan. Re-check: does this change the phase order, or just the tasks inside a phase? Most changes only affect the current phase's task list. Some (like discovering the original problem was framed wrong) mean going back a phase, which is normal and better than pushing forward on a flawed foundation.

Common mistakes at this level

• Treating the phase template as fixed instead of adapting it to the project's actual constraints and dependencies.
• Letting scope expand silently mid-phase instead of documenting new requests for a later phase.
• Not naming risks until they've already caused a delay, instead of flagging them at the start of a phase.
• Pushing forward through a phase after research reveals a wrong assumption, instead of pausing to re-plan.

Checklist

[ ] Dependencies identified for the current phase, not assumed
[ ] Scope explicitly defined — what's in, what's deliberately out
[ ] Top risk for this phase named, with a fallback plan
[ ] New requests logged for later phases instead of expanding current scope
[ ] Willing to step back a phase if new information contradicts earlier assumptions