> ## Documentation Index
> Fetch the complete documentation index at: https://docs.charle.agency/llms.txt
> Use this file to discover all available pages before exploring further.

# Block Types

> Understanding different block types and when to use them

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

<Tip>
  Schedule Design blocks early in the month so development can follow when designs are ready.
</Tip>

### 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

<Note>
  Development blocks should account for both building and initial developer testing.
</Note>

### 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

<Warning>
  Schedule Deployment blocks only when all QA is complete and approved.
</Warning>

## 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

<Tip>
  Plan for at least one round of Internal QA for all development work.
</Tip>

### 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

<Note>
  External QA Fixes blocks should align with the 20% feedback budget in task estimates.
</Note>

## Block type sequencing

### Typical workflow

Common block sequence:

<Steps>
  <Step title="Design">
    Create visual assets and mockups
  </Step>

  <Step title="Development">
    Build features based on designs
  </Step>

  <Step title="Internal QA Review">
    Team tests functionality
  </Step>

  <Step title="Internal QA Fixes">
    Fix bugs found by team
  </Step>

  <Step title="Internal QA Review (Round 2)">
    Re-test fixes
  </Step>

  <Step title="Client Review">
    (External to blocks - client reviews work)
  </Step>

  <Step title="External QA Fixes">
    Address client feedback
  </Step>

  <Step title="Deployment">
    Release to production
  </Step>
</Steps>

### 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:

| Block Type             | Work Type   | Who Sees It |
| ---------------------- | ----------- | ----------- |
| **Design**             | Design      | Designers   |
| **Development**        | Development | Developers  |
| **Internal QA Review** | QA          | QA testers  |
| **Internal QA Fixes**  | Development | Developers  |
| **External QA Fixes**  | Development | Developers  |
| **Deployment**         | Development | Developers  |

<Info>
  When assigning blocks, the system suggests team members whose work type matches the block type.
</Info>

## 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

<CardGroup cols={2}>
  <Card title="Plan the full sequence" icon="list-checks">
    Add all blocks upfront to see full timeline
  </Card>

  <Card title="Leave QA buffer" icon="shield">
    Always include Internal QA Review and likely fixes
  </Card>

  <Card title="Consider client rounds" icon="users">
    Clients rarely approve on first review
  </Card>

  <Card title="Right-size allocations" icon="ruler">
    Base hours on actual scope, not wishful thinking
  </Card>

  <Card title="Match work types" icon="user-check">
    Assign blocks to team members with matching skills
  </Card>

  <Card title="Update as you learn" icon="refresh-cw">
    Add QA rounds as needed, don't guess upfront
  </Card>
</CardGroup>

## 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

<AccordionGroup>
  <Accordion title="Can't add a block type I need">
    Core blocks (Design, Development, Deployment) are limited to one per client per month. If you need more, consider if it should be in a different month or if a multi-round QA block would work better.
  </Accordion>

  <Accordion title="Not sure which block type to use">
    Choose based on the work phase, not the person doing it. Design for visual work, Development for code, QA blocks for testing and fixes.
  </Accordion>

  <Accordion title="Need a block type that doesn't exist">
    The six block types cover standard workflows. If you have unique needs, discuss with management about whether a new block type is warranted.
  </Accordion>

  <Accordion title="Wrong block type added">
    Delete the incorrect block and add the correct type. Block types cannot be changed after creation.
  </Accordion>
</AccordionGroup>

## Next steps

<CardGroup cols={2}>
  <Card title="Blocks Overview" icon="layout-grid" href="/user-guide/blocks">
    Back to blocks overview
  </Card>

  <Card title="Hours Tracking" icon="clock" href="/user-guide/blocks/hours-tracking">
    Learn how hours are tracked
  </Card>

  <Card title="Scheduling Blocks" icon="calendar" href="/user-guide/blocks/scheduling-blocks">
    Configure and schedule blocks
  </Card>

  <Card title="Schedule" icon="calendar-days" href="/user-guide/schedule">
    See blocks in team schedules
  </Card>
</CardGroup>