Implementing keyboard shortcuts: a global and inclusive approach

The challenge

Healthcare professionals at Doctolib needed to work fast, but our interface wasn't keeping up. In Germany especially, where many users came from legacy softwares with keyboard-first workflows, the mouse-heavy interface felt like driving with the handbrake on.

But this wasn't just about adding shortcuts. It was about designing a universal language that could:

  • Bridge cultural differences between German power users and French mouse navigation preferences
  • Navigate technical constraints across multiple OS, browsers and our Electron App
  • Uphold our accessibility standards (WCAG 2.1.4)
  • Scale without creating chaos

The landscape was fragmented. German users expected single-key shortcuts like A for "anamnesis", patterns that conflicted with assistive technology needs. French users favored their mouse. Our two platforms, browser (with OS/browser limitations) and Electron (more flexible but prone to conflicts), each had their own constraints.

The design dilemna was then: How do you create keyboard shortcuts that feel natural for power users, remain discoverable for newcomers, and never exclude anyone?

My role and approach

I took end-to-end ownership as the lead designer, driving this from research through implementation. My methodology centered on three pillars:

1. User research as foundation

Accompagnied with a team of cross country user researchers, I launched a quantitative survey targeting both current and potential shortcut users across France and Germany. The insights revealed:

  • 40% of non-users recognized shortcuts as important, signaling strong latent demand
  • German users strongly preferred simple combinations because they were used to, but these violated our accessibility standards
  • No consistent pattern existed among competitors, an opportunity to define our own standard

2. Technical collaboration

I facilitated workshops with our tech teams (owning the Electron app) and browser developers to map "safe zones", shortcut patterns that wouldn't conflict with OS or browser defaults. This wasn't just about feasibility; it was about co-creating a system that was technically sound and experientially coherent.

3. Stakeholder orchestration

I balanced competing needs: German users demanding simplicity, accessibility advocates ensuring inclusivity, and product teams across both markets wanting consistency, and knowing how fast Doctolib is, I was aiming for scalability.

The solution: 3 categories, 1 language

Like any well-designed language, our system needed grammar, consistent rules users could internalize. I established a framework built on four core principles and three shortcut categories.

1. Core principles

To maximize user benefit and ensure long-term scalability, every keyboard shortcut had to follow these essential principles:

  • Conflict-free
    Shortcuts must not interfere with system, browser, or application-level key bindings. They should ensure a smooth and predictable user experience.
  • Discoverable
    Shortcuts should be easy to find and learn. Users must be able to access documentation or UI hints about available shortcuts.
  • Memorable
    Use intuitive and meaningful key combinations. Shortcuts should be easy for users to remember and relate to their function.
  • Unique and predictable
    Each shortcut must perform a single, clearly defined action to avoid confusion and ensure consistent behavior. These principles became our decision-making compass, helping us navigate technical constraints while keeping user needs at the center.

These principles became our decision-making compass, helping us navigate technical constraints while keeping user needs at the center.

2. Shortcut categories

2.1 navigation shortcuts

Navigation shortcuts enable users to move efficiently through the application. We distinguish two types:

2.1.1 Default navigation shortcuts (accessibility standards)

These shortcuts follow universal conventions and are expected by users across all web applications. They must always be present and never overridden:

  • Tab ⇥: Move focus to the next interactive element
  • Shift ⇧ + Tab ⇥: Move focus to the previous interactive element
  • Arrow Keys (←↑→↓): Navigate within lists, menus, or grids
  • Enter ↵ / Space ␣: Activate the currently focused element

Design decision: These shortcuts are essential for accessibility and keyboard navigation. They remain available and function as users expect, regardless of any custom shortcuts implemented. This was non-negotiable, even when German users requested single-key overrides.

2.1.2 Product-specific navigation shortcuts (custom, app-level)

These shortcuts are designed to enhance productivity by enabling quick navigation between major sections of the application. They mirror the visual tab order in the interface, making them instantly memorable.

Examples:

  • Ctrl+1: Jump to Calendar
  • Ctrl+2: Jump to Patient Flow Manager
  • Ctrl+3: Jump to Tasks

Why this works: Numbers follow left-to-right tab order. Users can internalize the pattern by simply counting. The Shift modifier in browsers prevents conflicts with browser tab-switching shortcuts.

2.2 global key actions

These shortcuts trigger main actions from anywhere in the product. They align with industry standards for familiar, high-frequency actions.

Examples:

  • Patient search: Command(⌘)+K (Mac) / Ctrl+K (Windows), borrowed from Slack and Notion for instant recognition
  • Read insurance card: Command(⌘)+G (Mac) / Ctrl+G (Windows), this action is a major one in our product.
  • Create patient: Command(⌘)+E (Mac) / Ctrl+E (Windows)

