User:TBurmeister (WMF)/Sandbox/Developer UXR
Material may not yet be complete, information may presently be omitted, and certain parts of the content may be subject to radical, rapid alteration. More information pertaining to this may be available on the talk page.
This page provides links to developer-focused user experience research findings from various Wikimedia projects. It focuses on resources that can be useful for designing information architectures for Wikimedia technical audiences.
This page excludes personas because I find them generally useless, and because there's already a lovingly-maintained list of them.
User journeys and tasks
| Project link | Time period | Notes | Contact |
|---|---|---|---|
| Developer Portal user journeys | 2021-present | IA based on user journeys for broad Wikimedia technical audience | TBurmeister (WMF) |
| API Portal: User journeys and content structure. See also: API Portal/Retrospective | 2021-2025 | High-level IA in phab task, more specific on Wikitech page | APaskulin (WMF) |
| API Gateway user stories and personas | 2019 - 2021? | User stories very focused on functionality, not API discovery or higher-level CUJs | BPirkle (WMF) ? |
| Web APIs hub project requirements and personas; developer personas for dev.wikimedia.org | 2013-2015 | Wireframes of initial UI and sets of personas | Qgil (WMF) |
| Audiences for Wikimedia technical documentation (general) | 2021 | Includes user tasks within personas | Tech Docs team |
Quotes from project docs
This section contains relevant info that I pulled out of docs that weren't specifically related to user research findings.
MediaWiki Core REST API
The quotes below are from MediaWiki Core REST API design principles (historical):
"The API should be specific for MediaWiki. API concepts and data types should be recognizable to users from the Web and mobile interfaces; for example, pages, users, and revisions. If we generalize past MediaWiki concepts to âdigital assetsâ or âentitiesâ or âagentsâ we have gone too far, and need to bring things back down to the specific.""A foolish consistency is the hobgoblin of little minds." (Ralph Waldo Emerson) Consistency is valuable when it helps our client developers guess at how the API works. Consistency is not an end in itself. We wonât force unrelated interfaces or data structures to be identical if it makes them harder to use.
"Developers looking at our API will be looking for functionality that they see in the Wikipedia Web interface. If the basics are not there, it will seem like the API is incomplete, and they'll skip over it."
Survey and listening tour findings
2024-2025:
Interview scripts and public session notes
TODO - include etherpad from Hackathon API presentation