UXy Lab homeStart a project

Case study

arbitrr

Delivery intelligence for digital teams

arbitrr connects to the tools delivery teams already use and, every night, finds the risks, opportunities and people they should know about. I researched, designed and built it myself, including the AI integration. Two years in the making.

Role
Research, design, build
Timeline
2 years
Status
Live
Link
arbitrr.com
The arbitrr dashboard: a delivery intelligence panel for seven active projects showing 35 total findings split into 12 risks, 11 opportunities and 12 people to meet, beside a feed of findings labelled risk or opportunity with the source and date of each.

The problem

Digital teams keep their knowledge in Jira, Slack, shared drives and Teams. Lessons learned on one project rarely reach the next, risks get spotted too late, and people working on the same problems in different teams never talk.

Delivery managers know the information exists somewhere. They just can't see it all at once.

The knowledge is there. Nobody can see it all at once.

Key design decisions

Building an AI product people actually trust meant making some deliberate choices.

  1. Findings, not a feed

    Most tools bury people in notifications. arbitrr shows a handful of findings worth acting on, sorted into three kinds: risks, opportunities and people to meet.

    The arbitrr findings feed: a column of finding cards labelled risk, opportunity or person to meet, each with its source and date, beside the selected risk open in a detail panel showing what happens if it is ignored and two next actions.
    The findings feed with a selected risk open in the detail panel

  2. Show the receipts

    People don't trust AI that can't explain itself. Every finding is backed by verbatim quotes from the real tickets, messages and documents it came from, one click away.

    A risk on the arbitrr evidence graph, 'Integration dependency between two active workstreams has no documented owner', shown as a card with the three sources it came from linked to it: an integration design document last edited three weeks ago, a Jira ticket PROJ-847 with no assignee for fourteen days, and a Slack message in the delivery channel asking about the dependency with no response. A high confidence marker sits below the risk.
    A risk shown with the document, ticket and message it came from

  3. Strict rules over clever AI

    Findings that can't be traced back to a real source are thrown out before anyone sees them. arbitrr also never comments on individual people's performance. It's a tool for teams, not for surveillance.

    Three arbitrr findings shown as cards, each linked to the tool it came from: a person to meet from a Slack conversation two days ago, a risk that two workstreams are scoping the same delivery area from a Jira ticket, and an opportunity to reuse a proven vendor onboarding approach from a Google Drive document four days ago. Behind them, the dashboard shows 12 findings in total.
    Every finding names the tool and date it came from

  4. People stay in control

    Nothing happens without the user saying so. A Jira ticket is pre-filled but never created until it's confirmed. Dismissing a finding teaches arbitrr what that person doesn't need to see.

    The bottom of an arbitrr opportunity: a 'Potential benefit gained from this opportunity' section listing three benefits, and below it an 'Actions' section offering three choices the person can take, each as an outlined button with an arrow: add to my backlog, view document in Google Workspace, or email a colleague.
    arbitrr suggests the next step; you decide whether to take it

  5. Writing the AI's words

    The AI's writing follows content design rules: plain headlines, no invented numbers, and sources stated in plain sentences, like 'Tom raised it in Slack on 14 May', instead of metadata.

    An arbitrr finding written in plain English: the headline 'RWS already solved the double-charge retry problem PRK is building from scratch', the project label 'Kestrel Parking Permit Renewals (PRK)', and a paragraph that names its sources in plain sentences, a colleague's write-up in the RWS recurring payment idempotency note and PRK's own discovery note, rather than listing metadata.
    A finding in plain English, with its sources named in the sentence

Designed and built

I didn't hand designs to a development team. I took arbitrr from research through to a live product.

  1. Discovery
  2. Usability testing
  3. Prototype
  4. Requirements
  5. Build

  • Research

    I interviewed industry experts and potential users during discovery, then ran usability testing on the early designs. What I learned shaped each round of changes.

  • Design

    I turned the discovery findings into the product design in Figma, then built a full working prototype in Figma Make. That prototype became the basis for the product requirements.

  • Build

    I built arbitrr from those requirements: the front end, the connections to Jira, Slack, Google Drive and Microsoft Teams, and the rules that decide which findings the AI surfaces and who sees them.

Where it is now

arbitrr is live. I'm now talking to organisations about using it, and looking for a development partner to help take it from a working product to software that can grow with its customers.

What's next

The aim is for arbitrr to become a standard tool for UCD and digital delivery teams, first in the UK and then further afield.

Visit arbitrr.com Ask for a demo

Read what building arbitrr taught me

What this means for your project

Your website won't need an AI engine. But it will get the same approach: research before design, words people understand, accessible by default, and built properly so it lasts.

See how website projects work

Got something complicated? Let's talk.