How to Remove Items from the WordPress Admin Bar

The WordPress Admin Bar, now officially called the Toolbar, provides logged-in users with shortcuts to common administration actions.

Depending on the website, it may contain items such as:

• the WordPress menu;
• site navigation;
• updates;
• comments;
• new content;
• editing shortcuts;
• profile controls;
• plugin-specific tools.

That can be useful, but the Toolbar can also become crowded as plugins add their own entries.

An Editor may need:

Edit
New Post
Comments
Media

but have no reason to see:

cache purge
plugin marketing shortcut
technical maintenance link
SEO configuration
developer utility

Fortunately, WordPress provides a proper API for removing individual Toolbar items without hiding the entire interface.

The core pattern is:

admin_bar_menu
↓
WP_Admin_Bar
↓
remove_node()

This guide explains how to remove items from the WordPress Admin Bar safely, how to identify node IDs, how priorities affect removal, how to target specific users, why CSS is usually the wrong tool for structural removal, and how to keep Toolbar cleanup separate from actual WordPress permissions.

Admin Bar and Toolbar mean the same thing

WordPress originally called the interface the Admin Bar.

Since WordPress 3.3, the official user-facing term has been:

Toolbar

However, the underlying API still contains names such as:

WP_Admin_Bar
admin_bar_menu
show_admin_bar
is_admin_bar_showing()

so both terms continue to appear in WordPress development.

The official WordPress Toolbar documentation explains the standard interface and the shortcuts it provides to logged-in users.

For a broader introduction, see What Is the WordPress Admin Bar, and Who Sees It?.

Remove individual items when the Toolbar is still useful

There are two fundamentally different situations:

Toolbar has no value
→ hide the entire Toolbar

Toolbar still useful
→ remove selected items

If an Editor benefits from the Edit and New Post shortcuts, disabling the entire Toolbar because one plugin added an unnecessary menu is excessive.

Item-level removal gives you much finer control.

WordPress represents Toolbar items as nodes

The Toolbar is managed by the:

WP_Admin_Bar

class.

The official WP_Admin_Bar class documentation describes the API WordPress uses to construct and render the Toolbar.

Toolbar entries are represented as nodes.

Each node can have properties including:

id
title
parent
href
group
meta

A node can also have child nodes

For example, the New Content menu is conceptually structured like:

New
├── Post
├── Media
├── Page
└── User

The exact children depend on the current user, registered post types and active plugins.

Use WP_Admin_Bar::remove_node()

The standard method for removing a Toolbar item is:

remove_node()

The official WP_Admin_Bar reference documents remove_node() as the method used to remove a node by its ID.

The basic syntax

$wp_admin_bar->remove_node( 'node-id' );

The important part is knowing:

node-id

for the Toolbar entry you want to remove.

Use the admin_bar_menu hook

The main WordPress hook for Toolbar customization is:

admin_bar_menu

The official admin_bar_menu documentation states that the hook can add, remove or manipulate Toolbar items.

WordPress passes the current:

WP_Admin_Bar

instance to your callback.

Basic removal example

function mysite_remove_toolbar_items( $wp_admin_bar ) {

    $wp_admin_bar->remove_node( 'comments' );
}

add_action(
    'admin_bar_menu',
    'mysite_remove_toolbar_items',
    999
);

This removes the Comments node from the Toolbar.

Why use priority 999?

Toolbar nodes are added at different stages.

If your callback runs before a node exists, calling:

remove_node()

cannot remove something that has not yet been registered.

The official admin_bar_menu documentation notes that changing existing items generally requires a sufficiently high priority.

Using:

999

is therefore common when the goal is to remove nodes added earlier.

999 is not a special WordPress requirement

It simply means:

run this callback relatively late

You could use:

100
500
999

depending on when the target node is registered.

wp_before_admin_bar_render is another option

The official admin_bar_menu reference also notes that developers can use:

wp_before_admin_bar_render

when they need to manipulate existing nodes without depending on a particular admin_bar_menu priority.

The Core wp_admin_bar_render() documentation shows the sequence:

admin_bar_menu
↓
wp_before_admin_bar_render
↓
Toolbar render
↓
wp_after_admin_bar_render

Most straightforward customizations can use admin_bar_menu

For ordinary node removal, this pattern is usually easier to read:

