task-ops
A designer is on round four of a set of banner sizes. The comments for round three came in over chat, a video call and two replies to an email thread that has lost its original subject line. One of those comments contradicts a decision made in round two. Nobody can find where round two was decided, so the contradiction wins, and the round count keeps going up.
Every list of creative project management software is written as though the problem were tasks. It is not. Creative work moves in loops, not lines, and the loop is a review round. A tool that handles rounds badly will fail no matter how many templates it ships with, and a tool that handles them well can be fairly plain everywhere else.
Software delivery gave the whole industry its vocabulary for project management, and that vocabulary assumes work proceeds through stages and does not come back. A ticket goes from to do, to in progress, to done. Creative work does not behave like that. A logo goes out for review and comes back as a different logo. The task did not fail and it did not finish. It went round.
This has three consequences for how a board should be set up.
First, a stage called review is not a stage. It is a state a card returns to repeatedly, and the number of returns is the fact worth tracking. A board that cannot show the round number loses the only figure that predicts whether a deadline will hold.
Second, waiting on the client is not the same as being worked on. The distinction is not administrative. A studio that merges them looks slow for nine days of somebody else's legal review, and cannot show otherwise when the schedule slips.
Third, the completed state needs to mean approved by a named person, not uploaded. Creative work that is finished but unapproved is the most dangerous item on any board, because it looks done and is not.
The practical setup that reflects this is a short set of stages, with the round count on the card. Brief, In progress, Internal review, With client, Approved. Five columns, and a card that says round 3 in its title or in a field on the card. Adding columns per round is the common mistake and it produces a board twelve columns wide by the end of a project.
A file called logo_final_v2_REALLY_final.ai is a joke with a real cost, which is that nobody can say which version the client approved. Two conventions solve it and either works as long as one is chosen.
Date first. 20260926_homepage_r2. Sorts correctly everywhere, survives being pulled out of the tool, and reads unambiguously in a year.
Round first. homepage_r2_20260926. Easier to scan when the same deliverable has many rounds, harder to sort across a folder of mixed deliverables.
What matters more than the choice is that the round number in the file name matches the round number on the card, and that the approval is recorded against the round rather than against the deliverable. The card comment that reads approved, dated, naming the person, against round 2, is the artefact that ends arguments. A tool where comments live on the card rather than in a separate channel gives that for free. A tool where discussion happens elsewhere does not, regardless of what its feature list says.
One habit is worth more than any convention: the person who receives approval writes it down in the same place as the work, in the same hour. Approval remembered from a call is not approval.
The same discipline applies to the round that is skipped. Clients occasionally approve at round one, and a card that jumps from round 1 to approved with no comment in between looks, six weeks later, like a card that was never reviewed. A one line note saying approved at first review, with the date and the name, costs ten seconds and prevents the reopening of a closed deliverable on the grounds that nobody remembers it being signed off.
The single largest cost in creative delivery is not designing. It is collecting, reconciling and chasing feedback. The cost comes from the number of places feedback can arrive, and each additional place multiplies the reconciliation work rather than adding to it.
The rule that fixes it is stated easily and followed with difficulty. Feedback that is not written on the card does not exist. That means the studio takes on a small, unglamorous duty: when a client gives feedback in a call, someone writes it on the card before the call ends and asks for confirmation in the same place.
Chat is where this breaks down most often, because chat is where the fastest and most consequential decisions get made. A message saying let us push the launch to the following week is a schedule change, and if it stays in a channel, the board keeps showing the old date and someone plans against a lie. Tools that put chat and cards in the same product make the copy across shorter, which is the only reason it happens at all. Where chat is separate, the workaround is a rule that any decision gets pasted into the card before the thread moves on.
Most products in this category advertise many views. A small team reliably uses three or four, and the ones it uses are decided by the question being asked, not by preference.
| View | The question it answers honestly | When it starts lying |
|---|---|---|
| Kanban board | What is in flight and who is waiting on whom | Once deadlines matter more than order |
| Calendar | What lands on which day | For work spanning weeks with no single date |
| Timeline or Gantt | Does the sequence fit before the deadline | When dependencies are guessed rather than known |
| List grouped by person | Who is overloaded next week | Without one owner and one date per card |
The important question when shortlisting is not how many views exist. It is whether the views read from the same cards. Two views built on two separate data entries will disagree within a fortnight, and the one that disagrees is the one that stops being updated. A timeline that has to be maintained by hand alongside the board is a second job, and it is the job that gets dropped in a busy week.
Cost enters here in a way feature comparisons tend to obscure. Timeline views, custom fields and permission controls sit behind higher tiers in several products, so a team can adopt a board on a free tier and discover that the view it needs to plan with is the paid one. Checking that before adoption rather than after is the whole point of reading a pricing page early, and comparisons such as Pinateca vs Asana are useful mainly for seeing which capabilities each product places behind which tier.
Dedicated proofing software exists because project tools are poor at one specific thing: putting a comment on a precise point of an image, a PDF page or a frame of video, and locking a version so that comment cannot drift.
That difference is real and worth paying for under two conditions. Reviews involve video or long PDFs, where pointing at a timestamp or a page is the only way to be precise. Or the number of reviewers is large enough that comments genuinely need to be consolidated by the tool rather than by a person.
Below that threshold, a proofing tool adds a second place to check, which is the exact problem this article opened with. For a five person studio reviewing static assets with one client approver, attaching the file to the card and writing feedback in the card comments is faster and keeps the history in one place.
Where both are in use, one rule keeps it sane: the proofing tool holds the markup, and the card holds the decision. The card records that round 2 was approved, with a link to the markup. Anyone reading the card six weeks later gets the answer without opening a second product.
Creative teams generate large files, and no project management tool is a sensible home for working files. Trying to make it one produces a board that is slow and a storage bill that is surprising.
The arrangement that works is that working files stay in the drive or the design tool, and the card holds a link plus the exported version that was reviewed. The exported flat file on the card is what makes the history readable later. A link to a living design document shows the current state, not the state that was approved, which is the wrong answer to the only question anybody asks in a dispute.
Two details are worth confirming before committing to a tool. How much file storage the plan includes, because a studio attaching exported assets to every round consumes it faster than a document team does. And whether files remain accessible when a person leaves, which depends on whether uploads belong to the workspace or to an individual account. Both questions are answerable from the vendor's own features documentation, and neither tends to appear in third party comparison lists.
A creative team's schedule is almost always limited by one or two people, and no amount of process changes that. What a tool can do is make the limit visible early enough to be negotiated.
That requires one view showing every card assigned to a person, across every project, with a date. Two conditions make it honest: one owner per card, and a date on every card in progress. With those in place, a commitment conversation takes two minutes and is based on what is already promised.
The number most often missed on that screen is the count of cards sitting With client. That work will come back, usually in a batch, and it does not appear in anyone's estimate of the coming week. A studio that tracks nothing else should track that.
What that view changes is the shape of the conversation. Without it, a request for a deliverable next Thursday is answered with an instinct, and the instinct is usually optimistic because the person answering is not the person who has to build it. With it, the answer is a reading of a screen, and the negotiation moves from whether it is possible to which of the existing commitments moves. That is a better conversation to have with a client on the day the work is requested than on the day it is late.
Put the round number on the card and write the approval in the same place as the work, starting with the next deliverable that goes out for review. That single change ends most of the arguments about what was agreed. If the board, the chat and the schedule are currently in three products, consolidating them is the second change, and Pinateca keeps the board types and the chat in the same place so that the copy across stops being a chore.
The work loops instead of proceeding in one direction, so the round number, the version history and the record of who approved what matter more than a task hierarchy. Tools aimed at creative teams usually add proofing or asset handling for that reason. A general tool works well if the board can show rounds and keep feedback on the card.
For static assets with one or two reviewers, attaching the export to the card and keeping comments there is faster and keeps one history. Dedicated proofing earns its place with video, long PDFs or many reviewers, where pointing at a timestamp or a page and locking a version cannot be done any other way.
Two included rounds with any further rounds billed is a common arrangement, and the exact number matters less than stating it in writing before work starts. The condition that makes it enforceable is counting rounds visibly on the card, since a round nobody counted is a round nobody bills.
Often yes, provided the views the team plans with are in the free tier rather than behind an upgrade. The two limits to check are the number of people counted and whether client reviewers who only look are counted as paid seats, because a studio with several clients can add more viewers than makers.