パスキーに関するデザインガイドラインを斜め読み(1) UXとコンテンツの原則

ritouです。

今回はFIDOアライアンスが公開したデザインガイドラインを取り上げます。

デザインガイドライン

https://www.publickey1.jp/blog/24/fido.html

パスキーは、従来のパスワードによるユーザー認証よりも強力で安全な認証方式とされており、普及が期待されていますが、多くのユーザーが慣れ親しんできたパスワード方式と比べると、サインアップやサインインの方法が分かりにくいという課題が指摘されていました。

FIDOアライアンスによるデザインガイドラインの公開は、こうした状況を改善するものとして期待されます。

(メモ)

サービス(Relying Party)がパスキー認証を利用する、Webブラウザ(Client)、パスワードマネージャーやセキュリティキー(Authenticator)が連動して動作し、その結果を処理していく部分はWebAuthnというブラウザAPIを適切に利用することで実現できます。

仕様はわかった、ではいざパスキーの登録、パスキーによる認証を実装しようと思うと次に考えなければならないのが「定番のUX」です。しかし、まだ登場して日が浅いパスキー認証を先行実装したサービスでももともとの認証フローやけっこう違いがあってどれが参考になるかを見極めるのに悩んだしまったり、開発者目線で「現時点で最良のUX」を実装できたと思っても初見であるユーザーにとって理解しがたいものだったりします。うちのサービスは元々パスワードを使っていなかったので他のサービスと同じUXとはいかないんだよなぁとかも似たような話ですね。

そこで「定番のUX」を定着させ、サービスとユーザー両方の迷いを減らすためのガイドラインが策定されて公開されたということです。もちろんこれが全て、というものではないと思いますが参考にできるものがあればしていきたいところです。

https://fidoalliance.org/design-guidelines/

Publickeyの記事にもある通り、コンテンツとして大きいというか、読み応えのある部分はDesign PrinceplesとDesign Patternです。今回は Princeples の方をざっくり見ていきます。

Design Principles

今回は "Design Principles" で説明されているUXの原則、コンテンツの原則について見ていきます。

https://fidoalliance.org/design-guidelines/principles/

UX Principles

10個あります。

1. Prompt to create passkeys alongside account-related tasks.
2. Associate the unfamiliar (passkeys) with the familiar.
3. Use proven passkeys messaging and icons before and after OS dialogs.
4. Allow freedom and choice related to passkeys.
5. Follow accessibility principles before and after the use of passkeys.
6. Use a passkey hero prompt consistently across the customer journey.
7. Persist helpful information about passkeys.
8. Make passkeys a primary option in account settings.
9. Display “passkeys cards” with content to give shape to passkeys.
10. Plan your UX in accord with your unique security and business needs.

それぞれ見ていきましょう。

1. Prompt to create passkeys alongside account-related tasks.

ユーザーがアカウント管理に関する作業(例えばアカウントの作成やリカバリー)を行っている時、またはアカウント設定の一部としてパスキー作成のオプションを提示すると、ユーザーはそれをサイトの体験を向上させるための適切な機能と捉えやすくなる。 これに対して、ログインの過程でパスキーの作成を促すと、パフォーマンスがあまり良くない。

(メモ) 特に後者、既存の認証方式からのアップグレード的なのを考える時にログインした時に...と考えがちなので認識しておきたいですね。あ、でもデザインパターンにはパスワード + SMSからのパスキー誘導みたいなのがあった気もします。

2. Associate the unfamiliar (passkeys) with the familiar.

パスキーはユーザーにとって新しい用語、視覚的シンボル、認証方法なので、ユーザーがパスキーの性質や価値を理解できるように、可能な限り馴染みのある概念や視覚、体験と結びつけて説明する。 例えば、生体認証の体験は多くの人にとって馴染み深いものである。

(メモ) これも前から言われていますが、ブラウザやデバイスの方は "パスキー" という表現を使いまくってるので、クッションというか結び付けはサービスが行う感じなんですよね。ブラウザで説明してくれたら...と思わなくもないですが難しいのでしょう。

3. Use proven passkeys messaging and icons before and after OS dialogs.

