openedx / openedx/openedx-core
[NTH - UXD] Define workflow for Taxonomies dropdown in Studio design
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 10
- Forks
- 32
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 12
Description
Use Case
As a Platform Administrator, I need a clear and intuitive way to navigate to and manage Competency Taxonomies and tag taxonomies from the Studio home page so that I can quickly access the taxonomies I care about without confusion about what each option does.
Description
The UX Designer has proposed a dropdown on the Taxonomies tab of the Studio home page with two options: "Competency" and "Tags". In the current design, clicking either option launches the taxonomy import wizard with the corresponding Taxonomy Type pre-selected.
Two concerns have been raised with this design:
-
Labeling: Nothing in the current design indicates that clicking an option starts an import/creation flow. A user clicking "Competency" will likely expect to see their competency taxonomies — not be taken into an import wizard. This is a significant discoverability risk.
-
Use case frequency: Platform Administrators will far more often want to view and manage existing taxonomies than to create new ones from the home page. The import wizard is already accessible via the Import button on the Taxonomies page itself.
Three directions are on the table for the designer to evaluate:
Option A — Navigation only: Dropdown options navigate to the Taxonomies page pre-filtered by type ("Competency Taxonomies", "Tag Taxonomies"). Import stays on the Taxonomies page as it currently is. Note: this requires filter/tab functionality on the Taxonomies page, which would expand the scope of ticket 7.
Option B — Navigation + creation: Four options — "View Competency Taxonomies", "View Tag Taxonomies", "Add Competency Taxonomy", "Add Tag Taxonomy". Covers both the management and creation use cases, at the cost of a more complex dropdown.
Option C — Label fix only: Retain the current import-only behavior but update the labels to make the action unambiguous — for example, "Add Competency Taxonomy" and "Add Tag Taxonomy", or prefix each with "+". Lowest-effort change; does not address the frequency-of-use concern.
The designer should evaluate these options (and any alternatives) and produce a revised design. The chosen direction feeds directly into ticket 7.
Acceptance Criteria
This is a design spike. The deliverable is design artifacts and documented decisions, not working code. There is no Gherkin and no QA path.
- The three options above (and any designer alternatives) have been reviewed with the team and a direction has been chosen with documented rationale
- The revised design clearly communicates to the user what action each dropdown option performs before they click it
- Figma or design file is updated to reflect the agreed-upon approach
- If Option A or B is chosen, the design specifies how filtering behaves on the Taxonomies page and notes are added to ticket 7 to expand its scope accordingly
- Notes for ticket 7 are written capturing the agreed workflow, interaction details, and any new filtering or navigation requirements the implementation will need
Context for the Designer
Current import workflow (from ticket 4 — what the existing design routes users into):
- Click Import on the Taxonomies page
- Upload a JSON or CSV file
- Click Continue
- Fill in Taxonomy Name, Taxonomy Description, and Taxonomy Type (dropdown: Tags default, Competency option)
- Click Import
Taxonomy types available to users: "Competency" and "Tags" only. System-level taxonomies exist but cannot be user-created and should not appear as dropdown options.
Filtering capability: The Taxonomies page does not currently have filter or tab functionality. If Option A or B is chosen, this will need to be built as part of ticket 7 — budget accordingly.
Related tickets:
- Ticket 4: Import flow with Taxonomy Type dropdown (the flow the current design leads into)
- Ticket 5: Taxonomy type badge on taxonomy cards (the visual that makes filtering meaningful)
- Ticket 7: Implementation of whichever design this ticket produces
- [Link to current Figma design]
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the current Figma design and review tickets 4, 5, and 7 alongside the three proposed dropdown options. Discuss the alternatives with the team and document the chosen workflow and rationale. Done means the revised design is updated, actions are unambiguous, and ticket 7 contains the agreed interaction, filtering, and navigation notes.
Written by the indexing model from the issue text.
Assessment
- Domain
- design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100