Overview
FloBrain puts tasks, calendars, chat and AI Buddy in one workspace. I designed it around one question: how can AI take on the busywork of starting a project, while people stay in charge of every commitment?
Problem
FloLabs is a remote team. We planned projects in Notion, talked in Discord and met on Zoom. Starting a project meant three separate jobs: finding people with the right skills, finding a time that works, and turning the discussion into a plan. Each job sent you to a different app.
My manager wanted one workspace that brought this together, one FloLabs could later offer to other companies. The AI Buddy flows came from what I saw in our own remote teamwork: too many meetings to arrange, and too much switching between tools to arrange them.
How AI and people split the work
I listed every step between "I have a project" and "we have a kickoff," then sorted them: which steps are prep work an AI can do, and which need a person's judgment.
- AI prepares: recommends collaborators by skill, finds times that work, drafts a project outline.
- People commit: invite teammates, book the meeting, add tasks.
One rule came out of this: a suggestion is never a commitment until a person explicitly confirms it.
In the prototype, all three live in the FloBrain AI panel. None of them is connected to a real calendar or task list yet.
Who should join
Teammates sorted by how many of the needed skills they cover, with where each skill came from.
When everyone is free
Three suggested times, the earliest all-free slot marked Best, and the grid behind it.
What the plan starts with
Phases and tasks drafted from a short brief. Switch tasks off before you add them.
Key decisions
Decision 1Show the skills, not a score
My first version gave each recommended teammate a match score, like 94%. When I looked back at it after the internship, I couldn't answer the first question anyone would ask: what does 94% mean? A precise number made the AI look more certain than it was, and gave people nothing to check.
So I replaced the score with the skills themselves. Each card now says how many of the project's needed skills a person covers, and only exact matches count. A related skill, like After Effects for a Motion need, is shown but kept out of the count, so the number never stretches.
Two things still need a person's judgment. Some skills were listed by the person and some were inferred from their past projects, and an inference can be wrong, so each card shows which is which. And the count treats every skill as equally important and ignores timing, so availability and workload stay on the card. The count is where you start, not the answer.
After: the skills behind it.
Decision 2Show the calendar, not just the answer
The Schedule tab suggests three times and marks the earliest one when everyone is free. Below that, everyone's availability is shown as a grid, and any slot that doesn't work for everyone says who's missing.
Sometimes a slot with one person missing is the right call, and sometimes that person is the one you need. The grid can't know which, so it shows you who's missing and leaves the choice to you. In the prototype, a slot only shows as booked after you press Book.
Decision 3Nothing lands until you add it
The Outline tab drafts phases and tasks from a short project brief. Any task can be switched off first, and the button counts what's left, so you know exactly what you're adding before you press it.
Decision 4Keep AI next to the work
I considered a popup and a separate AI page. A popup was too small for what AI Buddy needed to show, and AI Buddy was the feature we most wanted to build out. A separate page pulled you away from your work, so you couldn't look at a project while asking who should join it. A right-side panel keeps both on screen, and closes when you don't need it.
Final design
Interactive prototype. Names and numbers are sample data.
Reflection
Of the six proposals, the team saw mine as the one most likely to move forward. FloLabs is still working out the product’s MVP and business model, and the prototype has only had an informal test with four people.
After the internship, I asked four people to plan a project kickoff in the prototype: two FloLabs colleagues who hadn’t worked on FloBrain, and two classmates. The colleagues tried it on their own and sent me written feedback; I watched the classmates use it and asked follow-up questions. Because the conditions differed, I treat what they said as feedback, not as comparable results.
Three of the four said suggestions like these would save time finding teammates, especially in a large company. Two said they’d treat the suggestions as a starting point and still double-check, which fits what I designed for. The feedback also showed three gaps:
- The reasons behind a match weren’t clear. One person didn’t understand the difference between “Listed by” and “From 2 projects,” and another wanted to know why the project needed those skills in the first place. Next, I’d explain both: what each skill source means, and where the project’s list of needed skills comes from.
- Invitees’ agreement wasn’t visible. One person asked whether they should wait for a teammate to accept the invite before booking a time. The prototype lets you book right away. My rule kept the AI from committing anyone, but I hadn’t made the invitees’ agreement visible in the booking flow. Next, I’d show which invites are pending and which are accepted, and mark meetings as tentative or confirmed, then test whether booking should wait at all.
- Schedule needed more context. One person wasn’t sure where the availability came from, and another couldn’t tell whether later times were available or where a booking notice would appear. Next, I’d show where the availability comes from, make the time range clear, and confirm explicitly what happens after Book.
Four people can show me usability problems like these, but not how much people would trust AI recommendations at a larger company.
The feedback changed how I understood human control. A confirmation button gives someone a choice, but they also need to understand the suggestion’s basis, whose agreement is still pending, and what their action will trigger. My next revision would make those dependencies clearer across People and Schedule.