MethodsArticlesCompareFind a MethodAbout
MethodsArticlesCompareFind a MethodAbout

93 methods. Step-by-step guides. No signup required.

ExploreAll MethodsArticlesCompare
PopularUser TestingCard SortingA/B TestingDesign Sprint
ResourcesAboutArticles & GuidesQuiz

2026 UXAtlas. 100% free. No signup required.

93 methods. Step-by-step guides. No signup required.

ExploreAll MethodsArticlesCompare
PopularUser TestingCard SortingA/B TestingDesign Sprint

2026 UXAtlas. 100% free. No signup required.

HomeMethodsWork-Breakdown Structure
ParticipatoryGenerate IdeasQualitative ResearchIntermediate

Work-Breakdown Structure

Decompose complex projects into estimable, assignable work packages to establish clear scope and prevent creep.

Work-Breakdown Structure decomposes projects into a hierarchy of manageable deliverables and tasks for clear scope, scheduling, and tracking.

Share
Duration60 minutes or more.
MaterialsPaper, writing supplies.
PeopleProject manager.
InvolvementNo User Involvement

A Work-Breakdown Structure (WBS) is a project management tool that decomposes a project into a hierarchy of progressively smaller deliverables and tasks until each piece is small enough to estimate, assign, and track. Project managers, UX leads, and design directors use WBS at the start of UX projects to define scope boundaries, identify dependencies between research activities, design phases, and development handoffs, and establish a shared understanding of what needs to be done across cross-functional teams. The method works by starting with the top-level project objective and systematically breaking it into major deliverables, then subdividing those into work packages that individual team members can own. Each element follows the 100% rule, meaning all child elements must fully account for their parent without gaps or overlap. This structured decomposition prevents scope creep by making it immediately visible when new requests fall outside the defined boundaries. For UX teams specifically, a WBS helps translate ambiguous research and design work into concrete, trackable milestones that stakeholders and engineering partners can understand. It also serves as the foundation for scheduling, budgeting, and resource allocation throughout the project lifecycle.

WHEN TO USE
  • When starting a complex UX project with multiple research phases, design iterations, and cross-team dependencies.
  • When you need to estimate timelines and budgets accurately for stakeholders before committing to a project scope.
  • When multiple team members or departments need clarity on who owns which deliverables and in what sequence.
  • When scope creep is a known risk and you need a documented baseline to evaluate change requests against.
  • When preparing project proposals or statements of work that require detailed breakdowns of research activities.
WHEN NOT TO USE
  • ×When working on a small, well-defined task that a single person can complete without formal decomposition.
  • ×When the project scope is intentionally exploratory and defining all deliverables upfront would be premature.
  • ×When your team uses agile frameworks with backlog grooming that already serves the decomposition purpose.
  • ×When the overhead of creating and maintaining a formal WBS outweighs the coordination benefits for a small team.
HOW TO RUN

Step-by-Step Process

01

Identify the main goal

Define the main goal or objective of the project that will be broken down into smaller tasks. This could be developing a new product or improving an existing one.

02

Break down the main goal

Divide the main goal into major sub-goals or deliverables. These will represent the higher level of the work-breakdown structure and should be broad enough to cover every aspect of the project.

03

Decompose sub-goals

Further break down each sub-goal or deliverable into smaller, more manageable tasks or sub-tasks. Ensure that each task is clearly defined and can be assigned to appropriate team members.

04

Estimate effort and duration

Determine the necessary effort and time required to complete each task. Use previous projects or industry benchmarks as reference points for accurate estimation.

05

Assign resources

Assign the required resources, including personnel, equipment, and budget, to each task. Make sure the resources are sufficient to complete the tasks within the estimated timeframe.

06

Establish dependencies

Identify the interdependencies between tasks and establish the sequence in which they should be completed. This will help define the critical path and project timeline.

07

Create a visual representation

Develop a visual representation of the work-breakdown structure, such as a hierarchical chart, a tree diagram or a Gantt chart. This will help all stakeholders to get a clear understanding of the project scope and structure.

08

Review and refine

Review the work-breakdown structure with stakeholders and team members to ensure it is accurate and comprehensive. Incorporate any feedback and make adjustments as necessary.

09

Monitor progress

As the project progresses, regularly check each task's status and compare it to the estimated duration and effort. Use this information to update the work-breakdown structure and make any necessary adjustments to the project plan.

10

Update and maintain

Continuously update and maintain the work-breakdown structure throughout the project, incorporating any changes or new tasks as they arise. This will help keep everyone informed and ensure the project stays on track.

EXPECTED OUTCOME

What to Expect

After creating a Work-Breakdown Structure, the team will have a complete, hierarchical map of every deliverable required to achieve the project objective. Each work package will be small enough to estimate, assign to a specific owner, and track against a timeline. The WBS provides a shared reference point that aligns stakeholders, team members, and sponsors on exactly what the project includes and excludes. It serves as the foundation for creating accurate schedules, budgets, and resource plans. When change requests arise, the team can evaluate them against the documented scope baseline and make informed decisions about what to add, defer, or decline.

