Repository navigation
[NTH - UXD] Define workflow for Taxonomies dropdown in Studio design #617
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]
Activity
[-]Define workflow for Taxonomies dropdown in Studio design[/-][+][UXD] Define workflow for Taxonomies dropdown in Studio design[/+]illiphilli commentedon Jun 30, 2026
Proposed direction: Option B (Navigation + creation)
After reviewing the three options, my recommendation is Option B — a single dropdown that covers both viewing/managing existing taxonomies and creating new ones:
Why B over A and C
The starting question is really whether we want a dropdown on the tab at all. It isn't strictly required, and not adding one doesn't block any other work — see Option D below. But if we are going to put a dropdown here, it should be flexible enough to serve both navigation and creation/import shortcuts rather than committing to only one. That's what rules out A and C:
Option B addresses both of the concerns raised in the ticket directly. The explicit "View…" vs "Add…" labels make each action unambiguous before the click (labeling concern), and leading with the two "View" options puts the more frequent management use case first (frequency-of-use concern), while still keeping the creation shortcut one click away.
The alternative: Option D (do nothing now, enhance later)
For completeness, there's an Option D that isn't in the ticket: change nothing on the tab for now and surface any new taxonomy features once the user is already on the Taxonomies page. The dropdown is optional and doesn't block other work, so deferring it is viable. The argument against it is that a dropdown on the tab was originally intended to help highlight the new CBE features in Taxonomies — which is likely why no "change nothing" option was written into the ticket in the first place.
So from my POV the real decision is B vs D. My lean is B, since it delivers that highlight while keeping the menu useful for everyday management.
For reference: old design recommendation
This was a rough pass earlier this year, simply illustrating the concept of a dropdown menu on the Taxonomies tab.
I'd also like to point at a 5-month old comment from @marcotuts , and liked by @sdaitzman . If their opinions still stand on this issue, that would add some weight to Option D.
@jmakowski1123 — flagging you here since this decision really hinges on your input: do you want the dropdown on the tab (Option B) to highlight the new CBE features, or are you good deferring it (Option D)?
ormsbee commentedon Jul 1, 2026
Taxonomies today are really inconsistent with the course and libraries experiences:
Is it feasible to start bringing them closer together? For instance:
jesperhodge commentedon Jul 1, 2026
@ormsbee thinking about scope on this:
jmakowski1123 commentedon Jul 1, 2026
I'll comment on each of the 4 options first, then I'll address Dave's comment. And I agree with the problem statement, that the taxonomy dropdown should not navigate to the import modal.
Option A: I think building out a filter on the Taxonomy page adds more complexity than we need at the moment, considering the majority of users only deal with a small number of taxonomies, rather than hundreds of them. Is there a simpler solution here--eg, clicking the Taxonomy tab leads to the Taxonomy page, like it does now, and then the Competency Taxonomy tiles have a pill or some sort of label distinguishing them as a Taxonomy Type: Competency ?
Option B: This feels way to complex. I am in favor of not adding any dropdowns to the Taxonomy tab, and if we need the complexity for different types of Taxonomy Types, to shift that to the import button, where you can choose a competency taxonomy or a regular taxonomy. And we don't need a separate UX journey to edit taxonomies. Users can already just click on the tiles for the taxonomy they want to work with.
Option C: As stated above, I don't think the Taxonomy tab should lead to the import modal. It should lead to the Taxonomy page.
Option D: I wouldn't advocate for nothing. I think the smallest incremental improvement would be to just add a label or pill "Competency" or "Taxonomy Type: Competency" to the taxonomy tiles on the Taxonomy Page.
Dave is right that we should be always moving toward as much uniformity as possible, especially when it comes to all the "create new" workflows that are available in Studio.
Dave's comment 1: I agree that kicking off the workflow to create a new taxonomy makes sense by adding a " + New taxonomy" to the top level header. Clicking that could lead to the workflow to create a new taxonomy/import, where we can then shift the complexity to choosing a taxonomy type, per my comment in Option B. One thing to note is that the permission to create a new taxonomy is more limited than creating courses and libraries, so not all users would see that button, depending on their role.
Dave's comment 2: Agree this is a longer term consideration, but I wouldn't change the tile view to a list view for the MVP. But we can and should add distinguishing pills or labels as I mentioned in my comment for Option A.
So to summarize:
ormsbee commentedon Jul 1, 2026
@jesperhodge: I was assuming that we'd hijack the existing "Import" modal and add one or two fields. Import is the only way to make new Taxonomies right now, but I don't think it makes sense to have a standalone Import that's separate from a "Create Taxonomy" screen.
mgwozdz-unicon commentedon Jul 1, 2026
@jmakowski1123 left a great summary, so I will respond to that:
This sounds good to me.
We are already planning to do this as #616
I'm agree that we should try to increase consistency within the platform, but I think I also agree with Jesper's point that this isn't really needed for our competency criteria functionality in general. Especially if it just goes through the current import workflow that we're already planning on modifying in #615 then I think this plan to add consistency is additional scope that could go in a backlog as something that's nice to have but not required for Willow.
What do you think?
jmakowski1123 commentedon Jul 1, 2026
Adding this to the backlog as a nice to have sounds right.
[-][UXD] Define workflow for Taxonomies dropdown in Studio design[/-][+][NTH - UXD] Define workflow for Taxonomies dropdown in Studio design[/+]