add_action(
    'admin_bar_menu',
    'mysite_customize_toolbar',
    999
);

Common WordPress Toolbar node IDs

WordPress Core commonly registers nodes with IDs such as:

wp-logo
site-name
updates
comments
new-content
edit
my-account

and child nodes such as:

new-post
new-media
new-page
new-user
user-info
edit-profile
logout

The current WP_Admin_Bar::add_node() documentation includes examples of common Toolbar node IDs.

Do not treat an old node list as permanent

The exact Toolbar structure depends on:

• WordPress version;
• user capabilities;
• Multisite status;
• active plugins;
• custom post types;
• the current screen.

A node listed in an old tutorial may not exist in your current configuration.

Remove the WordPress logo

The WordPress logo node normally uses:

wp-logo

You can remove it with:

function mysite_remove_wp_logo( $wp_admin_bar ) {

    $wp_admin_bar->remove_node( 'wp-logo' );
}

add_action(
    'admin_bar_menu',
    'mysite_remove_wp_logo',
    999
);

Remove the Comments item

function mysite_remove_comments_toolbar( $wp_admin_bar ) {

    $wp_admin_bar->remove_node( 'comments' );
}

add_action(
    'admin_bar_menu',
    'mysite_remove_comments_toolbar',
    999
);

Remove the Updates item

function mysite_remove_updates_toolbar( $wp_admin_bar ) {

    $wp_admin_bar->remove_node( 'updates' );
}

add_action(
    'admin_bar_menu',
    'mysite_remove_updates_toolbar',
    999
);

Remove the New Content menu

The parent node is normally:

new-content

You can remove it with:

function mysite_remove_new_content( $wp_admin_bar ) {

    $wp_admin_bar->remove_node( 'new-content' );
}

add_action(
    'admin_bar_menu',
    'mysite_remove_new_content',
    999
);

Removing the parent also removes the visible submenu

The official add_node() documentation notes that removing a top-level node removes its link and submenu from the rendered Toolbar.

This is useful when the entire group is unnecessary.

Remove only one New Content child

Sometimes you want to preserve:

New Post
New Media
New Page

but remove:

New User

Then target the child node instead:

function mysite_remove_new_user_toolbar( $wp_admin_bar ) {

    $wp_admin_bar->remove_node( 'new-user' );
}

add_action(
    'admin_bar_menu',
    'mysite_remove_new_user_toolbar',
    999
);

Remove the Edit shortcut

The current-content edit shortcut normally uses:

edit

It can be removed with:

function mysite_remove_edit_toolbar( $wp_admin_bar ) {

    $wp_admin_bar->remove_node( 'edit' );
}

add_action(
    'admin_bar_menu',
    'mysite_remove_edit_toolbar',
    999
);

Think carefully before removing Edit

For content managers, Editors and Authors, the Edit shortcut is often one of the most useful parts of the frontend Toolbar.

It creates a direct path from:

view content
↓
edit content

Removing it merely because the Toolbar should look cleaner may make everyday work slower.

Remove multiple Toolbar items in one callback

You do not need separate functions for every item.

A cleaner implementation can look like:

function mysite_clean_admin_bar( $wp_admin_bar ) {

    $wp_admin_bar->remove_node( 'wp-logo' );
    $wp_admin_bar->remove_node( 'comments' );
    $wp_admin_bar->remove_node( 'updates' );
}

add_action(
    'admin_bar_menu',
    'mysite_clean_admin_bar',
    999
);

Keep related customization together

If these removals all belong to one site policy, one clearly named function is usually easier to maintain than several unrelated snippets spread across the codebase.

How do you find a Toolbar node ID?

This becomes especially important for plugin-generated Toolbar entries.

The visible label:

Clear Cache

does not necessarily mean the node ID is:

clear-cache

The plugin may use:

plugin_cache_flush
vendor-clear-cache
cache-purge
myplugin-toolbar

Inspecting the rendered HTML can help

WordPress usually renders Toolbar list elements with IDs derived from the node ID.

For example:

<li id="wp-admin-bar-comments">

corresponds to the node:

comments

Remove the wp-admin-bar- prefix

If browser inspection shows:

id="wp-admin-bar-my-plugin"

the Toolbar node ID is commonly:

my-plugin

Then:

$wp_admin_bar->remove_node( 'my-plugin' );

may remove it.