PRO TIPS

Expert Advice

Apply the 100% rule: the WBS must cover all activities needed to achieve the project goal with nothing extra.

Focus on deliverables and outcomes, not activities — the results matter more than how they are achieved.

Break down until tasks are estimable (usually 1-5 days of effort) but no further to avoid micromanagement.

Number each element with a hierarchical code (1.1, 1.2, 1.2.1) for easy cross-referencing in other documents.

Review the WBS with team members who will actually do the work to catch tasks you may have missed.

Create a WBS dictionary that defines each element to prevent misinterpretation across team members.

Update the WBS when scope changes rather than trying to fit new work into existing structure.

Use mind mapping tools for initial brainstorming before formalizing the hierarchical structure.

COMMON MISTAKES

Pitfalls to Avoid

Listing activities not deliverables

A WBS should decompose into deliverables and outcomes, not activities. Instead of writing 'conduct interviews,' write 'interview transcripts and analysis report.' Focus on what is produced, not what is done.

Decomposing too deeply

Breaking tasks down to hourly increments creates a maintenance burden and micromanagement. Stop decomposing when work packages are estimable at roughly one to five days of effort.

Violating the 100% rule

Every level of the WBS must account for 100% of the parent scope — no more, no less. Missing items leave gaps in planning, while extra items create scope inflation. Review each level for completeness.

Creating the WBS alone

A project manager building the WBS in isolation will miss tasks they are unfamiliar with. Involve the people who will do the work — researchers, designers, developers — to ensure completeness and buy-in.

Not updating after changes

Treating the WBS as a static document leads to a plan that diverges from reality. When scope changes are approved, update the WBS immediately so it continues to serve as an accurate reference.

DELIVERABLES

What You'll Produce

Project Scope

Defined project goals, objectives, stakeholders, and boundaries.

User Research Plan

Comprehensive plan for gathering and analyzing user data.

Recruitment Strategy

Plan for recruiting participants matching target demographics.

Ethics & Consent Forms

Ethical guidelines and consent forms for research participants.

Research Material Development

Prepared surveys, interview scripts, and usability test tasks.

User Data Collection

Collected qualitative and quantitative data from research activities.

Data Analysis & Synthesis

Analyzed data with identified patterns, trends, and insights.

Persona Development

User personas representing key user groups and their needs.

User Journey Mapping

Journey maps showing user steps, pain points, and opportunities.

Design Recommendations

Actionable recommendations based on synthesized user data.

UX Research Report

Comprehensive report with findings, insights, and recommendations.

Stakeholder Presentation

Visual presentation of key findings for decision-makers.

Post-Implementation Evaluation

Evaluation measuring impact of implemented design recommendations.

FAQ

Frequently Asked Questions

METHOD DETAILS
Goal
Generate Ideas
Sub-category
Co-design sessions
Tags
work-breakdown structureWBSproject managementproject planningscope managementtask decompositionschedulingdeliverable trackingresource planningUX project planning
Related Topics
Project ManagementAgile UXScope ManagementDesign OperationsResource PlanningResearch Planning
HISTORY

The Work-Breakdown Structure originated in the United States defense and aerospace industries in the late 1950s and early 1960s. It was first formally described in 1962 as part of the Program Evaluation and Review Technique (PERT) and the Polaris missile program. The U.S. Department of Defense adopted WBS as a standard in Military Standard 881 (MIL-STD-881) in 1968, making it a mandatory element of defense project management. The Project Management Institute (PMI) later incorporated WBS as a core component of the Project Management Body of Knowledge (PMBOK), cementing its role as a fundamental project planning tool across all industries. In UX and design fields, WBS gained adoption as teams needed to communicate research and design project scope to engineering and business stakeholders who were already familiar with the format from traditional project management.

SUITABLE FOR
  • Breaking large projects into manageable, assignable work packages
  • Creating foundation for cost, schedule, and resource estimation
  • Aligning team understanding of project scope and deliverables
  • Preventing scope creep by defining clear project boundaries
  • Communicating project structure to stakeholders and sponsors
  • Identifying dependencies between work packages for scheduling
  • Creating accountability by assigning owners to defined work elements
  • Tracking project progress against defined deliverable milestones
RESOURCES
  • Design: Breaking down your project workI see it all the time and am guilty of it myself. A designer gets a new project to work on, the wheels start to spin, ideas start coming, and what we see in our heads isn't sketches, flows, or…
  • Work Breakdown Structure (WBS): What Is It?A work breakdown structure is a visual breakdown of a project that's organized into multiple levels. Learn more.
  • Work Breakdown Structures in UX
  • Breaking Down Work Breakdown Structure in Easy StepsLearn all about the work breakdown structure (WBS), one of the most important artifacts that a project manager must create during a project.
RELATED METHODS
  • 5W1H Method
  • Bodystorming
  • Brainstorming