Block Types

CharleOS provides six block types that represent different phases of client work. Understanding when to use each type helps you plan capacity effectively.

​

Core blocks

Core blocks represent the main phases of project work. Each can only be added once per client per month.

​

Design

Purpose: Reserve capacity for visual and UX work When to use:

• UI/UX design needed
• Visual assets to create
• Mockups and prototypes
• Brand work
• Creative direction

Typical allocation: 10-40 hours depending on scope Assigned to: Designers Workflow position: Usually first in sequence Example scenarios:

• New website design
• App interface design
• Marketing materials
• Brand identity work
• Design system updates

​

Development

Purpose: Reserve capacity for code and technical implementation When to use:

• Building features
• Technical implementation
• Integration work
• Bug fixes
• Performance improvements

Typical allocation: 20-80 hours depending on complexity Assigned to: Developers Workflow position: After design, before QA Example scenarios:

• Feature development
• API integrations
• Database migrations
• Frontend implementation
• Backend logic

​

Deployment

Purpose: Reserve capacity for production releases When to use:

• Deploying to production
• Release coordination
• Go-live activities
• Post-deployment monitoring
• Release documentation

Typical allocation: 2-8 hours Assigned to: Developers or DevOps Workflow position: Last in sequence, after all QA Example scenarios:

• Production deployment
• Release management
• Environment setup
• DNS changes
• Post-deploy verification

​

QA blocks

QA blocks represent testing and fix phases. These support multiple rounds for iterative quality processes.

​

Internal QA Review

Purpose: Reserve capacity for team testing When to use:

• Testing functionality
• Bug identification
• Quality verification
• Pre-client testing
• Acceptance criteria checking

Typical allocation: 5-15 hours per round Assigned to: QA testers or developers Workflow position: After development, before client review Multiple rounds: Yes - add Round 2, Round 3, etc. if retesting needed Example scenarios:

• Feature testing
• Regression testing
• Cross-browser testing
• Mobile testing
• Integration testing

​

Internal QA Fixes

Purpose: Reserve capacity to fix issues found in internal testing When to use:

• Bugs found by QA team
• Issues to correct
• Adjustments needed
• Failed test cases
• Defect resolution

Typical allocation: 5-20 hours per round Assigned to: Developers Workflow position: After Internal QA Review identifies issues Multiple rounds: Yes - each QA round may need corresponding fix round Example scenarios:

• Bug fixes
• Logic corrections
• UI adjustments
• Performance fixes
• Data corrections

​

External QA Fixes

Purpose: Reserve capacity for client feedback changes When to use:

• Client review feedback
• Requested changes
• Adjustments post client QA
• Refinements
• Polish work

Typical allocation: 5-30 hours per round Assigned to: Developers or designers Workflow position: After client has reviewed Multiple rounds: Yes - clients may review multiple times Example scenarios:

• Client-requested changes
• Feedback incorporation
• Visual tweaks
• Content adjustments
• Functionality refinements

​

Block type sequencing

​

Typical workflow

Common block sequence:

​

Alternative sequences

Development-only work:

1. Development
2. Internal QA Review
3. Internal QA Fixes
4. Deployment

Design-only work:

1. Design
2. Client review (no blocks)
3. External QA Fixes (design revisions)

Ongoing retainer:

• Development (continuous)
• Internal QA Review (as needed)

​

Work type mapping

Each block type is associated with a work type for assignee filtering:

​

Single vs multi-round blocks

​

Single instance blocks

Blocks: Design, Development, Deployment Rules:

• Can only add once per client per month
• Button disabled if already exists
• Represents one phase per month
• If more needed, add in different month

Why single instance?

• Prevents duplicates
• Encourages focused phases
• Clearer capacity planning
• Simpler timeline

​

Multi-round blocks

Blocks: All QA blocks Rules:

• Can add multiple rounds
• Automatically numbered (Round 1, Round 2, etc.)
• Each round is independent
• No limit on rounds

Why multi-round?

• QA is iterative
• Testing often needs multiple passes
• Fixes may need re-testing
• Client feedback comes in waves

​

Choosing the right blocks

​

For new features

Required blocks:

• Development ✓
• Internal QA Review ✓

Optional blocks:

• Design (if UI/UX needed)
• Internal QA Fixes (likely needed)
• External QA Fixes (for client feedback)
• Deployment ✓

​

For bug fixes

Required blocks:

• Development ✓
• Internal QA Review ✓

Optional blocks:

• Internal QA Fixes (if issues found)
• Deployment ✓

​

For design work

Required blocks:

• Design ✓

Optional blocks:

• External QA Fixes (for revisions)

​

For integrations

Required blocks:

• Development ✓
• Internal QA Review ✓
• Deployment ✓

Optional blocks:

• Internal QA Fixes (testing often reveals issues)

​

Best practices

​

Common mistakes

​

Mistake 1: Skipping QA blocks

Problem: Only adding Design and Development Impact:

• No capacity for testing
• Bugs found late
• Team over-allocated when QA needed

Solution: Always add Internal QA Review at minimum

​

Mistake 2: Under-allocating QA fixes

Problem: QA Fixes blocks too small Impact:

• Fix work extends beyond allocation
• Developer has no time to address issues
• Delays in release

Solution: Allocate 30-50% of QA Review time for fixes

​

Mistake 3: Not planning for client feedback

Problem: No External QA Fixes blocks Impact:

• Client requests have no capacity
• Changes feel like scope creep
• Team scrambles to fit work in

Solution: Add External QA Fixes proactively

​

Mistake 4: Wrong block type

Problem: Using Development block for design work Impact:

• Designer time not tracked correctly
• Work type filters don’t work
• Confusing capacity planning

Solution: Use the correct block type for the work phase

​

Troubleshooting

​

Next steps