One of the first panels I delivered was technically flawless. Every field was manageable, every setting was exposed, everything was flexible. Six months later I called the client and found out nobody was using it — they were emailing me their content changes instead.
What I learned that day: a panel's success isn't measured by what it can do, it's measured by whether someone who doesn't know the system can use it without being afraid. Here's what came out of that lesson.
1. The panel shouldn't be a mirror of your database
The most common mistake: dumping tables onto the screen as-is. The user wants to
"publish a campaign announcement"; what you're handing them is separate record entry
across posts, post_meta, and taxonomies tables.
The panel should reflect the user's job, not your data model.
Test: does a screen's name describe the task the user came there to do? Not "Record Management" — "Publish a Campaign."
2. Not every field is required
A 30-field form tells the user "I need to fill all of these out correctly" and freezes them. Split fields into two groups: what's needed to finish the task and everything else. Put the second group behind a collapsed "Advanced" section. Most users will never open it — and that's a good thing.
3. Show what will happen before they save
The number one reason people are afraid of a panel: not knowing what happens when they hit "save." A preview is the cheapest trust-building tool there is. If a user can see it before it goes live, they won't hesitate to try things — and if they don't hesitate, they'll use the panel.
4. Make it reversible
Delete shouldn't actually delete. A soft delete with a 30-day trash bin is a feature that takes half a day to build but completely changes how the panel feels. Same with content revisions — keep them, so "what did this say yesterday?" is one click away.
5. Error messages should carry the information to fix the error
"Something went wrong" is useless. Tell the user three things: what happened, why it happened, and what to do now.
Bad: "Upload failed."
Good: "Image is 8 MB — the limit is 2 MB. Compress it and try again."
6. Turn the empty screen into an opportunity
The first time a user sees the panel, every list is empty. Most panels show a blank table here. But this is actually the best place to teach the user what to do next: "No campaigns yet. Create your first one →" with a single, obvious button.
7. Set permissions around tasks, not job titles
Abstract roles like "editor," "author," "contributor" rarely map cleanly onto real organizations. Start with concrete questions instead: who can change price? Who can publish? Who can delete? Let the roles fall out of those answers.
Also, a user shouldn't see something they don't have permission for — a grayed-out, unclickable button just constantly reminds someone of what they can't do.
8. The panel has a performance budget too
A visitor waits 3 seconds on the site; someone using the panel for work waits on it a hundred times a day. A slow panel taxes that person's entire workday directly. Paginate list views, don't pull every record at once, and index your search fields. The N+1 query problem from the performance post applies here just as much.
The real test
Once the panel is done, do this: sit down someone who's never seen it, doesn't know the project, and give them a single task — "publish that announcement." Don't help, don't explain, just watch.
If they finish in five minutes without asking you anything, the panel is ready. Every place they hesitate is something you need to fix. I ran this exact test on the WebWizz panel and reworked three screens after the first run — those three fixes are why that panel is still in daily use today.