Categories
Tags
Archives
Structuring a Research Site So People Stop Getting Lost
-
A Lab Website Rebuild That Didn’t Collapse Under Updates
The first signal that our lab website needed work wasn’t a complaint about how it looked. It was an email from a prospective collaborator that ended with a simple line: “I couldn’t find your latest publications list—do you have a more recent link?”
We did have a publications list. We also had a “News” page, a “Projects” page, several scattered PDF links, and a few half-updated profile sections that were once accurate but had drifted over time. The collaborator wasn’t being picky. They were reacting to what every visitor reacts to on academic and research sites: information reliability. A lab website is not judged by its hero image. It’s judged by whether the details feel current, consistent, and easy to verify.
I maintain the site, and I’m also the person who gets the internal messages like “Can you add this grant?” or “Can you update the lab member list?” or “Can you post the new preprint?” These requests don’t arrive in a neat batch. They arrive continuously, and often at inconvenient times—right before a submission, right before a conference, right after a funding announcement.
Over the years I’ve learned something uncomfortable: a research website doesn’t fail because it lacks content. It fails because its structure makes updates stressful. Stress creates avoidance. Avoidance creates outdated pages. Outdated pages create mistrust. And mistrust is expensive—especially when your site is often the first point of contact for a student, a collaborator, or a journalist.
That’s the context in which I rebuilt our site using Xleb – Laboratory Science Research WordPress Theme. This isn’t a feature rundown. It’s a log of decisions: how I rethought information flow, how I tried to prevent drift, what I corrected about my own habits, and what changed after the new structure had been live long enough to show real usage patterns.
I’m writing it for other admins and maintainers—people who care about stability, clarity, and the quiet work of keeping a research site trustworthy.
The actual problem: drift, not design
If you’ve maintained a lab website for more than a year, you’ve seen drift:
-
A project description that was “current” two years ago but now reads like an abandoned idea.
-
A publication list that stopped updating because it required too many manual edits.
-
A “Lab Members” page that still lists someone who graduated.
-
A “News” feed that becomes a scrapbook of random updates, with no structure.
-
A navigation menu that grows every time someone asks for a new page.
Drift is not a moral failure. It’s a structural one. When updating is hard, people delay it. When people delay updates, accuracy decays.
So I set the goal as: reduce the cost of being accurate. Not “make the site prettier.” Not “make the site more persuasive.” Just reduce the cost of keeping information correct.
That goal shaped everything else.
I started with visitor questions, not a sitemap
The temptation is to start with pages: Home, About, Research, Publications, People, Contact. That’s fine as a skeleton, but visitors don’t arrive thinking “I want the Publications page.” They arrive thinking:
-
“What does this lab actually work on?”
-
“Is this research active right now?”
-
“Can I quickly scan outputs?”
-
“Who would I email about collaboration?”
-
“If I’m a prospective student, what do I do next?”
-
“If I’m a peer reviewer or journalist, can I verify details?”
So I wrote down the most common visitor intents and mapped each to a short, predictable path. I kept it simple—no elaborate persona diagrams. Just honest use cases.
Intent A: Prospective student
They want a quick understanding of themes, active projects, and where they might fit.
Intent B: Collaborator
They want scope, evidence of recent work, and the right contact person.
Intent C: Conference / talk audience
They want a fast recap and a way to follow up after a talk.
Intent D: Admin (me)
I want to update publications, people, and news without fear.
Once I framed it this way, the content design stopped being abstract. It became an interface problem: how do I make those intents easy?
Decision 1: define “anchor pages” that never change
A research site can’t behave like a blog where everything is chronological. People need stable places to return to. I call them anchor pages:
-
Research areas (stable themes)
-
Projects (current work, with update patterns)
-
Publications (clean and current)
-
People (accurate and structured)
-
Contact / collaboration (clear routes)
These anchors are different from “news.” News moves. Anchors must stay stable.
The rebuild succeeded mainly because I treated these anchors as infrastructure. Their structure is consistent across time. Their placement in navigation is consistent. Their layout patterns are consistent.
Consistency isn’t about aesthetics. It’s about trust.
Decision 2: the homepage is a front desk, not an abstract mission statement
Old lab websites love mission statements. I understand why: researchers want to describe purpose and values. But mission statements rarely help a visitor decide what to do next.
So I made the homepage do only a few things:
-
Give a plain-language summary of the lab’s focus
-
Offer two or three clear routes: Research, Publications, People
-
Show a small signal of recency (not a wall of updates)
-
Provide an obvious “how to reach us” path
I avoided long paragraphs. Not because “short copy converts,” but because visitors are scanning under time constraints—especially on mobile. Many visitors arrive after hearing a talk, during a commute, or between meetings.
A front desk doesn’t give you a lecture. It points you where you need to go.
Decision 3: I separated “themes” from “projects” to reduce confusion
On many lab sites, research themes and projects are blended into one page. That creates confusion because themes are stable, projects are transient. When the two are mixed, your site constantly feels outdated unless you update everything frequently.
So I separated them:
-
Research themes: stable, high-level, slow-changing
-
Projects: current, time-bounded, updated as they evolve
This separation also helps maintenance. When a project ends, you don’t need to rewrite your theme overview. You only update the project section. The stable narrative remains intact.
Visitors also understand it intuitively. Themes tell them “what we care about.” Projects tell them “what we are actively doing.”
That distinction is subtle, but it reduces ambiguity.
The publications problem: reliability is more important than completeness
The collaborator email about publications made me confront an uncomfortable truth: an incomplete but current list is better than a complete but stale list.
If your publications page looks neglected, it signals neglect elsewhere—even if your lab is thriving. That’s unfair, but it’s how humans interpret signals.
So I rebuilt the publications workflow around one principle: it must be easy to update. If updating is tedious, it won’t happen.
I did not try to create the “perfect” system. I created a maintainable one:
-
A consistent format
-
Clear grouping logic (recent vs older, or by year)
-
Minimal manual formatting
-
A habit of updating on a predictable cadence
The goal was not to impress someone with a fancy layout. The goal was to remove friction from the act of keeping it current.
A misconception I corrected: “more pages means more clarity”
It’s natural in labs to add pages whenever someone requests something:
-
“Add a page for this grant.”
-
“Add a page for this collaboration.”
-
“Add a page for this dataset.”
-
“Add a page for this outreach activity.”
Over time, the navigation becomes a dumping ground.
I corrected this by adopting a rule: new information must fit into existing structure first. Only when it truly can’t fit do we create a new page.
This discipline does two things:
-
It reduces navigation sprawl.
-
It forces you to clarify what each anchor page is responsible for.
A lab site is not a CV. It’s an interface for outsiders. Too many pages makes the interface harder to learn.
Page flow: I designed for “scanability under stress”
Visitors rarely read a lab site like a book. They scan. They jump. They return later. They open multiple tabs. They’re often on a phone.
So I designed page flow to support scanning:
-
Clear headings with consistent meaning
-
Short, factual blocks rather than long narrative walls
-
Predictable placement of key information (what, why, how, status)
-
Reduced decorative complexity that interferes with reading
This is where a research-focused theme helps: it naturally supports information density without turning the page into a visual circus.
But again, the theme isn’t the reason the site improved. The theme just made it easier for me to keep structure consistent.
Admin perspective: how the rebuild reduced my maintenance load
This is the part that matters most to me. After the rebuild, three things changed.
1) Updates stopped feeling dangerous
On the old site, small edits could break layout coherence. A new lab member bio would push sections out of place. A new publication would disrupt formatting. That makes you hesitant.
On the new structure, pages behaved predictably. Predictability is what allows you to update weekly without dread.
2) I could delegate small edits
Once the structure was stable, I could let someone else update a short bio or add an item without worrying they’d destroy the whole page. That’s not because they became better editors—it’s because the structure constrained how edits could go wrong.
3) The site stopped accumulating patches
Old sites accumulate patches: banners, extra blocks, side widgets, announcements. The rebuild made patching less necessary because information had a proper home.
Patches are not always bad, but they create debt. Debt is what makes sites age poorly.
User behavior I observed after launch
After the new site had been live for a while, I watched for signals that mattered. I didn’t need deep analytics. I needed a few behavioral signs:
Students asked better questions
Instead of “what does your lab do?” I got “I saw your work on X—are you taking students in that direction?” That’s a higher quality conversation, and it saves everyone time.
Collaborators reached out with context
Emails included references to specific project areas and recent publications. That told me the site was serving its orientation role.
Fewer “where do I find…” messages
This is the most practical KPI for a lab site. When people stop asking where things are, the site is doing its job.
A gentle technical layer: stability over cleverness
I’m cautious about making lab sites “too clever.” Complex interactions often break on mobile, behave inconsistently across browsers, or create accessibility issues.
So my technical posture was conservative:
-
Keep pages lightweight and readable
-
Avoid over-animated sections
-
Maintain consistent typography and spacing
-
Ensure the site remains usable with imperfect connections
Mobile experience is especially important for research sites now. People open lab pages during talks, on conference Wi-Fi, in transit. A heavy site feels “slow” even if it’s technically fine.
I chose simplicity, because simplicity survives.
A note about decision-making: I rebuilt in the order that prevented rework
I didn’t redesign everything at once. I staged the rebuild:
-
Define anchors and navigation
-
Build the homepage front desk
-
Build Research themes and Projects structure
-
Build People pages with consistent formatting
-
Build Publications with an update-friendly workflow
-
Add News only after anchors were stable
This order mattered because if you start with News, you end up designing around a stream rather than around stable information. And a lab site needs stability first.
Why “News” should be minimal and disciplined
Lab news tends to be uneven. Sometimes there’s a burst: papers, grants, conferences. Sometimes it’s quiet. A “News” page that goes silent looks like abandonment, even if the lab is simply in a quieter phase.
So I kept News minimal:
-
Fewer posts, but clearer and more meaningful
-
A consistent format (date + factual update)
-
No long essays unless necessary
This approach reduces the risk of the site looking stale. The anchors still communicate current work; News becomes an optional layer rather than the site’s heartbeat.
Correcting common admin mistakes (I made most of them)
Here are the mistakes I’ve made—and now actively prevent:
Mistake: rewriting the whole site every time the lab focus shifts slightly
Instead, keep themes stable and update projects. Let the site reflect evolution without constant rebranding.
Mistake: mixing “about the lab” with “how to collaborate”
About pages often become biographies. Collaboration pages should be practical: who to contact, what information helps, what kinds of requests make sense.
Mistake: letting the People page become a photo grid without information
Photos are fine, but visitors often need roles, research interests, and contact routes. The page should be a directory, not a gallery.
Mistake: letting the Publications page become a wall of text
Visitors scan. Structure matters.
Maintaining a catalog mindset without turning the lab into a storefront
This might sound unrelated, but I’ve found that maintaining any structured website benefits from looking at well-organized catalogs. A good catalog teaches you discipline: consistent layout, predictable navigation, and restraint.
Sometimes I browse collections like WooCommerce Themes not because I’m shopping, but because it reminds me what “clean information browsing” feels like from the user side. That mindset translates well to lab sites: projects are “items,” people are “items,” publications are “items.” If your items don’t behave consistently, the site feels chaotic.
Again: not marketing, just structure.
What I would do differently next time
The rebuild worked, but I would adjust two things if I did it again:
1) I would decide the publication update workflow on day one
I spent too long thinking about layout before deciding how we would maintain the publications page. Maintenance should be decided first.
2) I would create a clear “prospective students” route earlier
Students are a core audience. They need an obvious route that respects their questions without overwhelming them.
Closing: the best lab site is the one you can keep accurate
When people judge lab websites, they don’t say it directly, but they’re looking for a feeling: “this is maintained by people who care about details.” That feeling comes from consistency, clear structure, and current information—not from big adjectives or design tricks.
The rebuild didn’t make the lab “more impressive.” It made the site easier to maintain, which made it more accurate, which made it more trustworthy. Trust is the asset.
If you’re maintaining a research site, my main advice is not “pick a theme.” It’s: build a structure that makes accuracy cheap. Once accuracy is cheap, consistency becomes a habit instead of a struggle.
And once consistency becomes a habit, the site stops being a burden—and quietly becomes what it should have been all along: a reliable interface between your work and the people trying to understand it.
-