The Bar Lands on the Date
A project schedule as a proper Gantt — task rows, a time axis, milestone diamonds, dependency arrows — where each bar actually sits under the dates it claims. Six fields.
Two runs of the same template. A season of library work beside a winter boat refit — six tasks each, one live, dependencies running forward only. The refit places its milestones in a single lane along the foot rather than beside their bars, which is a real scheduling convention and a legitimate divergence from the first run.
Generated from this template with the fields shown above, and measured rather than eyeballed: against a month width of 189 pixels, the twelve bar edges land a mean of 25 pixels from their true dates — about four days. Every bar falls in its correct month except two starts that cross a boundary by roughly two and four days. That is a substantial improvement on the reference's baseline, which printed its dates neatly at every bar end and then drew the bars wherever they balanced, putting a task beginning on the third of February inside January and one beginning on the twenty-ninth of April in the middle of the month. The labels were right and the chart was wrong, which is worse than either alone because a reader trusts the picture over the caption. Recorded as a partial pass: the geometry is close but not exact, and a schedule read to the day would still want checking against the dates.
Generated for this library
Input
Header BAKERY REBRAND · a family bakery · January to June
· the studio · in progress
Axis six columns, January to June
Tasks 1 research 02 Jan-02 Feb · 2 naming 03 Feb-23 Feb ·
3 identity 26 Feb-29 Mar · 4 packaging 01 Apr-26
Apr · 5 in-store 29 Apr-24 May · 6 launch 27 May-14
Jun
Depends each waits on the one before it
Stones report 02 Feb · name agreed 23 Feb · identity 29
Mar · packaging 26 Apr · launch 14 Jun
Palette white and pale grey, one fluorescent yellow
Returned 1 chart · 3:2 · white, grey bars, yellow for live
axis six month columns, ruled, evenly divided
bars each starting and ending under its own dates - the
naming bar begins inside February, not January
depends dotted elbows from each bar's end to the next bar's
start, none running backwards
stones small diamonds sitting on their exact dates, each
labelled beneath
legend live, not started, milestone, dependencyYou fill in 6 fields — the braced lines at the top. Everything below them is fixed.
- 1The project header
- 2The time axis
- 3The tasks, with start and end dates
- 4The dependencies
- 5The milestones
- 6The palette
The Bar Lands on the Date
Produce ONE image, 3:2 landscape: a project schedule as a Gantt chart. Follow every line. Replace only the FIELDS block; everything after it is fixed.
First — do you have the fields?
If any field below still has braces around it, stop and ask. Put all the questions in one short message, and show the example under each one so they can see the shape of a useful answer. Wait for the replies, then draw. Never fill a brace yourself: a value you invented is a value nobody asked for, and it will look exactly as considered as the ones they did give you.
Ask in whatever language they are writing to you in. Translate the questions and the examples; do not make someone read English to tell you what they want.
The examples are only examples. If someone answers a question, use their answer; never fall back to the example because you prefer it.
If the fields are already filled in, ignore this and carry on.
Fields — replace these six lines only
- The project header: {name, client, duration, owner, status}
- The time axis: {the columns, and their unit}
- The tasks, with start and end dates: {each with both dates}
- The dependencies: {what waits on what}
- The milestones: {each with its date}
- The palette: {a ground, and one live colour}
The position law
This is what separates a Gantt from a table with rectangles on it.
Every bar starts and ends under the dates it claims. A bar labelled 3 February begins inside the February column. A bar ending 24 May stops before the May column does. Length is duration; position is time; both are read against the axis.
A reference run of this style printed its dates neatly at the ends of every bar and then drew the bars wherever they balanced — a task starting on the third of February drawn beginning in January, a task starting on the twenty-ninth of April drawn from the middle of the month. The labels were right and the chart was wrong, which is worse than either, because a reader trusts the picture over the caption.
Check three bars against the axis before finishing.
The dependency law
Nothing starts before the thing it waits on has finished.
Dependency arrows run from the end of one bar to the start of the next, as thin dotted elbows with a small arrowhead. An arrow that runs backwards along the axis is a plan that cannot happen.
If two tasks genuinely overlap, they are not dependent, and no arrow joins them.
Milestones
A milestone is a moment, not a span. Draw it as a small solid diamond sitting exactly on its date, with a short label and the date beneath it. Never a bar, never a range.
The layout
- Header strip across the top: the project name large at the left, then evenly spaced fields — client, duration, owner — each with a tiny label above its value, and a status pill in the live colour at the right.
- Task list down the left: a number, the task name, and one line of sub-steps beneath it, each row aligned to its bar.
- The axis across the top of the plot: evenly divided columns, each labelled with its period, with faint vertical rules carrying down through the whole plot.
- Bars: rounded, of even height, with the start date printed at the left end and the end date at the right. Grey for not started, the live colour for what is under way now.
- Legend at the foot: live, not started, milestone, dependency.
- An updated-on date at the lower right, only if the fields give one.
The chart fills the frame. No floating panel with wide empty bands above and below.
Nothing invented
Task names, dates, dependencies, milestones and header values come from the fields. Do not invent a client name, an owner, a status, a budget or an updated-on date. A schedule is read as a commitment.
Style
White or pale grey ground, thin grey rules, dark grey type, one saturated colour used only for what is live. Modern sans, small tracked labels, generous white space. No gradients, no shadows, no 3D, no dashboard styling.
Never
- ✕ a bar whose position does not match its printed dates
- ✕ a dependency arrow running backwards along the axis
- ✕ a task starting before the task it waits on has ended
- ✕ a milestone drawn as a bar or a range
- ✕ an invented client, owner, status or date
- ✕ the chart inset in a canvas with empty bands around it
The result
A schedule somebody could plan from: six tasks in the right months, arrows that only ever point forwards, diamonds on the days things are due — and a bar you can hold a ruler to.
The whole template, in one piece. The steps below are the entire workflow.
How to use it
- Copy the whole template with the button above.
- Replace the six FIELDS lines. Give every task an explicit start and end date — the chart is only as true as those.
- Paste it into any image-capable agent or model, in one message. One run returns the schedule.
- Check three bars against the axis before shipping: read where each one starts and confirm it falls under the right month. If a bar labelled the third of February begins in January, the chart is decorative.
What you swap
- The project header
- BAKERY REBRAND · client: a family bakery · duration: January to June · owner: the studio · status: in progress
- The time axis
- six columns, January to June, months only
- The tasks, with start and end dates
- 1 research and analysis 02 Jan–02 Feb · 2 naming 03 Feb–23 Feb · 3 identity design 26 Feb–29 Mar · 4 packaging 01 Apr–26 Apr · 5 in-store application 29 Apr–24 May · 6 launch 27 May–14 Jun
- The dependencies
- each task waits on the one before it — 2 after 1, 3 after 2, 4 after 3, 5 after 4, 6 after 5
- The milestones
- research report 02 Feb · name agreed 23 Feb · identity signed off 29 Mar · packaging approved 26 Apr · launch 14 Jun
- The palette
- white and pale grey, one fluorescent yellow for what is live now
Before it runs
- Real dates. This chart's whole job is to put work in time, and a bar without a start and end is a coloured rectangle.
- A dependency chain you have checked. If two tasks overlap but one waits on the other, the plan is wrong before the drawing is.
- Milestones that are moments. A milestone spanning three weeks is a task; the diamond is for the day something is done.
When to reach for it
When a plan has to be read at a glance: a project schedule, a campaign, a build, a season of work. Templates in this style print the dates neatly at the ends of the bars and then draw the bars wherever they look balanced, which turns a chart back into a table.
What changes
- One clean schedule: a header strip, numbered task rows, a month axis, bars, milestone diamonds and dependency arrows.
- Bar geometry required to encode the dates — a bar starting on the third of a month begins under that month, not the one before.
- Dependencies held to being possible, so nothing starts before the thing it waits on has finished.
- Milestones as points rather than bars, sitting exactly on the date they mark.
- Full bleed, since these charts are routinely rendered floating in a canvas of empty margin.
Pairs with
- Count Both SidesA value-proposition canvas — a square facing a circle, three regions each — where the two halves are written as pairs, so anything unmatched shows up instead of hiding in a list. Six fields.
- Each Layer Takes Something AwayAn exploded axonometric that pulls one site apart into stacked transparent layers — kept on white and kept analytical, because the temptation is to render it dramatic and lose the drawing. Six fields.
- Every Region OccupiedA three-circle overlap diagram where every region you draw has something real in it — held to three sets, because four creates overlaps nobody can fill. Six fields.