ExoFlare
Year
2026
Role
- Sole product designer and builder
Project
- Internal tool, prompt built, in daily use
Selt-built tool for product design
My whole workload, pulled from five systems into one ranked queue. Built in an afternoon with Claude chat, inside the tool itself, and refined with daily use ever since.
I built the tool for myself, to prioritise my work, and answer the most important question of where should I be spending my time, at any given time.
Product Design at ExoFlare
In 2024, I joined ExoFlare as the company’s first (and only) product designer. ExoFlare is a Sydney-based biosecurity startup helping organisations control who and what moves between farms and production sites, reducing the risk of disease spreading.
I design both the business-facing platform and the visitor experience, while playing a hands-on role in discovery, ideation, and shaping new solutions to customer problems. Since 2025, we have operated without a dedicated product manager, so product management is shared across the team. For me, that means deciding which problems are most important to tackle and where my design effort will have the greatest impact.
The work is varied and rarely arrives through a single, tidy product process. I work across two Jira projects, a stream of ideas, and incoming requests captured in Help Scout, email, Notion meeting notes, Slack, and phone calls. My calendar is filled with customer conversations, product discussions, and team rituals.
As the senior product designer, I have a front-row seat to how ExoFlare interacts with its customers. I’m responsible not just for designing solutions, but for identifying the problems worth solving in the first place and connecting customer insight to product decisions.
The prioritisation problem
At any given moment, I could not confidently answer the most important question: what should I work on next?
Work lived across five systems that did not talk to each other. The same piece of work might exist as an autogenerated email from a customer interaction in Help Scout, a stale Jira ticket, a handwritten note from a meeting, or a saved conversation in Slack. These sources drifted apart. Captures got lost, became stale, or were overtaken by newer requests, creating an endless queue that no single person could realistically complete.
As a result, priorities often depended on who shouted the loudest, what had arrived most recently, or which tab happened to be open. Every morning started with manually reconciling five sources of work.
The result was a prioritisation problem. There was no trustworthy, data-backed way to answer the question that mattered most: what do I do now?
Where the idea came from
An engineer on the team built a dashboard that summarised activity in our code repository and shared it with the team on Slack. I immediately saw the potential to apply the same approach to my own problem.
He explained that he had used Claude connectors to pull data from the apps his dashboard relied on. Before the end of the day, I used Claude Chat to build my own dashboard, connecting the tools I relied on to create a single view of my work.
It was a quick experiment, but it changed how I thought about the problem. Instead of manually reconciling information across multiple systems, I could bring the data together and start building a more informed way to decide what to work on next.
The WorkDesk
My product design tool, WorkDesk, connects five systems through Claude connectors using the open Model Context Protocol (MCP), pulling specific, relevant information from each:
- Jira: My two projects, including open tickets, status, age, and priority.
- Notion: My private capture inbox, including only items that are still open.
- Slack: Messages I have saved for later, requests people have sent me.
- Gmail: Recent threads that appear to need a reply.
- Google Calendar: The day’s one-off meetings.
WorkDesk runs as a single-file app that calls an AI model on demand. The model reads across these sources, connects the context, and reasons over it to help me understand what needs attention and decide what to work on next.
The first features shipped
I started with a simple goal: turn a fragmented stream of work into a clear view of what needed my attention. The first version of WorkDesk included:
- Top 3: The desk weighs tickets, captures, saved Slack messages, emails, and my calendar, then proposes the three things worth doing right now. The list stays fixed across refreshes so it does not reshuffle while I am working. I can also swap an item for a fresh suggestion.
- Daily focus: WorkDesk generates a numbered summary of my Top 3 that I can copy and paste into our daily standup Slack channel. I deliberately kept this manual rather than automating the post, because I still wanted to review and edit what I shared.
- Proof of done: When I complete an item, WorkDesk checks the source system for evidence that the work actually happened, such as a Jira status change, a Slack reply, or a closed Notion capture. It then writes the completion back to the source, keeping the systems in sync.
- Notion tasks: My private to-do list was surfaced directly in the desk, with the ability to add new items.
- On Point: AI-generated observations suggested ways to combine tasks, use my time more effectively, or approach my workload differently.
- Email: Threads that appeared to need a response were surfaced alongside the rest of my work.
- Jira visibility: I could see tickets currently in Designing, items I had moved into Backlog Prep over the previous 30 days, and items that had progressed but were still waiting to reach Ready for Dev.
- Stale work: Tickets that had been untouched for six months were surfaced so they could be reassessed.
The Top 3 became the biggest time saver. Instead of spending the start of each morning reconciling systems and deciding what to work on, I could get straight into the work. The rest of the desk provided a peripheral view of everything I was juggling, without requiring me to keep five systems open and mentally reconcile them.
My process – built through daily use
I described each capability in plain language and refined it through conversation with Claude, my AI assistant. Each change was compiled and run through an automated render before it shipped, catching errors early. I reviewed every iteration by using it in my day-to-day work, then changed it whenever I noticed something was not working as expected.
I did not build WorkDesk once and walk away. I use it every day and refine it most days. Because I am also the user, I know immediately when something is wrong and can fix it in the same session. I am constantly thinking about how it could become more useful, particularly as I discover new ways to apply AI. That continuous loop of using, noticing, fixing, and extending is how the product evolves. Bugs do not come from a test plan. They come from real work.
Free visual design
I also spent almost no dedicated time on visual design. The palette, typography, and spacing came from the design instructions I already maintain for the platform, so WorkDesk inherited them automatically. A tool I started in a morning still feels on-brand because the design system and rules I had already established did the work for me.
What broke?
Moving into Claude Design
Once the first version was working, I moved WorkDesk into Claude Design to keep building.
This is where the Top 3 grew into a Top 8 and I added stats to see what was actually moving each week.
The move also changed the UI dramatically. My original design instructions did not carry across, and the dashboard took on Claude’s beige visual style. I left it. At this point I was focused on making the tool more useful, not polishing the interface.
How the queue ranks
The queue needed to do more than collect my work. It needed to decide what deserved my attention.
I created a points system based on signals I already use to prioritise: deadlines, someone waiting on me, meeting prep, age, quick wins and whether the same work appears across multiple sources.
Claude extracts the facts, but the scoring happens in code. This keeps the ranking predictable and lets me see exactly why something moved up the queue.
Teaching the ranking
I didn’t want to keep manually tweaking the points every time the ranking felt wrong.
Each item has a feedback menu where I can flag what is off, from missing links or due dates to something being ranked too high or too low. The feedback is logged in Notion with the item’s context, giving me a record of where the system gets things wrong.
Ranking feedback goes one step further. Repeated pushback adjusts the points system, so the queue can gradually learn what I value rather than relying on me to keep rewriting the rules.
Where my time was going
Once I had the basic workflow working, I started wondering what the desk could tell me about my work, not just what I should work on next.
I added a stats view to track things like tickets moved, captures cleared and asks answered over time. It gave me a way to look back at my workload rather than only looking forward at the next task.
They quickly showed something the queue had hidden: I was getting plenty done, but very little design work was actually moving forward.
That led me back to the ranking itself. I adjusted how ageing design work was scored and reserved two places in the Top 8 for design whenever it existed.
Automating the stats
The stats only worked if I remembered to refresh the dashboard, and different copies could end up with different histories.
I moved the history into Notion and started taking the recurring refresh into Claude Cowork, where it can run on a schedule. The dashboard stays interactive, while the routine data collection happens without me.
Testing a more transparent way to prioritise
My latest experiment takes the ranking beyond my own dashboard.
I’m exploring a shared board where the team can see my ranked work, understand why something sits where it does, and nudge an item with a reason.
It is less about solving an existing team problem and more about testing a discovery process: can I make competing priorities visible, capture the context behind requests, and learn from where people disagree with the ranking?
A nudge does not automatically change the queue. It comes back to me to accept or decline, turning the disagreement itself into useful input.
Until I iterate again
WorkDesk is still evolving. I use it every day, and that means I keep finding things to change, remove or build. The features will keep shifting with the way I work, and I’ll keep using the data and feedback it collects to decide what comes next. That is what I like most about building it this way: it does not need to be finished. It can keep changing as my needs do.
