The Conference Room vs. The Trenches
There's a specific kind of frustration that comes from using software designed by people who've never done your job. You can feel it in every click, every workflow, every inexplicable design decision.
Support software is especially prone to this. It's usually built by developers who talk to product managers who talk to executives who maybe talked to a support agent once, three years ago, at a company offsite.
Like a game of telephone, but instead of garbled messages, you get garbled software.
Here's how to tell if your support platform was designed in a conference room instead of the trenches.
Sign #1: The Dashboard Is the Homepage
What It Looks Like:
You log in and see: graphs. Charts. Numbers. A beautiful dashboard showing metrics from the last 30 days. It looks impressive in demos.
Why It's a Problem:
When does a support agent need to see monthly trends? Approximately never. What they need is their queue. Their tickets. The work right in front of them.
Dashboards-as-homepage is a sign that the primary user was imagined to be a manager, not an agent. The person who actually lives in the tool all day got deprioritized.
It's like designing a spaceship cockpit for the flight controller on the ground instead of the pilot in the seat. Sure, the controller needs information too—but maybe put the steering wheel where the pilot can reach it.
What Good Design Looks Like:
Open the app, see your tickets. Everything else is secondary. If you want to check metrics, they're there—but they're not blocking you from doing your actual job.
Sign #2: "Simple" Actions Take 3+ Clicks
What It Looks Like:
To assign a ticket to yourself: Click dropdown → Select "Assign" → Select your name → Confirm. Four clicks for something you do dozens of times daily.
Why It's a Problem:
Every unnecessary click multiplies across hundreds of tickets. What feels like a minor inconvenience becomes hours of wasted time over weeks and months.
If you do 42 tickets a day (the answer to life, the universe, and everything), those extra clicks add up to roughly "too many" clicks per year. That's a scientific measurement.
This happens when designers don't observe actual usage. They design for conceptual completeness—every option neatly organized—rather than for practical speed.
What Good Design Looks Like:
One-click assignment. Keyboard shortcuts for common actions. The interface should anticipate what you're trying to do and get out of your way. Speed is respect.
Sign #3: Search Doesn't Work Like You Think
What It Looks Like:
You search for a customer's email. No results. You try their name. Nothing. You try partial matches, different formats, creative spellings. Finally you give up and scroll manually.
Why It's a Problem:
Support agents search constantly. For customers, for previous tickets, for knowledge base articles. Bad search doesn't just slow you down—it breaks your entire workflow.
Bad search usually means the team optimized for "technically correct" results rather than "actually useful" results. The customer might exist, but the search algorithm is too strict, too slow, or too literal.
It's like having a librarian who only helps you if you know the exact Dewey Decimal number. Technically accurate. Practically useless.
What Good Design Looks Like:
Search that's forgiving. Partial matches. Typo tolerance. Searching across fields simultaneously. Results that load instantly, not after a loading spinner that makes you question your career choices.
Sign #4: Required Fields That Don't Matter
What It Looks Like:
Before closing a ticket, you must fill in: category, subcategory, sub-subcategory, resolution type, time spent, root cause, satisfaction prediction, and your mother's maiden name.
Okay, maybe not the last one. But close.
Why It's a Problem:
These fields exist because someone wants data. That's valid! But when data collection slows down actual work, you've got the priorities backwards.
Worse: agents learn to game it. Pick "Other" for everything. Enter "1 minute" regardless of actual time. The data becomes useless anyway. You've traded agent goodwill for garbage data. Congratulations.
What Good Design Looks Like:
Minimal required fields for closing tickets. Optional fields for deeper categorization. Smart defaults and auto-categorization where possible. Data collection should feel helpful, not punitive.
Sign #5: Canned Responses Are an Afterthought
What It Looks Like:
Creating a template requires navigating to Admin → Communications → Templates → Create New. Using a template requires remembering its exact name or scrolling through an unsearchable list.
Why It's a Problem:
Canned responses are one of the highest-leverage features in support. They save time, ensure consistency, and let agents focus on personalization rather than typing the same paragraph for the hundredth time.
When templates are hidden away, it's a sign the team doesn't understand how support actually happens. It's like hiding the Fast Travel option in a menu seven layers deep. We have places to be!
What Good Design Looks Like:
Templates integrated directly into the response composer. Searchable by keyword. Recently used floating to the top. Creating new templates from existing responses with one click.
The Common Thread
Notice what these all have in common? They're not technical failures. The software works. It just doesn't work for the people using it.
This happens when:
- User research means talking to buyers, not users
- Design decisions optimize for demos, not daily use
- Features get added for competitive checkboxes, not actual needs
- The team ships and moves on instead of observing and iterating
It's the difference between software built in a conference room versus software built in the trenches. Both might look similar on a feature list. Using them feels completely different.
Building for the Trenches
At cStar, we started with a different premise: what would software look like if it was built by support agents, for support agents?
It would prioritize the queue over the dashboard. It would make common actions fast. It would search like you think. It would collect data without creating friction. It would put templates front and center.
In other words, it would respect your time and intelligence.
That's what we're building. And if you've ever felt the frustration of software designed in a conference room, we built it for you.
Want to know more about why we built cStar? Read Why We Built cStar: A Love Letter to Support Agents. And if you're curious how we make support work actually feel rewarding, check out The Psychology of Gamification: Why XP Actually Works.
Josh spent a decade as a support agent before building cStar. He has strong opinions about search functionality, a deep abiding hatred for unnecessary dropdown menus, and believes every piece of software should be designed by someone who has to use it 8 hours a day. His office neon sign says "Don't overthink shit." Solid advice.