(生成、認証といった)パスキーのOSダイアログを表示する前後でタスクの現在のステータスや関連するパスキーのメッセージ、アイコン、アクションを表示する。 これにより、RPとOSダイアログの間に "ハンドシェイク" が提供され、OSとサービスがどのように連携してパスキーを通じてアカウントアクセスとセキュリティを最適化しているかが明確になり、ユーザーのパスキーという新しい概念に対する信頼と関心が高まる。

(メモ) いきなりダイアログが出てきちゃうとユーザーはびっくりしてしまうので、なるべくサービス側で説明してダイアログに繋げましょうという話ですね。数年前のガイドライン公開時は、Heroページを作れみたいなのがあった記憶があります。現状、「まだユーザーのほとんどはパスキーのことを知らない、なので丁寧に説明していくUX」のと「より短い操作で完結するUX」という2つのアプローチがあるように思っていますが、この原則については前者と言えるでしょう。

4. Allow freedom and choice related to passkeys.

ユーザーが自分の体験をコントロールし、ブランドに対する信頼を育むためには、パスキーの作成や管理に関する明確な選択肢を提供することが重要。ユーザーがパスキーを使ってアカウントを作成するかどうかを選べるようにしたり、パスワードのリセット時には新しいパスワードを作成するか、代わりにパスキーを作成するかを選べるようにする。このように自由な選択肢を提供することで、ユーザーは自分の好みに合わせた方法でアカウントを管理できるようになると。

(メモ) 自分もパスキー必須となるユースケースについて考えたりしますが、過渡期である今は特にユーザーに自由度を与えつつ使い始めてもらう、というのが重要かもしれませんね。

5. Follow accessibility principles before and after the use of passkeys.

ユーザーがしっかり認識できて、ブラウザやパスワードマネージャーの支援機能を使いながら操作でき、色々な制限を持っているユーザーにも理解しやすい方法が提示されている状態が最もアクセシブルですよと。
**ブラウザ、パスキー利用の全体を通して、アクセシビリティのガイドラインを遵守することで全てのユーザーがパスキーを使用しやすくなり、包括的なユーザー体験が提供される。

例示されているドキュメントも見ておくのが良さそうですね

https://fidoalliance.org/white-paper-guidance-for-making-fido-deployments-accessible-to-users-with-disabilities/

https://www.w3.org/TR/WCAG21/

6. Use a passkey hero prompt consistently across the customer journey.

パスキーの「ヒーローコンテンツ」を作成し、その中には特定のシンボル、見出し、メッセージ、および行動を促す呼びかけを含める。 例えば、「パスキーを作成」ボタンだけを使用するのではなく、完全なヒーローコンテンツを使用するように、ユーザーのアカウント関連の一連の機能で利用する。 これにより、ユーザーはパスキーの価値や利用方法をより深く理解しやすくなる。

(メモ) 出ましたヒーローコンテンツ。まぁ慣れるまでは地道にこういうものがあってうちは対応してるよ、と周知を続けるべきというところでしょうか。

7. Persist helpful information about passkeys.

パスキーに関するお役立ち情報をデフォルトでユーザーインターフェースに表示し続ける。 例えば、パスキーが何であるか（「what」）やどこで使用するか（「where」）についてのメッセージを、パスキーが作成された後もアカウント設定のヒーローメッセージに保持し続け、追加のクリックで隠さないようにする。

別の例では、上記の原則のようにユーザーがパスキーを無効にする選択肢を与えられるべきだが、無効にした場合のサインイン方法が分からないかもしれないので「パスキーを無効にする」リンクの横に、パスキーを無効にするとどうなるかの簡単な説明をする。これもツールチップのようなものではなくデフォルトで表示する。

(メモ) こういう情報はついツールチップやヘルプに載せたりしたくなりますが、結構強火で表示していこうという話ですね。

8. Make passkeys a primary option in account settings.

パスキーの表示と操作モデルを、ユーザー名、パスワード、または2段階認証（2FA）などの他の認証項目と一致させる。 例えば、アカウント設定内の他のサインインオプションがH2見出しでラベル付けされている場合、「パスキー」もH2見出しでラベル付けします。このようにすることで、パスキーが他の主要な認証オプションと同等に扱われ、ユーザーにとって一貫した操作体験が提供される。

(メモ) 控えめなオプションではなく既存の方式と並べて推していけよという話です。

9. Display “passkeys cards” with content to give shape to passkeys.