Do not blindly rely on HTML inspection alone

For plugin-specific nodes, source code or documented hooks can provide a more reliable answer.

Plugins can generate dynamic IDs or different structures depending on context.

WP_Admin_Bar also exposes get_node()

You can retrieve a known node using:

get_node()

For example:

$node = $wp_admin_bar->get_node( 'comments' );

This can be useful when you want to inspect or modify an existing node rather than simply remove it.

get_nodes() can help during development

The current WP_Admin_Bar class also exposes node retrieval functionality that can help when inspecting the current Toolbar structure.

Be careful not to leave raw debugging output enabled on production websites.

Remove plugin-generated Toolbar items

Plugins often add Toolbar entries for:

• SEO;
• caching;
• analytics;
• forms;
• security;
• backups;
• page builders;
• maintenance tools.

If the node ID is known, the removal process is the same:

function mysite_remove_plugin_toolbar_item( $wp_admin_bar ) {

    $wp_admin_bar->remove_node( 'plugin-node-id' );
}

add_action(
    'admin_bar_menu',
    'mysite_remove_plugin_toolbar_item',
    999
);

If the item remains, the priority may be too early

Suppose the plugin adds its node at:

priority 1000

and your removal runs at:

999

Your callback runs first.

The plugin then creates the node afterward.

The result is:

remove nonexistent node
↓
plugin adds node
↓
item still visible

Run later than the code that creates the node

For example:

add_action(
    'admin_bar_menu',
    'mysite_remove_plugin_toolbar_item',
    2000
);

may work if the plugin added the item earlier.

Do not escalate priorities randomly forever

If you find yourself using:

999
9999
999999
PHP_INT_MAX

without understanding why, inspect when the plugin actually adds the node.

It is better to understand the hook order than to start an arms race between integers.

wp_before_admin_bar_render can help when priority becomes awkward

Because it fires after admin_bar_menu callbacks but before the Toolbar is rendered, it can be useful for final manipulation.

The official wp_admin_bar_render() source confirms that order.

Example using wp_before_admin_bar_render

function mysite_final_toolbar_cleanup() {

    global $wp_admin_bar;

    if ( ! is_object( $wp_admin_bar ) ) {
        return;
    }

    $wp_admin_bar->remove_node( 'plugin-node-id' );
}

add_action(
    'wp_before_admin_bar_render',
    'mysite_final_toolbar_cleanup'
);

Use the simpler API when it works

Most sites do not need to jump immediately to global variables and final-render hooks.

Start with:

admin_bar_menu
+
remove_node()

and use more complex timing only when necessary.

Remove items according to capabilities

Toolbar cleanup becomes especially useful when different users have different responsibilities.

Suppose users who cannot manage updates should not see the Updates shortcut.

function mysite_role_aware_toolbar( $wp_admin_bar ) {

    if ( ! current_user_can( 'update_plugins' ) ) {
        $wp_admin_bar->remove_node( 'updates' );
    }
}

add_action(
    'admin_bar_menu',
    'mysite_role_aware_toolbar',
    999
);

Why capabilities are useful here

The rule is:

User cannot manage plugin updates
→ update shortcut has little value

rather than:

User is not named Administrator
→ hide shortcut

A custom role could legitimately possess the required capability.

current_user_can() is the standard permission check

The official current_user_can() documentation explains how WordPress checks whether the current user possesses a capability.

For a deeper explanation, see WordPress User Roles and Capabilities, Explained.

Roles can still be appropriate for UX targeting

A Toolbar decision is not always a security decision.

For example:

Customer
→ simplified Toolbar

Editor
→ editorial Toolbar

Administrator
→ technical Toolbar

If the business requirement genuinely depends on a user category, role-based interface targeting can make sense.

See How to Target WordPress Users by Role.

Example: simplify the Toolbar for users without editorial responsibilities

function mysite_simplify_toolbar( $wp_admin_bar ) {

    if ( current_user_can( 'edit_posts' ) ) {
        return;
    }

    $wp_admin_bar->remove_node( 'comments' );
    $wp_admin_bar->remove_node( 'new-content' );
    $wp_admin_bar->remove_node( 'edit' );
}

add_action(
    'admin_bar_menu',
    'mysite_simplify_toolbar',
    999
);

Do not confuse interface cleanup with authorization

This is the most important warning in the guide.

