WBS Samples by Role: Web Development, Design, and Writing
Plenty of people understand the concept of a WBS but freeze the moment they try to apply it to their own project.
The hurdle gets higher when there are few concrete examples for your specific line of work. "Textbook" WBS examples tend to be framed in generic project-management language, and they're often not in a form an engineer, designer, or writer can use as-is.
This article presents WBS samples tailored to three kinds of work, in a form you can use directly. Each is organized into four levels (project → phase → deliverable → task).
A quick refresher on the four levels
Before looking at the samples, a quick review of what each level means.
- Project level: the engagement or contract
- Phase level: chronological stages (requirements, design, implementation, testing, etc.)
- Deliverable level: the concrete outputs produced in each phase
- Task level: the smallest units of hands-on work (what you track time against)
Organizing work in this structure lets you aggregate hours by phase and by deliverable.
Sample 1: Website build (contract development)
A sample assuming a corporate website of about 5 pages.
📁 Corporate website build
▾ Requirements
▾ Discovery
□ Prepare discovery questionnaire (1h)
□ Run client discovery session (2h)
□ Meeting notes & requirements doc (2h)
▾ Requirements confirmation
□ Create sitemap (2h)
□ Client confirmation & revisions (1h)
▾ Design
▾ Wireframes
□ Homepage WF (3h)
□ Services page WF (2h)
□ Company profile & other page WFs (2h)
□ Client review & revisions (2h)
▾ Design comps
□ Homepage design (6h)
□ Shared parts (header/footer) (3h)
□ Client review & revisions (3h)
▾ Implementation
▾ Shared components
□ Implement header/footer (3h)
□ UI components — buttons, forms, etc. (3h)
▾ Page implementation
□ Implement homepage (4h)
□ Implement services page (3h)
□ Implement contact page & form (4h)
▾ Testing & delivery
▾ Verification
□ Cross-browser & responsive checks (2h)
□ Form submission tests (1h)
▾ Delivery
□ Client review & final revisions (3h)
□ Production deploy & verification (2h)
Key point: explicitly including "client review & revisions" as WBS tasks matters. If it's missing at estimation time, it becomes the reason hours balloon later. Including review hours in every phase makes the reality of revision work visible.
Sample 2: UI design (new feature for a SaaS product)
A sample assuming an engagement to design the UI for a new product feature.
📁 Feature X UI design
▾ Research & definition
▾ User research
□ Prepare interviews with existing users (2h)
□ Run & record interviews (4h)
□ Summarize insights (2h)
▾ Requirements shaping
□ Translate functional requirements into design terms (2h)
□ Confirm constraints & technical specs (1h)
▾ Concept
▾ Idea exploration
□ Rough sketches, multiple directions (3h)
□ Present directions to team & gather feedback (1h)
□ Decide on direction (1h)
▾ Design production
▾ Wireframes
□ Wireframe key screens (4h)
□ Interaction design (2h)
□ Review & revisions (2h)
▾ Visual design
□ UI design for key screens (8h)
□ Edge cases & error states (3h)
□ Review & revisions (2h)
▾ Design file housekeeping
□ Organize & name components (2h)
□ Spec comments for engineers (2h)
▾ Handover
▾ Handoff
□ Walk engineers through the spec (1h)
□ Implementation review & design adjustments (3h)
Key point: explicitly making "post-handoff adjustments with engineers" a task lets you estimate rework hours in the implementation phase up front. And giving "edge cases & error states" its own task keeps that work from falling through the cracks.
Sample 3: Web writing (owned-media articles)
A sample assuming an engagement to write 4 SEO articles per month.
📁 Acme Corp owned media (monthly)
▾ Planning
▾ Topic selection
□ Keyword research & competitor article review (3h)
□ Select & propose 4 monthly topics (1h)
□ Client confirmation & final decision (1h)
▾ Writing
▾ Article A
□ Outline (1h)
□ Draft (3h)
□ Revision & polish (1h)
▾ Article B
□ Outline (1h)
□ Draft (3h)
□ Revision & polish (1h)
▾ Article C (same structure as A & B)
▾ Article D (same structure as A & B)
▾ Delivery & publishing
▾ Publishing work
□ Load into CMS & set images (30 min × 4 articles)
□ Client confirmation & revisions (1h)
□ Verify publication (30 min)
Key point: in writing work, splitting each article into three tasks — outline, draft, revision — makes it easy to see which stage consumes the time. Estimate based only on writing time and the outline and revision hours tend to slip out. For monthly engagements, treating one month as one project makes month-over-month comparison straightforward.
Notes on using these samples
These are samples, nothing more. When you use them, adjust for your project's requirements, scale, and how involved the client is.
Don't forget communication hours: meetings, email, and confirmation work belong in your tasks. Leave them out and your estimate undershoots reality.
Make revision handling its own task: "revisions after review" always happen. Recording them separately from the production work itself reveals how much revision effort actually occurs. Over several projects, "this type of engagement costs X hours of review work" becomes a number rather than a hunch.
For your first attempt, compare against past projects: if you have records from similar past work, use them to calibrate this project's task hours. Recording your WBS in a consistent structure makes those comparisons easy.
Break tasks down to roughly 4 hours or less: oversized tasks make progress hard to read. Aiming for "a granularity where you can tell whether it finishes within a day" usually lands you in the right place.
The "four-level WBS breakdown and effort tracking" covered in this article is exactly what LayerClock supports. Register your WBS in a four-level structure — project, phase, deliverable, task — and accumulate actuals with timer tracking. A time-tracking system that works for any role, free to try.