Loopline
A dependency-first coordination platform for teams. Blockers made visible, decisions made fast.
- Type
- Self-initiated concept
- Year
- 2026
- Role
- Product & Brand Designer
- Sector
- Team Collaboration · SaaS
- Disciplines
- UX/UI, Branding
The Brief
Teams rarely slip on their own tasks — they slip waiting on each other. Cross-team dependencies live in chat threads and standups, invisible until they are already late. Loopline gives that hidden layer a home: who is blocked, on whom, and what decision clears the path.
The Approach
I designed the day as a loop. A Morning Snapshot opens it — today, tomorrow, unresolved blockers — and an End-of-Day Check-in closes it, where every task earns an honest outcome: done, carried over, or dropped. Dependencies are first-class objects with an owner, a status, and a thread — never chat messages. Members see their day; project managers see the whole board.
Constraints
Technical · BusinessOne dependency object, two views. The member app and the PM board derive from a single shared data model, so an engineer builds the object — owner, status, decision trail — once, and both surfaces stay in sync by construction.
Coordination tools are only worth it if they’re opened daily; a loop that takes more than a minute gets abandoned. I budgeted the Morning Snapshot and End-of-Day Check-in to under 60 seconds each so the habit survives a busy day.
AI in the Process
Tools- Claude Code
- Design-to-build partner — turning the system into working, clickable screens.
Process — 03
Two jobs, one loop
Mapped a team member’s day against a project manager’s week. The same blocker looked like a task to one and a risk to the other — so the system holds one object with two views.
One object, every surface
A request carries an owner, a status, and a decision trail. The PM board, the dependency map, and nudges all derive from that same object, so nothing gets lost in a thread.
A calm indigo system
A looped-circles mark, deep navy and indigo over a light workspace, one accent per status. Twenty screens wired into a clickable prototype where every screen has an entry and an exit.
Design Decisions
Cognitive rationaleEvery task gets an outcome at day’s end
Unfinished tasks create lingering mental tension. The End-of-Day Check-in forces each open item into done, carried, or dropped — naming the outcome discharges the tension, which is why people actually close their day instead of carrying it.
A dependency map, not a list
PMs see who blocks whom as a spatial map. Recognizing a relationship in a diagram is faster and lower-effort than recalling it from rows of text, so overload becomes visible at a glance.
Every request carries one named owner
In group chat, a blocker belongs to everyone and therefore no one, so it dies. Making each dependency an object with a single named owner removes the ambiguity that lets requests slip.
Micro-flows — 02
Selected user flowsCHOSEN MICRO-FLOW · PERSONA HANDSHAKE
Blocked to unblocked in seven minutes — Lior (Design) and Roi (Engineering) resolve a dependency across two swim-lanes, timestamped end to end.
MICRO-FLOW · FOCUS SPOTLIGHT
Two personas, seven surfaces — the full architecture dimmed to one illuminated loop, the one that gives Loopline its name.
User Research
Methods · Participants · InsightsKey Insights
- 01
Blockers travel by DM and die in threads. If a dependency is not an object with an owner, it does not exist.
- 02
Unfinished work has three honest futures — done, carried, or dropped. Naming them at day’s end is the feature.
- 03
PMs don’t need another dashboard. They need to know who is waiting on whom, right now — that’s a map, not a list.
Outcome
Designed to turn the invisible friction between teams into a visible loop: every blocker has an owner, and every day is framed to open with a snapshot and close with a decision. The full prototype clicks end to end — zero dead ends.
Reflection
Next step: run the daily loop with a real team for a week — the habit is the whole bet, and only real use can prove it.
Final Products — 04
Gallery