Why this works: Leverages existing mental models. For instance, currently many search feature are using G or K as letter in addition to Command(⌘) or Ctrl

Design constraint: The list of available global shortcuts is limited, with high risk of conflicts with existing combinations like Command(⌘)+C or Command(⌘)+P. Introducing a new global key action requires careful consideration and validation against our conflict-free principle, knowing that the number of available letters is quite limited as many of them are already used by OS.

2.3 Local key actions

Local key actions are context-specific actions valid only in specific workflows or pages.

Examples during a consultation:

  • Add diagnosis: Option(⌥)+D (Mac) / Alt+D (Windows)
  • Create medication prescription: Option(⌥)+M (Mac) / Alt+M (Windows)

Quick note: Option(⌥)+Q (Mac) / Alt+Q (Windows), initially Ctrl+D, changed after pilot feedback revealed conflicts.

Why this works: Clear separation from global actions prevents confusion. The Alt/Option modifier signals "this works here, in this context." This pattern allows us to reuse letter combinations across different contexts without creating conflicts.

3. Best practices codified

Beyond the three categories, I established design rules to guide future implementations:

  • Shortcuts trigger actions, not flows: Shortcuts should not operate inside multi-step forms. Within forms, standard navigation keys (Tab, Enter, arrows) handle all interactions.
  • Shift as a modifier means "do more" or "do differently": Following browser conventions (e.g., Command(⌘)+N for new window, Command(⌘)+Shift+N for incognito).
  • Never override navigation: Standard navigation keys must retain expected behaviors unless there's an explicit, justified exception.
  • Visibility is mandatory: Shortcuts must be displayed in plain text and always visible in the UI where relevant. We use tooltips when permanent display is impractical.

Navigating constraints

Browser limitations

Some shortcuts can't be overridden (Cmd+S, Ctrl+T). Rather than fight the browser, I designed around these, choosing "safe" letters and modifier combinations. This constraint actually improved consistency, forcing us to be more thoughtful about every choice.

Platform parity with flexibility

While Electron offered more freedom, I maintained parallel patterns across platforms. When differences were necessary (like Ctrl+Shift+[Number] for browser navigation), I ensured the mental model stayed consistent, it's still "number = tab position," just with an extra modifier.

Accessibility non-negotiable

Single-key shortcuts were off the table, despite German user requests. Screen reader users, mobility assistance users, and those with tremors need modifier keys to prevent accidental triggers. This wasn't a compromise, it was better design for everyone.

Making shortcuts discoverable

Efficiency without awareness is like a bridge with no signage. I designed three discoverability layers:

  1. Cheat sheet in Help Hub: Complete reference, searchable and categorized
  2. Contextual hints: Shortcuts appear next to button labels throughout the interface
  3. Scalable documentation framework: Clear guidelines for adding new shortcuts without breaking the system's logic

Rollout and impact

German pilot (Spring)

Initial deployment with power users validated the technical logic. However, feedback revealed visibility was critical, users loved the shortcuts but couldn't find them. This directly informed the cheat sheet and hint implementation.

Cross-platform launch (Summer)

Impacted users:

  • 78% of French users (browser platform)
  • 69% of German users (Electron app)

The system now covers both platforms seamlessly. Post-pilot adjustments included changing local shortcuts (Ctrl+D → Alt+Q) based on real-world conflict reports.

Cultural bridge

German users gained efficiency without losing accessibility. French users discovered shortcuts through hints, gradually adopting keyboard-first patterns. The system didn't force a choice, it invited users in.

Impact

Now that these shortcuts are live, we never received additional requests on the Community, and some teams created new shortcuts following the recommended patterns in full autonomy.

What I learned

1. Design can lead technical projects

This could have been a pure engineering initiative. By leading with design thinking, focusing on patterns, mental models, and user needs, we built something coherent rather than just functional.

2. Constraints spark better solutions

Browser limitations and accessibility requirements initially felt restrictive. They became our design principles, forcing clarity and consistency we might not have achieved otherwise.

3. Cultural differences require translation, not compromise

The German-French divide wasn't a problem to solve, it was context to design for. The three-category system gave both user groups what they needed through different entry points.

The bigger picture

Keyboard shortcuts are more than a feature, they're a language. And like any language, their power lies in their ability to unite, not divide.

This project proved that inclusivity and efficiency aren't opposing forces. By treating shortcuts as a designed system, not just a feature list, we created something that serves power users without excluding anyone. It's a reminder that the best design often comes from the hardest constraints.