Removing:

updates

from the Toolbar does not remove:

update_plugins

from the user.

Removing:

edit

does not revoke:

edit_post

A hidden shortcut is not a denied permission

Toolbar node removed
≠
destination inaccessible

The user may still reach the destination through:

• wp-admin navigation;
• a direct URL;
• another plugin;
• the REST API;
• another custom interface.

Actual access must be enforced separately

WordPress capability checks should protect sensitive actions regardless of whether a shortcut is visible.

Removing items with CSS is usually inferior

You could write:

#wp-admin-bar-comments {
    display: none !important;
}

Visually, the Comments item disappears.

But structurally:

WordPress created node
↓
HTML rendered
↓
CSS hides HTML

The node still existed and the interface was still generated.

remove_node() changes the Toolbar structure itself

WordPress creates Toolbar
↓
your callback removes node
↓
node does not render normally

For the broader distinction, see WordPress Admin Bar Removal vs. CSS Hiding Tricks.

CSS remains useful for visual presentation

CSS is still appropriate when the requirement is genuinely visual.

For example:

@media (max-width: 782px) {
    #wp-admin-bar-custom-help {
        display: none;
    }
}

That is a responsive presentation rule rather than an attempt to manipulate WordPress permissions or Toolbar architecture.

Do not use JavaScript as the first choice either

A JavaScript solution such as:

document
    .querySelector( '#wp-admin-bar-comments' )
    ?.remove();

acts after the browser has already received and parsed the element.

When WordPress already provides:

remove_node()

there is normally no reason to remove Core Toolbar items after rendering.

Be careful removing My Account

The user account area usually includes important actions such as:

Profile
Log Out

Removing the entire:

my-account

node can remove an obvious logout route.

If you remove account controls, provide alternatives

A custom application may have its own:

• profile page;
• account menu;
• logout button.

In that case the default WordPress account node may be redundant.

But never remove it casually just because fewer menu items look cleaner.

Be careful removing the site-name node

The:

site-name

node provides convenient navigation between the site and its administration area.

For staff who regularly move between:

frontend
↔
wp-admin

this shortcut can be useful.

Remove plugin marketing links more aggressively than workflow links

A Toolbar entry whose main purpose is:

Upgrade to Pro

does not have the same operational importance as:

Edit current page

or:

Clear cache

when cache management is part of the user’s actual job.

Evaluate function, not origin

Do not automatically remove everything added by plugins.

Some third-party Toolbar items are genuinely useful.

The correct question is:

Does this shortcut help this user
perform a real responsibility?

Different roles may need different Toolbar items

A practical model can look like:

Administrator

Site
Updates
Comments
New Content
Edit
Maintenance tools
Profile

Editor

Site
Comments
New Content
Edit
Media
Profile

Author

Site
New Post
Edit own content
Media
Profile

Customer or member

Account
Logout

or no frontend Toolbar at all.

For the broader role-specific strategy, see Customizing the WordPress Toolbar for Different Roles.

When should you hide the entire Toolbar instead?

If you find yourself removing almost every node:

wp-logo
site-name
updates
comments
new-content
edit
my-account
plugin item 1
plugin item 2
plugin item 3

the more appropriate question may be:

Does this user need the Toolbar at all?

WordPress supports frontend Toolbar visibility control

The:

show_admin_bar

filter can control frontend Toolbar visibility.

The official show_admin_bar documentation describes returning false as the recommended approach when the complete frontend Toolbar should be hidden.

Example

add_filter(
    'show_admin_bar',
    '__return_false'
);

Do not use full removal when useful shortcuts remain

The decision should be:

Toolbar still useful
→ remove selected nodes

Toolbar not useful
→ hide frontend Toolbar

TheOneWP Disable Admin Bar Items

TheOneWP Disable Admin Bar Items provides centralized control for removing selected Toolbar entries without requiring individual code snippets.

This is useful when the site needs repeatable administration policy rather than one-off CSS or theme edits.

TheOneWP Hide Admin Bar

If the entire interface is unnecessary, TheOneWP Hide Admin Bar handles the broader visibility use case.

The two features solve different problems

Disable Admin Bar Items
→ Toolbar useful
→ remove selected nodes

Hide Admin Bar
→ Toolbar unnecessary
→ remove entire interface for targeted users

Where should custom Toolbar code live?