パスワードとは異なり、パスキーは人々にとってよく見えないデジタルの鍵である。そのため、アカウント設定内にパスキーカードの機能を表示する。このカードの中には、パスキーのアイコン、メッセージ、およびユーザーにパスキーが有効で利用可能で管理可能であることを安心させるオプションを含める。 もしユーザーが複数のパスキーを持っている場合、各パスキーにはそれぞれ独自のカードを用意して、ユーザーはパスキーの存在を視覚的に確認しやすくなり、管理しやすくなる。

(メモ) パスキーは複数設定できること、これが有効化されているとか最後に使ったのはいつかなど表示する内容はいくつかあると思うのでユーザーがイメージしやすいUIを目指したいですね。

10. Plan your UX in accord with your unique security and business needs.

このガイドラインは、同期されたパスキーを用いたFIDOに特有のUX概念に焦点を当てつつ、ガイドライン全体を通じて、さまざまな形態のアイデンティティ証明や非FIDO認証の例が紹介されている。しかし、これらのガイドラインは、アイデンティティ証明や他の非FIDO認証メカニズムのためのセキュリティガイドラインを定めることを目的としていません。これらは各RP独自のビジネスニーズとセキュリティポリシーに基づいているためである。

ガイドラインにあるシンボル[i]は、サービス自身のセキュリティポリシーやビジネス判断が必要な箇所を示している。このシンボルがある場所では、独自のセキュリティポリシーとビジネスの要求を考慮してUXを設計する必要がある。

(メモ) それはそう。あくまで他の認証方式などとの組み合わせも考慮はしているけど、どの認証方式と組み合わせるか、その方式自体に関するUXなどはサービス側が自分とこのポリシーに基づいて考えてねというところですね。わざわざここはあなた方が考えてくださいよ、と教えてくれるの親切ですね！

Content principles

上記UX原則をちゃんとコンテンツの原則に落とし込み、デザインパターンに繋げていきましょう。

1. Pair passkeys language with wording they know.

パスキーは多くのユーザーにとって新しい概念である。ユーザーがこの新しいサインイン方法の価値を理解できるように、パスキーが既に使用している他の方法とどのように関連しているかを示す。 例えば、「パスキーを使えば、複雑なパスワードを覚える必要がありません」や「パスキーは、指紋、顔、またはパスコードを使用して作成する暗号化されたデジタルキーです」といった説明をする。

(メモ) 馴染みのあるワードを使って説明しましょう。他の認証方式との関係などもちゃんと説明しましょう。というところ。

2. Use clear “handshake” messages before and after OS dialogs.

OSのパスキー体験に対してユーザーが安心感を持てるように、OSダイアログの前に「アカウント作成」や「パスキー作成」といった明確なメッセージを表示し、ダイアログの後には確認や成功のメッセージを表示する。 これにより、あなたの会社がOS/Platformと協力してパスキーでアカウントを保護していることをユーザーに再確認させることができる。

(メモ) ブラウザのダイアログの前後もちゃんとサービスがわで説明なり誘導を行なってスムーズに処理を進めてもらいましょうということ。

3. Use passkey messaging throughout the customer journey.

パスキーのプロンプトや情報を、ユーザーージャーニーにおけるアカウント関連機能（登録、リカバリー、設定）で利用し、ユーザーがパスキーを試すことを促します。これには、明確にラベル付けされた「パスキーを作成」ボタンや、詳細な「なぜ」「何」「どこで」のパスキーメッセージなどが含まれます。これにより、ユーザーはパスキーの価値を理解し、利用しやすくなる。

(メモ) しっかり説明しましょう、というところ。

まとめ

今回はFIDOアライアンスが出したデザインガイドラインのデザイン原則について斜め読みしてみました。
馴染みのある生体認証などのキーワードとうまく関連付けながら説明する、その説明もヘルプに置いたりツールチップではなく前面に出すなど、新しい技術、馴染みのないパスキーというものをユーザーに理解してもらいましょうというアプローチが透けて見えています。

これが未来永劫使えるガイドラインかと言われるとうーむと思うところもありますが、過渡期でありとにかく使い始めてもらいたい現状におけるガイドラインというところなんだろうなーと思います。
引き続き、この考えを念頭におきながら今度はデザインパターンの方も見ていきたいと思います。

ではまた。