Todoist and Twist support Windows, macOS, Android, iOS, and the web, giving users flexibility across devices. Maintaining those platforms also creates design debt: copy, text colors, icons, corner radiuses, warning modals, and emoji rendering can diverge between apps. These differences are particularly challenging for a product approaching 12 years old, such as Todoist.
Small inconsistencies become conspicuous when they accumulate. Over two years, Todoist’s designers and developers refined a collaborative process for resolving them alongside larger projects, using Todoist for tasks and Twist for communication.
Related resource: Designing Without Whiteboards: The Remote Guide to Product Design explores how teams at Todoist, Automattic, and Help Scout collaborate across borders.
Why the Team Changed Its Process
As the team expanded, designers and developers increasingly worked in separate silos. People did not always know what others were doing, whether a fix was live, or when it could be tested. Information spread across too many tools, making the latest updates difficult to locate.
The revised workflow pursued three goals:
- Fewer tools: Limit the process to Todoist and Twist, connecting task assignment within Todoist projects with status communication in Twist through automation.
- Less complexity: Pilot the process with the smaller Twist team, which had one developer per platform, rather than introduce it across both products immediately.
- Greater transparency: Make changes visible in Twist so anyone in the company could follow them.
The resulting process links four responsibilities:
- Report: A designer identifies a parity issue, proposes a design solution, and creates an implementation task.
- Implement: A developer makes the change, tells the designer when it is complete and available in beta, and requests review.
- Review: The designer checks the revised feature or fix in beta.
- Release: The designer confirms that the issue is resolved and ready for users.
This structure helps the team handle smaller fixes quickly and visibly without losing track of larger work.
Putting the Workflow Into Practice
Establish a Review Schedule
Cross-platform consistency requires deliberate QA, rather than waiting for someone to notice a problem. Todoist designers reserve time for regular checks; the source author, product designer Alex Muench, aims to spend a little time on QA every other morning.
Review frequency also follows release schedules. Todoist’s Web and Android apps receive updates more often than iOS, so they need checks accordingly. Scheduled searches for discrepancies help prevent an unmanageable backlog of design debt.
Create a Todoist Project for Each Platform
Each Twist platform has a dedicated Todoist project for reported QA and parity work. The naming pattern is “[Product] [Platform] Parity”, such as “Twist Web Parity”. Each project contains three sections:
- Implementation tasks: Designer-reported work assigned to developers. These “parity tasks” are generally small adjustments to align features, functionality, and visual design, rather than critical bugs.
- In review: Work awaiting a designer’s inspection. When implementation is finished, the developer completes the task, notifies the designer, and comments on when the change will be live.
- Done: Reviewed and implemented tasks are checked off and moved here.
Connect the Project to Twist
A Todoist integration sends project comment activity to a new thread in a Twist platform channel. This gives the company visibility into changes while keeping task management and discussion connected.
Configure the integration fields as follows:
- Post to channel: Choose the appropriate channel. The Twist team uses “Twist Parity & UI updates”. For Todoist, the team recommends existing platform channels such as “Todoist iOS” or “Todoist Android”.
- And in following thread: Select “new thread”.
- Who do you want to notify? Create a separate group within the channel for people who need notifications, then select that group in the integration settings.
- Who do you want to post from? Use the Todoist project name, such as “Twist iOS Parity”, so each thread is readily identifiable.
Keep Project Membership Small
Parity projects usually involve three people. For example, “Twist Web Parity” includes Head of Front-end Development Henning, Head of Support Malin, and Muench. The roles are:
- Product designer: Finds inconsistencies, designs solutions, assigns implementation, and reviews changes before release. This is often the “Design Hero”, a rotating month-long role for a designer or illustrator focused on app and design quality. Responsibilities include polishing icons, spotting inconsistencies, suggesting improvements, and handling small team requests.
- Platform developer: Implements changes for the relevant platform, such as iOS or Windows.
- Support specialist: Watches upcoming changes and communicates significant updates to support colleagues and users. This person mainly observes, intervening when a change could negatively affect users.
Add Tasks With Enough Context
The designer prepares each task in this order:
- Describe the issue, add it to the parity project, attach a platform label such as “@web”, and assign it to the developer.
- Add supporting material in a task comment: annotated screenshots made with tools such as CloudApp, mockups, links, and assets. Thorough context reduces delays from back-and-forth questions, especially on a remote team.
- Where relevant, explain the solution’s rationale in a comment. This helps developers describe changes accurately in changelogs and provides a place to discuss questions, including whether other components are affected or whether the issue is simply a bug.
- Assign the task to the developer and notify them in the added comment.
Order the Implementation Work
Developers generally work from oldest to newest, with incoming tasks added at the bottom. They assess the effort required or provide a rough time estimate.
Most items are small fixes. If a change involves substantial work, the developer alerts the designer and platform Head, such as the “Head of Android”. The team can discuss an interim solution or create a formal project proposal.
A designer or product team member can flag an urgent bug affecting users’ daily experience to the platform developer. That task moves higher in the list with increased priority, using Todoist’s task priority colors.
When priorities are unclear, the designer helps reorder implementation tasks. Developers should also communicate when the workload becomes difficult to manage.
Report Completed Implementation
After making the change, the developer tells the designer in a task comment that implementation is complete.
Return the Task to the Designer
The developer reassigns the task to the designer and updates its name to include the version number in which the change is live. This tells the designer when the implementation is available to inspect.
Move the Task to Review
The designer moves the task into “In review”. A developer may move it instead, but the designer remains responsible for ensuring tasks are in the correct section.
Test the Change and Close or Reopen the Task
The designer tests the live implementation or beta, then follows one of two paths:
- The change works as intended: Complete the task and move it to “Done”. No additional communication is required.
- Further work is needed: Add a comment explaining the problem, uncomplete the task, and reassign it to the developer. After making improvements, the developer returns it to the designer. Repeat the review cycle until no more changes are necessary.
Making Room for Small Improvements
Small refinements rarely fit neatly into a regular 4-6 week product cycle. Without a clear reporting and follow-up process, they can be repeatedly deprioritized. This workflow lets a small team address them in 1-5 days without pulling attention away from higher-impact projects.
The process continues to evolve. At the time of the article, the team was testing monthly developer and designer “heroes” dedicated to improvements and bug fixes, while others concentrated on new features and larger projects. The aim is consistent attention to quality in both major features and small details.
