Sky Glass: Developing a new keyboard input

Background:

Input on 10-foot interfaces is typically a hard thing to perfect, and typing text is seen as particularly tedious. It’s also dependent on the hardware and physicality of the input device: remote D-pads, joysticks, pointers and touchpads all require different approaches.

Working on the Search project highlighted a clear need for a new keyboard, not just for the Search page, but for all types of input across the platform: email, password, and form completion – so this project was split into a separate workstream: to build a holistic, system-wide modular keyboard.

My Role:

I worked as the only UX designer on the project, and collaborated with product leads, other UX designers, developers and a UI designer.

Work included competitor analysis, stakeholder interviews, prototyping, moderated research, design, and dev handover.

Before: Text Search on Sky Q (Ribbon Keyboard)

Before: Sign in – Sky Q Germany

Before: Form input on Sky Q (Ribbon Keyboard)

Before: App overlay keyboard on Sky Q

🧠 Platform keyboard audit: Insights

  • The 'vertical ribbon’ keyboard layout has some usability issues including:

    • Its length means some characters are 30+ clicks away.

    • Not all characters can be seen on-screen at once so users have to scroll to discover.

    • No competitor uses this 'vertical' design pattern, so it is unfamiliar

    • It was originally designed for a ‘touch’ remote, but all input is now one-click from a ‘D-Pad’ on the remote

    • Not all special characters are included, which would technically make some wifi and password combinations impossible to input

  • There’s no consistency between keyboard layouts across the platform, making input unfamiliar.

 Differentiation of searching for content vs inputting data

🍿 Content Search

Goal: Quickly find a specific piece of content
Goal: Check if content is present on the system

  • Simple: usually only some characters inputted

  • Backend doing bulk of the work to give results

  • Multiple ways to support user, e.g. suggestions

We can support by guessing what the user wants from a finite list of options. We're helping them narrow down to something we can show, usually done by a results list.

👩‍💻 Data Input

Goal: Quickly and accurately input specific data

  • Complex: user often must input every character

  • User doing bulk of the work to choose characters

  • Usually personal info, no way to guess exact input

We can support by knowing the format of that form type. We’re helping them by offering things that are standard to ‘that’ form, e.g. an ‘@gmail.com’ button if it’s an email form.

👀 Competitor Research & Analysis

In the discovery stage of the project, it was important to build on and learn from existing design patterns across other TV platforms, both for content search and data input. Size, shape, layout and functionality of other keyboards were all collected into a matrix, so we could compare features, and cherry-pick things that were working best.

👉 Findings from competitor research

  • Competitor content keyboards tend to be a grid of uppercase letters, arranged in an ‘ABC’ format, whereas data input keyboards (blue columns) tend to be QWERTY.

  • The squarer the keyboard is, the closer together all the characters are, and the quicker it is to navigate. QWERTY keyboards trade layout for speed, as they have to be a rectangle (10 keys wide), whereas ABC keyboards can be square.

  • Content search keyboards only need letters and numbers for simplicity

  • Keyboards like Apple’s are designed around their proprietary input method (long and thin for touch remote), to restrict users navigation to one axis.

  • Glyphs (e.g. delete, space) work better for some characters than others.

Sketching and ideation

👉 Interactive keyboard prototype

Alongside a Lead UX Designer, I built a functional prototype of the first iteration of the keyboard. This was constructed as a Protopie component, which could be added to other prototype scenes, and could send key commands upwards. These could be read by the scene and processed into actual text input, allowing our journeys using the keyboard to be more complex, and our testing more realistic.

 

✍️ Testing

Another project: ‘3rd-party App Sign-in’ was in need of a keyboard component, and in need of evaluation, so the first iteration of the prototype was built into the journeys, and both were tested together.

👉 Testing Results

  • Generally the keyboard was well received, and all participants were able to use it without many issues. All participants used the email bolt-ons.

  • Tweaks were made to the visibility of some characters, as users were unable to find them.

  • Some participants found the spacebar glyph confusing, so it was updated to a written word instead.

 Final Keyboard Layout and UI

The keyboard was finalised as a modular component, so it appears consistent across all touchpoints. Variations included:

  • A ‘content search’ layout for use in the Search page, with uppercase letters, numbers, space and delete.

  • An ‘input’ layout for forms like passwords, including a shift toggle, and special character key.

  • An ‘email’ layout, with modular components – which shift as you type in an email address.

A few changes can be seen in the final version, and were the result of conversations with UI designers and developers, but the overall layout remained largely the same, and it retained the majority of its features and functionality through the design process.