• Context
• Context
OVERVIEW
OVERVIEW
One Tool. No More Chasing.
One Tool. No More Chasing.
LoopOps is an internal request management tool designed for growing tech companies where operational requests (new laptops, software licenses, travel approvals, budget sign-offs) fall through the cracks of Slack threads and email chains. It gives employees one place to submit and track requests, and managers one place to review and decide.
LoopOps is an internal request management tool designed for growing tech companies where operational requests (new laptops, software licenses, travel approvals, budget sign-offs) fall through the cracks of Slack threads and email chains. It gives employees one place to submit and track requests, and managers one place to review and decide.
• Problem
• Problem
THE GAP
THE GAP
Lost in Slack, Email, and Sheets
Lost in Slack, Email, and Sheets
Every growing company hits the same wall. Requests go out through whoever seems responsible: a Slack DM, an email thread, a shared doc nobody updates. There's no single place to submit, no way to track, and no record of what was decided or why.
The friction compounds fast. Employees spend more time chasing approvals than doing their actual work. Managers are buried in disconnected messages with no way to prioritize or audit decisions.
The result is wasted time on both sides. Requests get forgotten. Nothing moves.
Every growing company hits the same wall. Requests go out through whoever seems responsible: a Slack DM, an email thread, a shared doc nobody updates. There's no single place to submit, no way to track, and no record of what was decided or why.
The friction compounds fast. Employees spend more time chasing approvals than doing their actual work. Managers are buried in disconnected messages with no way to prioritize or audit decisions.
The result is wasted time on both sides. Requests get forgotten. Nothing moves.
• Users & Roles
• Users & Roles
WHO IT'S FOR
WHO IT'S FOR
Two People, One Broken Loop.
Two People, One Broken Loop.
• Information Architecture
• Information Architecture
HOW IT'S STRUCTURED
HOW IT'S STRUCTURED
A System Built for Three Roles
A System Built for Three Roles
The system is organized around three roles: Employee, Manager, and Admin, each with a distinct set of screens and permissions. The case study focuses on the Employee and Manager experiences, where the core request loop lives.
The system is organized around three roles: Employee, Manager, and Admin, each with a distinct set of screens and permissions. The case study focuses on the Employee and Manager experiences, where the core request loop lives.
• User Flows
• User Flows
HOW USERS MOVE THROUGH IT
HOW USERS MOVE THROUGH IT
Mapped Before a Single Screen
Mapped Before a Single Screen
Both flows were mapped before any screens were designed, to make sure the system logic was sound before the UI was built.
Both flows were mapped before any screens were designed, to make sure the system logic was sound before the UI was built.
Employee Flow
Employee Flow
Employee flow follows Alex from realizing she needs something, to submitting a request, tracking its status, and getting notified when a decision is made. The flow accounts for three outcomes: approved, rejected, or sent back for more information.
Employee flow follows Alex from realizing she needs something, to submitting a request, tracking its status, and getting notified when a decision is made. The flow accounts for three outcomes: approved, rejected, or sent back for more information.
Manager Flow
Manager Flow
Manager flow follows Jordan from receiving a notification, scanning the approval queue by priority, reviewing the full request detail, and making a decision with a reason attached.
Manager flow follows Jordan from receiving a notification, scanning the approval queue by priority, reviewing the full request detail, and making a decision with a reason attached.
• Employee Experience
• Employee Experience
SUBMIT, TRACK, STAY INFORMED
SUBMIT, TRACK, STAY INFORMED
Clarity at Every Step
Clarity at Every Step
Dashboard to New Request to My Requests, with full visibility into every ask along the way.
Dashboard to New Request to My Requests, with full visibility into every ask along the way.
DASHBOARD
DASHBOARD
Alex's starting point. Four stat cards give her an immediate read on her request activity: active, resolved, needs input, and average response time. The active requests table below shows status at a glance, so she never has to chase anyone to find out where things stand.
Before this redesign, a buyer's saved projects and their investment activity lived in two separate lists on the homepage, with no shared logic connecting them. A project that had been saved, one actively generating credits, and one that had already finished delivering all looked the same: just another row in a list. There was no way to tell, at a glance, what stage anything was actually in.
I redesigned this into a single unified list, with a summary strip up top so a buyer knows the shape of their portfolio before reading a single row.
NEW REQUEST FORM
NEW REQUEST FORM
Designed to reduce back-and-forth. Category selection uses a visual grid so Alex can move fast. A contextual sidebar shows who the request is going to and an estimated response time based on priority, before she even submits. Tips for faster approval coach her upfront, reducing the need for Jordan to ask follow-up questions.
Before this redesign, a buyer's saved projects and their investment activity lived in two separate lists on the homepage, with no shared logic connecting them. A project that had been saved, one actively generating credits, and one that had already finished delivering all looked the same: just another row in a list. There was no way to tell, at a glance, what stage anything was actually in.
I redesigned this into a single unified list, with a summary strip up top so a buyer knows the shape of their portfolio before reading a single row.
MY REQUESTS
MY REQUESTS
Alex's full request history, filterable by status and category. Four summary stats at the top give her a personal approval rate and average resolution time, light accountability that encourages better request quality over time. Every row is clickable, opening the full request detail.
Before this redesign, a buyer's saved projects and their investment activity lived in two separate lists on the homepage, with no shared logic connecting them. A project that had been saved, one actively generating credits, and one that had already finished delivering all looked the same: just another row in a list. There was no way to tell, at a glance, what stage anything was actually in.
I redesigned this into a single unified list, with a summary strip up top so a buyer knows the shape of their portfolio before reading a single row.
• Manager Experience
• Manager Experience
REVIEW, DECIDE, MOVE ON
REVIEW, DECIDE, MOVE ON
Decisions Without the Digging
Decisions Without the Digging
Approval Queue to Request Review to Team Overview, with every decision made in one place.
Approval Queue to Request Review to Team Overview, every decision made in one place.
APPROVAL QUEUE
APPROVAL QUEUE
Jordan's inbox. Requests are listed with a Waiting column that flags overdue items in red, the most important signal on the page. Quick Approve and Reject buttons let her clear straightforward requests without opening them. Clicking the row or hitting Review opens the full detail.
Before this redesign, a buyer's saved projects and their investment activity lived in two separate lists on the homepage, with no shared logic connecting them. A project that had been saved, one actively generating credits, and one that had already finished delivering all looked the same: just another row in a list. There was no way to tell, at a glance, what stage anything was actually in.
I redesigned this into a single unified list, with a summary strip up top so a buyer knows the shape of their portfolio before reading a single row.
REQUEST REVIEW
REQUEST REVIEW
The decision screen. Jordan sees the full description, attachments, and the comment thread between her and the employee. A decision panel on the right has three tabs: Approve, Reject, and Ask, each with a note field and a dedicated action button. An overdue banner at the top creates urgency without being destructive. Prev/Next navigation lets her move through the queue without returning to the list.
Before this redesign, a buyer's saved projects and their investment activity lived in two separate lists on the homepage, with no shared logic connecting them. A project that had been saved, one actively generating credits, and one that had already finished delivering all looked the same: just another row in a list. There was no way to tell, at a glance, what stage anything was actually in.
I redesigned this into a single unified list, with a summary strip up top so a buyer knows the shape of their portfolio before reading a single row.
TEAM OVERVIEW
TEAM OVERVIEW
A manager-level view of request activity across the full team. Each member row shows their approved, rejected, and active requests as pill tags: fast to scan, no complex charts. A category breakdown on the right shows where most requests come from, useful for spotting budget patterns or recurring friction points.
Before this redesign, a buyer's saved projects and their investment activity lived in two separate lists on the homepage, with no shared logic connecting them. A project that had been saved, one actively generating credits, and one that had already finished delivering all looked the same: just another row in a list. There was no way to tell, at a glance, what stage anything was actually in.
I redesigned this into a single unified list, with a summary strip up top so a buyer knows the shape of their portfolio before reading a single row.
• Outcome
• Outcome
WHAT I LEARNED
WHAT I LEARNED
One System of Record
One System of Record
LoopOps replaced a fragmented email, Slack, and spreadsheet workflow with a single system of record: one place for employees to submit and track, one place for managers to review and decide.
Key design decisions that drive this:
Visibility over assumptions
Employees see exactly where their request stands at every step. No more chasing.
Speed for managers
The queue surfaces overdue requests first. Inline actions mean fast decisions stay fast.
Context before decisions
The Request Review screen puts everything Jordan needs in one view: description, attachments, comment history, cost estimate, and SLA status.
Coaching at the point of submission
The New Request Form tells employees what makes a request more likely to be approved, reducing back-and-forth before it starts.
Working on Atmos reinforced that trust isn't something you add to a product, it's something you arrange. The rating, the track record, the alignment tags: none of it was new information. It all existed before I touched anything. The redesign was entirely about where that data sat and how much effort it took to reach, not about adding anything the platform didn't already have.
It also clarified how much comparison-heavy tasks benefit from front-loading the deciding factor. When someone's job is to compare multiple options against one standard, that standard belongs in the list view, not gated behind a click.