Tell us what you're building. We'll come back with a plan.
Designing Admin Dashboards That Operators Actually Like
Stop Building "Salesforce-Lite"
The default admin dashboard is a forest of nav rails, a generic data table, and a modal-heavy edit flow. It looks competent in screenshots. Then you watch a real operator try to process 40 refunds in a morning and realize the UI is fighting them on every click.
Operators are not infrequent power users. They live inside the tool for six hours a day. Every wasted click compounds into hours of friction per week. Designing for them is a different discipline from designing a marketing site or even a customer-facing SaaS UI.
Start From the Operator's Daily Flow
Before we open Figma we sit with the people who will use the tool. We watch them do their current workflow—usually a horrifying chain of spreadsheets, Slack threads, and one stagnant Notion page. We write down every action they take, in order, with timestamps.
That ordered list is the spec. The dashboard is not a CRUD app over the schema. It is a tool that turns "I need to process today's refunds and flag the suspicious ones" into the smallest possible number of keystrokes.
Tables Are the Product
In a customer-facing app, the table is a fallback. In an admin app, the table is the product. Get it right and the rest follows. Get it wrong and no amount of beautiful detail pages will save you.
Things we always include in our admin tables:
- Sticky header and first column so operators can scroll horizontally without losing context
- Inline editing for the two or three fields that change most often—status, owner, notes
- Column visibility controls that persist per user, not per session
- A density toggle because some operators want eight rows visible and some want forty
- Saved filters that show up as one-click chips at the top of the table
The fanciest detail-pane animation in the world is worth less than a table that lets a senior support agent triage 200 tickets without lifting their hands off the keyboard.
Bulk Actions and Keyboard Shortcuts
Single-row actions are for end users. Operators work in batches. Every admin table we ship has:
- Multi-row selection with shift-click for ranges
- A bulk action bar that animates in when anything is selected
- Keyboard shortcuts for the top three actions on every screen
- A discoverable shortcut overlay triggered by `?` or `cmd+k`
We tell our clients to expect about a 4x throughput improvement once their operators learn the shortcuts. We have never been wrong about that number.
The 80/20 Rule for Admin UIs
Resist the urge to make every screen equally polished. Identify the three flows that account for 80% of operator time and pour 90% of your design budget into them. The rarely-used screens can be functional and ugly; nobody cares.
For a marketplace this is usually order management, dispute handling, and merchant onboarding. For a vertical SaaS it's usually the bulk-import flow and the daily reconciliation screen. For an internal CRM it's the lead inbox and the deal pipeline.
The Anti-Pattern List
A few things we refuse to ship in admin tools, regardless of how much the stakeholder asks:
- Modal forms for anything with more than five fields—use a dedicated edit route
- Confirmation dialogs on destructive actions without a typed confirmation token
- Pagination as the only navigation option for long lists; always offer virtual scroll
- "Smart" search that hides exact-match results behind a relevance algorithm
- Onboarding tours for daily-use tools—operators will skip them and never come back
Measure It
The simplest metric we track on every admin tool we ship is "actions per operator per day." We instrument it from week one. If the number stays flat or drops after a release, we revert. If it climbs, we ship the next iteration.
Designing for operators is a craft, not a checklist. But these patterns get us 80% of the way on every project, and the remaining 20% comes from sitting next to the people using the tool and asking what hurts.
Mark P.
🎨 Writes about design at LevelByte. Built things at startups and agencies for the last decade.
Tell us what you're building. We'll come back with a plan.
Designing Admin Dashboards That Operators Actually Like
Stop Building "Salesforce-Lite"
The default admin dashboard is a forest of nav rails, a generic data table, and a modal-heavy edit flow. It looks competent in screenshots. Then you watch a real operator try to process 40 refunds in a morning and realize the UI is fighting them on every click.
Operators are not infrequent power users. They live inside the tool for six hours a day. Every wasted click compounds into hours of friction per week. Designing for them is a different discipline from designing a marketing site or even a customer-facing SaaS UI.
Start From the Operator's Daily Flow
Before we open Figma we sit with the people who will use the tool. We watch them do their current workflow—usually a horrifying chain of spreadsheets, Slack threads, and one stagnant Notion page. We write down every action they take, in order, with timestamps.
That ordered list is the spec. The dashboard is not a CRUD app over the schema. It is a tool that turns "I need to process today's refunds and flag the suspicious ones" into the smallest possible number of keystrokes.
Tables Are the Product
In a customer-facing app, the table is a fallback. In an admin app, the table is the product. Get it right and the rest follows. Get it wrong and no amount of beautiful detail pages will save you.
Things we always include in our admin tables:
- Sticky header and first column so operators can scroll horizontally without losing context
- Inline editing for the two or three fields that change most often—status, owner, notes
- Column visibility controls that persist per user, not per session
- A density toggle because some operators want eight rows visible and some want forty
- Saved filters that show up as one-click chips at the top of the table
The fanciest detail-pane animation in the world is worth less than a table that lets a senior support agent triage 200 tickets without lifting their hands off the keyboard.
Bulk Actions and Keyboard Shortcuts
Single-row actions are for end users. Operators work in batches. Every admin table we ship has:
- Multi-row selection with shift-click for ranges
- A bulk action bar that animates in when anything is selected
- Keyboard shortcuts for the top three actions on every screen
- A discoverable shortcut overlay triggered by `?` or `cmd+k`
We tell our clients to expect about a 4x throughput improvement once their operators learn the shortcuts. We have never been wrong about that number.
The 80/20 Rule for Admin UIs
Resist the urge to make every screen equally polished. Identify the three flows that account for 80% of operator time and pour 90% of your design budget into them. The rarely-used screens can be functional and ugly; nobody cares.
For a marketplace this is usually order management, dispute handling, and merchant onboarding. For a vertical SaaS it's usually the bulk-import flow and the daily reconciliation screen. For an internal CRM it's the lead inbox and the deal pipeline.
The Anti-Pattern List
A few things we refuse to ship in admin tools, regardless of how much the stakeholder asks:
- Modal forms for anything with more than five fields—use a dedicated edit route
- Confirmation dialogs on destructive actions without a typed confirmation token
- Pagination as the only navigation option for long lists; always offer virtual scroll
- "Smart" search that hides exact-match results behind a relevance algorithm
- Onboarding tours for daily-use tools—operators will skip them and never come back
Measure It
The simplest metric we track on every admin tool we ship is "actions per operator per day." We instrument it from week one. If the number stays flat or drops after a release, we revert. If it climbs, we ship the next iteration.
Designing for operators is a craft, not a checklist. But these patterns get us 80% of the way on every project, and the remaining 20% comes from sitting next to the people using the tool and asking what hurts.
Mark P.
🎨 Writes about design at LevelByte. Built things at startups and agencies for the last decade.
Designing Admin Dashboards That Operators Actually Like
Stop Building "Salesforce-Lite"
The default admin dashboard is a forest of nav rails, a generic data table, and a modal-heavy edit flow. It looks competent in screenshots. Then you watch a real operator try to process 40 refunds in a morning and realize the UI is fighting them on every click.
Operators are not infrequent power users. They live inside the tool for six hours a day. Every wasted click compounds into hours of friction per week. Designing for them is a different discipline from designing a marketing site or even a customer-facing SaaS UI.
Start From the Operator's Daily Flow
Before we open Figma we sit with the people who will use the tool. We watch them do their current workflow—usually a horrifying chain of spreadsheets, Slack threads, and one stagnant Notion page. We write down every action they take, in order, with timestamps.
That ordered list is the spec. The dashboard is not a CRUD app over the schema. It is a tool that turns "I need to process today's refunds and flag the suspicious ones" into the smallest possible number of keystrokes.
Tables Are the Product
In a customer-facing app, the table is a fallback. In an admin app, the table is the product. Get it right and the rest follows. Get it wrong and no amount of beautiful detail pages will save you.
Things we always include in our admin tables:
- Sticky header and first column so operators can scroll horizontally without losing context
- Inline editing for the two or three fields that change most often—status, owner, notes
- Column visibility controls that persist per user, not per session
- A density toggle because some operators want eight rows visible and some want forty
- Saved filters that show up as one-click chips at the top of the table
The fanciest detail-pane animation in the world is worth less than a table that lets a senior support agent triage 200 tickets without lifting their hands off the keyboard.
Bulk Actions and Keyboard Shortcuts
Single-row actions are for end users. Operators work in batches. Every admin table we ship has:
- Multi-row selection with shift-click for ranges
- A bulk action bar that animates in when anything is selected
- Keyboard shortcuts for the top three actions on every screen
- A discoverable shortcut overlay triggered by `?` or `cmd+k`
We tell our clients to expect about a 4x throughput improvement once their operators learn the shortcuts. We have never been wrong about that number.
The 80/20 Rule for Admin UIs
Resist the urge to make every screen equally polished. Identify the three flows that account for 80% of operator time and pour 90% of your design budget into them. The rarely-used screens can be functional and ugly; nobody cares.
For a marketplace this is usually order management, dispute handling, and merchant onboarding. For a vertical SaaS it's usually the bulk-import flow and the daily reconciliation screen. For an internal CRM it's the lead inbox and the deal pipeline.
The Anti-Pattern List
A few things we refuse to ship in admin tools, regardless of how much the stakeholder asks:
- Modal forms for anything with more than five fields—use a dedicated edit route
- Confirmation dialogs on destructive actions without a typed confirmation token
- Pagination as the only navigation option for long lists; always offer virtual scroll
- "Smart" search that hides exact-match results behind a relevance algorithm
- Onboarding tours for daily-use tools—operators will skip them and never come back
Measure It
The simplest metric we track on every admin tool we ship is "actions per operator per day." We instrument it from week one. If the number stays flat or drops after a release, we revert. If it climbs, we ship the next iteration.
Designing for operators is a craft, not a checklist. But these patterns get us 80% of the way on every project, and the remaining 20% comes from sitting next to the people using the tool and asking what hurts.
Mark P.
🎨 Writes about design at LevelByte. Built things at startups and agencies for the last decade.
Tell us what you're building. We'll come back with a plan.
Designing Admin Dashboards That Operators Actually Like
Stop Building "Salesforce-Lite"
The default admin dashboard is a forest of nav rails, a generic data table, and a modal-heavy edit flow. It looks competent in screenshots. Then you watch a real operator try to process 40 refunds in a morning and realize the UI is fighting them on every click.
Operators are not infrequent power users. They live inside the tool for six hours a day. Every wasted click compounds into hours of friction per week. Designing for them is a different discipline from designing a marketing site or even a customer-facing SaaS UI.
Start From the Operator's Daily Flow
Before we open Figma we sit with the people who will use the tool. We watch them do their current workflow—usually a horrifying chain of spreadsheets, Slack threads, and one stagnant Notion page. We write down every action they take, in order, with timestamps.
That ordered list is the spec. The dashboard is not a CRUD app over the schema. It is a tool that turns "I need to process today's refunds and flag the suspicious ones" into the smallest possible number of keystrokes.
Tables Are the Product
In a customer-facing app, the table is a fallback. In an admin app, the table is the product. Get it right and the rest follows. Get it wrong and no amount of beautiful detail pages will save you.
Things we always include in our admin tables:
- Sticky header and first column so operators can scroll horizontally without losing context
- Inline editing for the two or three fields that change most often—status, owner, notes
- Column visibility controls that persist per user, not per session
- A density toggle because some operators want eight rows visible and some want forty
- Saved filters that show up as one-click chips at the top of the table
The fanciest detail-pane animation in the world is worth less than a table that lets a senior support agent triage 200 tickets without lifting their hands off the keyboard.
Bulk Actions and Keyboard Shortcuts
Single-row actions are for end users. Operators work in batches. Every admin table we ship has:
- Multi-row selection with shift-click for ranges
- A bulk action bar that animates in when anything is selected
- Keyboard shortcuts for the top three actions on every screen
- A discoverable shortcut overlay triggered by `?` or `cmd+k`
We tell our clients to expect about a 4x throughput improvement once their operators learn the shortcuts. We have never been wrong about that number.
The 80/20 Rule for Admin UIs
Resist the urge to make every screen equally polished. Identify the three flows that account for 80% of operator time and pour 90% of your design budget into them. The rarely-used screens can be functional and ugly; nobody cares.
For a marketplace this is usually order management, dispute handling, and merchant onboarding. For a vertical SaaS it's usually the bulk-import flow and the daily reconciliation screen. For an internal CRM it's the lead inbox and the deal pipeline.
The Anti-Pattern List
A few things we refuse to ship in admin tools, regardless of how much the stakeholder asks:
- Modal forms for anything with more than five fields—use a dedicated edit route
- Confirmation dialogs on destructive actions without a typed confirmation token
- Pagination as the only navigation option for long lists; always offer virtual scroll
- "Smart" search that hides exact-match results behind a relevance algorithm
- Onboarding tours for daily-use tools—operators will skip them and never come back
Measure It
The simplest metric we track on every admin tool we ship is "actions per operator per day." We instrument it from week one. If the number stays flat or drops after a release, we revert. If it climbs, we ship the next iteration.
Designing for operators is a craft, not a checklist. But these patterns get us 80% of the way on every project, and the remaining 20% comes from sitting next to the people using the tool and asking what hurts.
Mark P.
🎨 Writes about design at LevelByte. Built things at startups and agencies for the last decade.
Tell us what you're building. We'll come back with a plan.
