Best Practices in Trello Workflow Design

Don’t Overthink It

Creating a workflow often has the side effect of making you think about your processes in detail. This usually has a positive effect, but don’t overthink it.

Human-driven processes are fluid and evolve as we encounter exceptions and adapt to change. Trying to cover every corner case or make your workflow watertight from the outset is a recipe for frustration.

Start out by creating the simplest base workflow that works for the most typical case. Do not optimize the process for edge cases or try to cover every eventuality from the get-go.

Take Advantage of Trello’s Flexibility

The beauty of Trello is that it’s not a straightjacket: if your base workflow covers 90% of the cases, you can create an exception list to handle special cases separately, or create a label to mark a type of exception. If a standard checklist doesn’t contain a few items you need for some special case, you can simply add the items to the checklist on that card only.

For example, a candidate may have interviewed with us in the past, and we only want to do two interviews instead of our usual three. We can simply edit the checklist in their card to remove the third interview.

Trello is best for organizing human processes, which are often fuzzy and variable in nature.

For people used to more strict process management software, Trello’s flexibility and open access can be unnerving. There is a tendency to try to “lock down” the workflow to prevent other users from straying away. This is an uphill battle in Trello, which is designed with open cooperation in mind.

Too Many States is Too Many

Try to limit your process to a reasonable number of meaningful states.

Instead of a single “Offer” state, we could have states for “Preparing Offer”, “Waiting for Offer Approval”, “Offer Issued”, and “Response Received”. This is clearly too many.

It’s better to mark these sub-states with labels, and filter or sort by label to see how many are in each situation within the current state.

A rule of thumb is if you can substitute the word “stage” for the word “state” and the states still sound chunky or hefty enough. Compare:

We have 5 people at the “Offer” stage, of which 2 have been issued an offer.

We have 3 people at the “Preparing Offer” stage, and 2 people at the “Offer Issued” stage.

In the second example, it sounds like our stages are very small. Although this is a subjective matter, the point is not to create micro-states.

Use (Or Not) Card Archival as a Final State

Every item must reach a final state in the process eventually. In a well-run process, items don’t hang around in middle states forever.

Finished items shouldn’t hang around either. Once your card has reached a final state, it’s best to remove it from view so that it doesn’t distract from running the process. A way to do this in Trello is to simply archive the card.

Archiving removes the card from view, but preserves all the information in it and lets you find it later by using search.

Archiving is enough for many workflows. But if you run a high-volume process, likely to generate thousands of cards over time, and periodically need to consult past work items, it will become a needle-in-a-haystack situation. In this case, we recommend to move the processed cards to another board instead of archiving them. The cards should be placed in a different list for each week or month, making it easier to find them by processing date.

every sunday, move all cards in list "Rejected Applications"

to list "Applications for week #{weeknumber} {year}"

on board "Process History"

This also makes it easier to comply with data retention policies: you can simply delete the history board and re-create it periodically to delete all cards in it.

At the end of the process, archive your Trello cards or move them to a separate history board.

Schedule is (Generally) Not a State

It’s tempting to use Trello as a team To-Do list and define your states by date: have states for “On-Site Interviews This Week”, “On-Site Interviews Next Week”, “On-Site Interviews This Month”, etc.

But these are not actual states. The fact that the interview is later this month doesn’t change the fact that the candidate is in the “On-Site Interviews” stage of the process.

Instead, use sorting and filtering by due date, and the Calendar Power-Up to have a temporal view of what needs to be done next.

In general, do not let time define your states. “Due this week” is not a state.

There is an exception to this, which is when time does substantially change the state of an item. For example, in an Editorial Workflow, stories scheduled to be published tomorrow are qualitatively different from stories that haven’t been given a publication date.

It’s Process, not Project

If you find yourself defining a workflow that involves a final date based on a cascade of task dependencies, then you need to think about project management, not process management.

Process management is concerned mostly about repeatability.

Trello is also great for project management, but it’s a different use case. Of course, you can have a process for project management to make sure you run projects consistently. We think that deserves its own separate article.

Iterate and Conquer

Once you’ve created an initial workflow, run the process with it for a while and gather experience. As you learn what works and what doesn’t, make incremental changes.

Managing a process is a learning process in itself.

For example, you may realize that a checklist is unnecessary, or that two states end up being the same and you need to merge them. You may want to add a custom field to store a piece of information that users find useful for the process. Etc.

Let what works best for your users evolve the design. Keep it simple and don’t lose focus on the most frequent use cases.