The most important feature for Wikipedia's editors was effectively invisible to all of them
Role: Design Lead
Scope: End-to-end, Solo
Stack: Figma · Framer
Surfaces: Brand · Marketing site · Product
Category: AI Voice SaaS · Enterprise
01 - The brief
Wikipedia's editors are its most valuable contributors. They had no idea how to search.
Directed to campaigns & automations
Agency replacement
Wikipedia runs on a volunteer editing community. Experienced editors — people who have made dozens or hundreds of article edits, who log in to their accounts, who know the platform well — are the backbone of what makes the encyclopedia reliable. They're not casual readers. They're power users.
The Wikimedia Foundation came to us with a focused question: how are experienced editors actually using the search page? Not the search bar on the homepage — the dedicated search page, with its advanced filters and full-text search capabilities. The tool built specifically for the complex, nuanced queries that editors need.
The client had a few going-in assumptions based on their own prior research:
1
Experienced editors mostly search and edit on desktop
2
Editors use the search page
(not just the search bar)
for fine-tuned searches
3
Editors use search to find articles they want to edit — but how exactly is unknown
4
Editors tend to have more complex queries than readers
Four weeks. Seven participants. Moderated remote usability testing over Zoom. Our job was to find out whether those assumptions held up — and what was actually happening when editors tried to use the tool.
02 - The approach
We designed tasks around what editors actually do, not what the interface assumes they do
The Wikimedia Foundation gave us four research focus areas: Reading, Editing, Learning, and Communication. These weren't arbitrary — they map to the real things an editor does in a session. We built seven tasks around them.
Discovery
Find the Wikipedia search page from the homepage.
(We added this task because accessing the search page turned out not to be straightforward. That turned out to be the most important task in the study.)
Reading
Find an article about a dog breed to help you decide if it's a good fit.
Editing
You're writing an article about beagles. Use search to find a movie featuring one for a "Pop Culture" section.
Editing
You want to write about canine lifespans. Use search to gauge how much coverage already exists.
Learning
Find resources on how to add an image to a Wikipedia article.
Communication
Find an experienced editor working in a related topic area and reach out to them about collaborating.
We recruited through email lists, Reddit, Discord, and Wikipedia's own community forums. 56 people responded to the screener. 7 were selected based on editing experience and active account usage. Each session ran 45–60 minutes via Zoom, with one researcher moderating and one taking notes, while participants thought aloud throughout.
03 - Findings
What we assumed vs. what we found
The client's assumptions were reasonable. Most of them were wrong in ways that mattered.
Editors were assumed to be using the search page over the search bar. In reality, they didn't know the search page existed. Editors were assumed to have complex, nuanced queries. They did — but the interface couldn't handle them, so they fell back to Google. The most revealing finding wasn't any single usability problem. It was that a feature Wikipedia's editors genuinely needed was sitting unused, because nobody could find it.
Four findings. Four recommendations.
1
The most used feature on Wikipedia was effectively invisible
"I can't remember where it was."
Every single participant in our study needed help reaching the search page. Not most — all seven. One participant assumed it was login-gated and tried to sign into their account to access it. Another had used it before but couldn't recall where it was. The most common path to the advanced search page — submitting an empty search query from the homepage — was completely unknown to everyone we tested.
The homepage search bar gives no indication that a more powerful search tool exists anywhere on the site. There's no link, no button, no affordance. The only path to it is an empty search, which is something no one does intentionally.
Recommendation:
Add a dedicated "Advanced Search" button near the default homepage search bar — prominently placed, always visible, no login required.
2
The advanced search features existed. Nobody used them.
"I didn't know I could filter anything."
Here's the twist: the Wikipedia search page has capable advanced search tools. Keyword filters, namespace search, date ranges. Everything a careful editor needs to do complex research. Fewer than half our participants used any of them — and those who did, used them inconsistently.
The reason wasn't inability. It was visibility. The advanced filters are collapsed by default behind a dropdown. On a page called "advanced search," the advanced features are hidden. Editors landing on the search page saw a search bar, treated it like Google, and missed everything else. When we told participants the filters existed, they were interested — they just couldn't find them without prompting.
This was the finding that most clearly contradicted the client's starting assumption. Editors weren't using the search page for fine-tuned searches. They were using it the same way they used the homepage bar — because nothing in the interface signaled there was another way.
Recommendation:
Expand advanced filters by default. Rearrange the search page layout to surface filter options without requiring a dropdown interaction. Add clearer instructional copy that tells editors what each filter actually does.
3
Editors searched the way they think, and the system couldn't follow
"I just typed what I'd type into Google."
About half our participants entered natural language queries into the search bar — full sentences or questions, structured the way a person actually thinks about information. "How do I cite a source in Wikipedia?" or "articles about beagles in pop culture." These are reasonable searches. Wikipedia returned error messages or completely irrelevant results.
Participants weren't surprised they'd have to learn a new search syntax. They were disappointed that they had to. Several mentioned Google explicitly — not as a feature request, but as a baseline expectation that Wikipedia simply wasn't meeting. For a platform built around making information accessible, having a search system that rejects the way people naturally express information needs is a meaningful gap.
Recommendation:
Incorporate a search algorithm capable of parsing natural language queries — returning relevant articles alongside targeted results, the way modern search has trained users to expect.
4
Once a search ran, editors were stuck with the results
"I have to start over every time I want to change anything."
Participants wanted to refine results after running a search — filter by date, narrow to a content type, restrict to a namespace. The current search results page offers none of that. To adjust a search, users have to scroll back to the top of the page, open the advanced search panel, change the parameters, and re-run the search from scratch. Every refinement resets everything.
This matters more for editors than for casual readers. An editor doing research is iterating — narrowing down a large results set, comparing sources, cross-referencing content types. The current flow treats each search as a discrete action. Editors need it to be a continuous process.
Recommendation:
Introduce a persistent faceted search panel alongside results — enabling filtering by year, content type, category, and namespace without requiring a new search. Keep the active search parameters visible so editors know what they're currently searching within.
04 - Outcome
The client agreed with every finding. And asked to keep working together.
Across enterprise and SME
voice campaigns
The Wikimedia Foundation reviewed the full report and confirmed alignment with all four identified problems. They were receptive to the recommendations and expressed openness to continued collaboration beyond the study.
That outcome matters for what it signals: the findings were grounded enough to hold up to client scrutiny. Usability research is only as useful as the confidence it gives stakeholders to act on it. The WMF's response suggested the study did that.
View Research Report →
View Client Presentation →
Designing a research protocol from a real client brief
Recruiting participants from outside channels (Reddit, Discord, Wikipedia forums)
Running moderated remote usability sessions with think-aloud protocol
Synthesizing behavioral observations into structured findings
Establishing CTA hierarchy and visual language across a complex modal-heavy product
Translating findings into annotated redesign recommendations
Presenting research conclusions to an external client stakeholder
Identifying the gap between what users say they need and what they actually use
Reflections
The most interesting finding was the gap between what users said they needed and what they actually used
The editors we tested consistently described a need for better search filtering — more precise results, more ways to narrow down what they were looking for. They said this in post-test questioning. They said it emphatically.
They also consistently failed to use the filtering tools that already existed on the page.
That gap is the real design problem, and it's a more nuanced one than "the feature is broken." The feature works. It's just invisible — collapsed behind a dropdown, labeled in a way that doesn't connect to how editors think about the task. The fix isn't a new algorithm or a rebuilt UI. It's making what's already there legible.
That applies well beyond Wikipedia search. When users report needing something and simultaneously fail to use the version of it that exists, the question isn't whether to build it — it's whether the current version actually registers as what they're asking for.
What I'd do differently: With more time, we'd have recruited a broader pool of editors and run a second round of testing on the redesigned mockups — moving from problem identification to validated solutions rather than recommended ones. The client's openness to continued collaboration made that a real possibility; the timeline didn't allow for it.
Skills applied: Moderated usability research · Think-aloud protocol · Participant recruitment and screener design · Research synthesis and report writing · Findings presentation to external client · Figma wireframing for annotated redesign mockups
Project contentSagar's PortfolioCreated by yousynthesys-case-study-final.md358 linesmdcs2-wikipedia-search.md159 linesmdcs1-tbh-design-system.md246 linesmdContent