Possible locations include:

• a site-specific plugin;
• a must-use plugin;
• a maintained snippet system;
• a child theme.

Administration policy often belongs outside the theme

If the requirement is:

Editors should never see
these Toolbar entries

regardless of the frontend design, the rule is more closely related to application behavior than theme presentation.

A site-specific plugin or managed snippet system is often a cleaner long-term location.

Do not edit WordPress Core

Never remove Toolbar items by editing files such as:

wp-includes/admin-bar.php
wp-includes/class-wp-admin-bar.php

WordPress provides a public API specifically for this purpose.

Core changes would also be overwritten by updates.

WordPress Multisite needs separate testing

Multisite adds Toolbar navigation associated with:

• My Sites;
• Network Admin;
• individual site dashboards;
• Super Administrator functionality.

A node that appears unnecessary for a normal site Administrator may be essential for a Super Administrator managing the network.

Do not test only as one user

Toolbar structure changes according to user capabilities.

A complete test should include representative accounts such as:

• Administrator;
• Editor;
• Author;
• Contributor;
• Subscriber;
• Customer;
• custom roles;
• Super Administrator on Multisite.

Test both frontend and wp-admin

The Toolbar can appear in both contexts.

A node may exist:

frontend only
wp-admin only
or
both

depending on its registration logic.

Test several frontend content types

Context-sensitive nodes can change depending on whether you are viewing:

• the homepage;
• a post;
• a page;
• a custom post type;
• an archive;
• a WooCommerce product;
• a plugin-specific frontend screen.

Test direct URLs after removing links

If the node was removed because a user should not access its destination, test the URL directly.

If they still have the capability, removing the Toolbar link did not solve the authorization problem.

Test after plugin updates

A plugin can change:

• node IDs;
• registration priority;
• parent nodes;
• display conditions.

A customization targeting:

old-plugin-node

will silently stop working if the plugin renames it.

Keep third-party node removal documented

Record:

Plugin:
Example Plugin

Toolbar item:
Clear Cache

Node ID:
example-clear-cache

Reason:
Hidden for Editors

This makes future maintenance considerably easier.

Do not over-customize Core without a UX reason

Removing every recognizable WordPress element can make the interface feel cleaner initially, but it can also remove:

• useful shortcuts;
• standard navigation patterns;
• documentation familiarity;
• expected account controls.

White-labeling and workflow optimization are not the same thing

Ask whether the item is being removed because:

it confuses users
it duplicates another interface
it exposes irrelevant functionality
it wastes space

or merely because:

it looks like WordPress

The former are stronger UX reasons.

Removing Toolbar items does not normally improve public SEO

The Admin Bar is shown to logged-in users.

Anonymous visitors and search crawlers normally do not receive the same Toolbar interface.

Removing several Toolbar nodes is therefore primarily an administration UX decision rather than an SEO optimization.

Performance claims should remain modest

Removing unnecessary nodes can reduce some interface output, but deleting a few Toolbar links is not a major frontend performance optimization.

The primary benefits are:

• cleaner navigation;
• less distraction;
• clearer role-specific workflows;
• more predictable administration UX.

Common mistakes when removing WordPress Admin Bar items

Using the wrong node ID

The visible label is not necessarily the internal ID.

Running the removal too early

The target node may not exist yet.

Using CSS instead of remove_node()

This hides rendered HTML instead of changing the Toolbar structure.

Using JavaScript to remove Core nodes after render

This performs work later than necessary.

Removing Edit from users who rely on frontend editing

Cleaner is not always faster.

Removing My Account without another logout control

Account navigation still needs a usable replacement.

Treating hidden links as access restrictions

Toolbar visibility is not authorization.

Removing everything for every role

Different users have different workflows.

Hardcoding plugin nodes without documenting them

Future updates become harder to debug.

Editing WordPress Core

The public Toolbar API already exists for this purpose.

Practical Toolbar cleanup example

The following example keeps useful editorial functionality while removing several technical shortcuts from users who cannot manage the site:

