Detailed
TL;DR
Fluorine AI created tasks.
I designed the flow that reads project chat and updates task status
Fluorine AI created tasks.
I designed the flow that reads project chat and updates task status
Fluorine AI created tasks.
I designed the flow that reads project chat and updates task status
Role
Product Design, UX Strategy, AI Interaction Design, Visual Design
Project
Fluorine
Product
AI-native B2B SaaS
Overview
Fluorine is a project management SaaS with an AI assistant called Flo. It could create tasks directly from command, but task status still had to be updated by the user manually.
So, I designed the project chat and review flow so users could see Flo’s suggestion first and decide if they wanted to update the task or not.
Before
After
Before
After
Problem statement
Task status fell behind when work moved before the board was updated
Task status fell behind when work moved before the board was updated
Task status fell behind when work moved before the board was updated
Task status still had to be updated manually, so if work moved forward before the board was updated, the task could keep showing an old status.
Task status still had to be updated manually, so if work moved forward before the board was updated, the task could keep showing an old status.
Task status still had to be updated manually. Every change depended on someone returning to the board and reordering the task status.
Task status still had to be updated manually. Every change depended on someone returning to the board and reordering the task status.
The gap appeared when work moved forward before the board was updated. If that step was missed, the task kept showing an old status.
The gap appeared when work moved forward before the board was updated. If that step was missed, the task kept showing an old status.
Task status changed only when someone updated it manually.
Task status changed only when someone updated it manually.
The update usually came after the work had already moved.
The update usually came after the work had already moved.
A missed update could leave the task showing an old status.
A missed update could leave the task showing an old status.
The board could show a different state from the work itself.
The board could show a different state from the work itself.
Work moved first. The board still needed a manual update.
Diagnosis
Task creation had AI help, but status updates did not
Task creation had AI help, but status updates did not
Task creation had AI help, but status updates did not
I reviewed Fluorine’s existing AI flow and the ClickUp flow I studied. The gap was clear: both started with a direct command, while project chat did not.
I reviewed Fluorine’s existing AI flow and the ClickUp flow I studied. The gap was clear: both started with a direct command, while project chat did not.
Fluorine AI worked from clear commands. The user told it what task to create, then reviewed or approved the result.
Fluorine AI worked from clear commands. The user told it what task to create, then reviewed or approved the result.
Status updates sat outside that AI flow. Users still changed existing task status manually.
Status updates sat outside that AI flow. Users still changed existing task status manually.
In the ClickUp flow I reviewed, the user directly command AI to change a task, so the action was already clear.
In the ClickUp flow I reviewed, the user directly command AI to change a task, so the action was already clear.
Project chat was different. A team message could describe progress without asking Flo to change anything.
Project chat was different. A team message could describe progress without asking Flo to change anything.
If Flo found a task update in chat, should it act first or wait for the user?
What I tried first
Flo changed tasks before users could review them
Flo changed tasks before users could review them
Flo changed tasks before users could review them
My first version let Flo act on team messages before asking the user to review the change.
My first version let Flo act on team messages before asking the user to review the change.
Attempt one: act first, review later
I designed project chat so team members could discuss work inside each project and give Flo could read those updates.
I designed project chat so team members could discuss work inside each project and give Flo could read those updates.
Flo read the message, found the related task or tasks, and updated their status right away. Only tasks moved to Blocked showed Confirm or Dismiss with a notes.
Flo read the message, found the related task or tasks, and updated their status right away. Only tasks moved to Blocked showed Confirm or Dismiss with a notes.
Attempt one: act first, review later
What user feedback changed
The client tested this version with users. They were worried because Flo changed task status before they could review what it had found.
The client tested this version with users. They were worried because Flo changed task status before they could review what it had found.
That feedback changed the flow. Flo would still find the related tasks, but the board would stay unchanged until the user chose an action.
That feedback changed the flow. Flo would still find the related tasks, but the board would stay unchanged until the user chose an action.
What user feedback changed
Attempt two: move review before action
I then moved the review step before the task changed. Flo showed the related task, proposed status, source message, and confidence before changing anything on the project board.
I then moved the review step before the task changed. Flo showed the related task, proposed status, source message, and confidence before changing anything on the project board.
The proposal gave three choices. Update Task applied the change. Not Now kept the current status. Ask Flo opened a conversation about the suggestion. If the user took no action, the task stayed unchanged.
The proposal gave three choices. Update Task applied the change. Not Now kept the current status. Ask Flo opened a conversation about the suggestion. If the user took no action, the task stayed unchanged.
Attempt two: move review before action
How I judged them
The first version moved faster, but users lost control over when the board changed. The second kept the task unchanged until they reviewed Flo's suggestion.
The first version moved faster, but users lost control over when the board changed. The second kept the task unchanged until they reviewed Flo's suggestion.
I kept task detection and motion, but moved the user decision before the update.
I kept task detection and motion, but moved the user decision before the update.
Flo could prepare the update, but the user decided whether the task should change.
The decision
The board should wait until the user decides
The board should wait until the user decides
The board should wait until the user decides
User feedback made the direction clear. Flo could still prepare the update, but the user had to decide before the board changed.
User feedback made the direction clear. Flo could still prepare the update, but the user had to decide before the board changed.
How I got there
I kept what worked from the first flow: Flo could read the conversation and find related tasks. I moved the decision before the update.
I kept what worked from the first flow: Flo could read the conversation and find related tasks. I moved the decision before the update.
How I got there
What shaped the decision
Flo had to work from normal team conversations, not a direct command.
Flo had to work from normal team conversations, not a direct command.
One message could relate to more than one task, so each match had to stay clear.
One message could relate to more than one task, so each match had to stay clear.
Users needed to see what Flo found before anything changed on the board.
Users needed to see what Flo found before anything changed on the board.
Flo had to understand team conversations, match the right tasks, and show users its findings before anything changed.
Flo had to understand team conversations, match the right tasks, and show users its findings before anything changed.
The change
Before: Flo changed tasks before review.
Before: Flo changed tasks before review.
After: Flo showed the change and waited for the user actions.
After: Flo showed the change and waited for the user actions.
I moved the decision before the status update. Flo could prepare the change, but the task stayed as it was until the user acted.
I moved the decision before the status update. Flo could prepare the change, but the task stayed as it was until the user acted.
The rule
I carried one rule into the final flow.
I carried one rule into the final flow.
Flo should show the task and proposed change first. The user decides whether to apply it. Only then should the task status change.
Flo could prepare the update. The user decided when it became real.
The solution
Flo shows the proposal
before updating the project board
Flo shows the proposal
before updating the project board
Flo shows the proposal
before updating the project board
The final flow follows one rule: Flo can prepare a task update, but nothing changes until the user reviews it and chooses.
The final flow follows one rule: Flo can prepare a task update, but nothing changes until the user reviews it and chooses.
I designed the project chat so team members could discuss work inside each project. Flo reads the conversation, finds related tasks, and prepares an update.
I designed the project chat so team members could discuss work inside each project. Flo reads the conversation, finds related tasks, and prepares an update.
I designed project chat for team discussions. Flo reads the conversation, finds related tasks, and prepares an update.
I designed project chat for team discussions. Flo reads the conversation, finds related tasks, and prepares an update.
The proposal shows the current status, suggested status, source message, and confidence. The user can check what Flo found before taking action what to do.
The proposal shows the current status, suggested status, source message, and confidence. The user can check what Flo found before taking action what to do.
The proposal shows the suggested change, source, and confidence so users can review it before acting.
The proposal shows the suggested change, source, and confidence so users can review it before acting.
Update Task applies the change. Not Now keeps the current status. Ask Flo opens a conversation about the suggestion.
Update Task applies the change. Not Now keeps the current status. Ask Flo opens a conversation about the suggestion.
After approval, the task moves to its new status with a visible transition. The motion shows what changed from the old state to the new one.
After approval, the task moves to its new status with a visible transition. The motion shows what changed from the old state to the new one.
After approval, the task moves to its new status with a visible transition showing what changed.
After approval, the task moves to its new status with a visible transition showing what changed.
The same flow works across the project views. Flo reads the message, finds the task, shows the proposal, waits for a choice, then updates the task if approved.
The same flow works across the project views. Flo reads the message, finds the task, shows the proposal, waits for a choice, then updates the task if approved.
The same flow works across all project views, with Flo proposing updates and applying them only after user approval.
The same flow works across all project views, with Flo proposing updates and applying them only after user approval.
No action means the task stays unchanged.
No action means the task stays unchanged.
Together, these states form the complete task-update flow across project chat, Flo, and the project board.
Together, these states form the complete task-update flow across project chat, Flo, and the project board.
The final flow was ready to go back to the client and users for review.
Validation
User feedback changed the flow before final approval
User feedback changed the flow before final approval
User feedback changed the flow before final approval
The client tested the first version with users. They were worried that Flo changed tasks before review, so I moved the decision before the update.
The client tested the first version with users. They were worried that Flo changed tasks before review, so I moved the decision before the update.
What users noticed
Users were uncomfortable because Flo changed task status before they could review what it had found. Only Blocked changes asked for Confirm or Dismiss.
Users were uncomfortable because Flo changed task status before they could review what it had found. Only Blocked changes asked for Confirm or Dismiss.
What users noticed
What changed after feedback
I moved review before action. Flo now shows the related task, proposed status, source, and confidence first. The board stays unchanged until the user chooses.
I moved review before action. Flo now shows the related task, proposed status, source, and confidence first. The board stays unchanged until the user chooses.
What changed after feedback
What happened in the second review
The client approved the revised flow, and users were satisfied with it. They could review Flo's suggestion before deciding whether the task should change.
The client approved the revised flow, and users were satisfied with it. They could review Flo's suggestion before deciding whether the task should change.
The first review exposed the problem.
The second confirmed the new direction.
The first review exposed the problem. The second confirmed the new direction.
Reflection
I’d keep review before action and test earlier
I’d keep review before action and test earlier
I’d keep review before action and test earlier
What I'd defend
I’d keep the review step before Flo changes a task. The second version gave users a chance to check the proposal first, and they were satisfied with that flow.
I’d keep the review step before Flo changes a task. The second version gave users a chance to check the proposal first, and they were satisfied with that flow.
The final flow gave users control before a task changed. Looking back, I’d test that core interaction earlier and keep watching how users respond to Flo’s suggestions.
The final flow gave users control before a task changed. Looking back, I’d test that core interaction earlier and keep watching how users respond to Flo’s suggestions.
The interaction I’d keep
What I'd do differently
I’d bring users in earlier, before the first flow was fully shaped. Their feedback changed the core interaction, so earlier testing could have helped me reach the stronger direction earlier. I’d also test whether confidence and Ask Flo help users make a decision or add unnecessary noise.
I’d bring users in earlier, before the first flow was fully shaped. Their feedback changed the core interaction, so earlier testing could have helped me reach the stronger direction earlier. I’d also test whether confidence and Ask Flo help users make a decision or add unnecessary noise.
What I'd do differently
What I'd watch
I’d track how often users update, dismiss, or question Flo’s suggestions, and how often approved updates are later changed back.
I’d track how often users update, dismiss, or question Flo’s suggestions, and how often approved updates are later changed back.
Flo could suggest the update, but the user made the final call.
Showcase
From team conversation to a task status change the user reviews first
From team conversation to a task status change the user reviews first
From team conversation to a task status change the user reviews first
Contact
Have a role in mind?
imran.uxi@gmail.com
Copied
© 2026 Imran. All Rights Reserved.
Contact
Have a role in mind?
imran.uxi@gmail.com
Copied
© 2026 Imran. All Rights Reserved.
Contact
Have a role in mind?
imran.uxi@gmail.com
Copied
© 2026 Imran. All Rights Reserved.
Contact
Have a role in mind?
imran.uxi@gmail.com
Copied
© 2026 Imran. All Rights Reserved.
Contact
Have a role in mind?
imran.uxi@gmail.com
Copied
© 2026 Imran. All Rights Reserved.