function mysite_customize_admin_bar( $wp_admin_bar ) {

    /*
     * Remove branding shortcut for everyone.
     */
    $wp_admin_bar->remove_node( 'wp-logo' );

    /*
     * Users without update permissions
     * do not need the Updates shortcut.
     */
    if ( ! current_user_can( 'update_plugins' ) ) {
        $wp_admin_bar->remove_node( 'updates' );
    }

    /*
     * Users who cannot moderate comments
     * do not need the Comments shortcut.
     */
    if ( ! current_user_can( 'moderate_comments' ) ) {
        $wp_admin_bar->remove_node( 'comments' );
    }

    /*
     * Users without editorial capability
     * do not need New Content.
     */
    if ( ! current_user_can( 'edit_posts' ) ) {
        $wp_admin_bar->remove_node( 'new-content' );
    }
}

add_action(
    'admin_bar_menu',
    'mysite_customize_admin_bar',
    999
);

Why this pattern is maintainable

Each removal corresponds to an understandable rule:

cannot update
→ no Updates shortcut

cannot moderate
→ no Comments shortcut

cannot edit
→ no New Content shortcut

The interface therefore follows the user’s actual responsibilities instead of depending entirely on role names.

Admin Bar cleanup checklist

• Confirm that the Toolbar itself is still useful.
• List unnecessary Toolbar items.
• Identify the exact node ID for each item.
• Use admin_bar_menu for normal Toolbar manipulation.
• Use WP_Admin_Bar::remove_node() for structural removal.
• Use a sufficiently late priority when modifying existing nodes.
• Use wp_before_admin_bar_render when timing requires it.
• Do not assume every node exists for every user.
• Do not assume visible labels equal node IDs.
• Inspect plugin-generated nodes carefully.
• Use capability checks when the rule represents permission or responsibility.
• Use role targeting when the rule represents a real UX audience.
• Keep Toolbar visibility separate from authorization.
• Do not use CSS as the primary node-removal method.
• Do not use JavaScript when the WordPress API can remove the node earlier.
• Preserve useful Edit shortcuts.
• Preserve a clear logout path.
• Review Updates according to maintenance responsibilities.
• Review plugin marketing shortcuts.
• Review cache and operational shortcuts before removing them.
• Test Administrators.
• Test Editors.
• Test Authors.
• Test Contributors.
• Test Subscribers.
• Test Customers or members.
• Test custom roles.
• Test Multisite separately.
• Test frontend pages.
• Test wp-admin screens.
• Test direct destination URLs.
• Retest after major plugin updates.
• Retest after major WordPress updates.
• Document third-party node IDs.
• Use full Toolbar hiding only when almost no Toolbar functionality remains useful.

TheOneWP tools for Admin Bar cleanup

Disable Admin Bar Items

TheOneWP Disable Admin Bar Items provides a centralized way to remove selected WordPress Toolbar entries without maintaining individual PHP snippets for every node.

It is the appropriate approach when:

Toolbar still useful
+
specific entries unnecessary

Hide Admin Bar

TheOneWP Hide Admin Bar addresses the broader case where selected users should not receive the Toolbar at all.

Choose the narrower solution when possible

One item unnecessary
→ remove one item

Several items unnecessary
→ remove selected items

Almost entire Toolbar unnecessary
→ consider hiding Toolbar

Related guides

• What Is the WordPress Admin Bar, and Who Sees It?
• Customizing the WordPress Toolbar for Different Roles
• WordPress Admin Bar Removal vs. CSS Hiding Tricks
• WordPress User Roles and Capabilities, Explained
• How to Target WordPress Users by Role
• Decluttering the WordPress Admin Dashboard

Final recommendation

If the WordPress Toolbar is still useful but contains unnecessary items, remove those items through the Toolbar API instead of hiding their rendered HTML.

The normal implementation is:

admin_bar_menu
↓
WP_Admin_Bar
↓
remove_node()

Use the exact node ID:

$wp_admin_bar->remove_node( 'comments' );

and run your callback after the target node has been registered.

For role-aware interfaces, decide whether the rule describes:

a permission
→ use capabilities

a user audience
→ role targeting may be appropriate

Keep interface visibility separate from security.

Node removed
≠
permission revoked

If the user should genuinely be unable to perform an action, enforce that through WordPress capabilities and server-side authorization.

Use CSS for appearance, not as a substitute for Toolbar structure.

Use complete Toolbar hiding only when the Toolbar itself no longer provides meaningful value.

The best Admin Bar cleanup is therefore not the one that removes the largest number of links. It is the one that leaves each user with the smallest useful set of shortcuts for the work they actually perform.