自動補完の最適なフォームUXについて – デザイナー VS 開発者

当記事はクリエイティブ・コモンズ・ライセンス(Creative Commons license / CC license)に基づいて翻訳・編集しています。

Mustafa(以下M): 開発者というのは、往々にして、ページ上に入力フィールドを設定するだけで、UXについて深く考えていないと思うんです。そのページの属性のことでもあるんですが、フォームの全体としての流れは考えたとしても、それぞれの入力やユーザーがどの点でやりづらさを感じるか?について気にする必要性を感じていないのでしょう。

そして、オートコンプリート(自動補完)がユーザーエクスペリエンスをスピードアップさせることに役立ち、フォーム入力をかなり「良く」するとわかっているわけです。ひとつの機能としてのオートコンプリートやオートフィルについてどのような想いそして経験がありますか?

 

Adrienne Porter Felt(以下A): ユーザーエクスペリエンスという点では、オンラインで何か買おうとしたり、子供の学校に提出する書類を記入しなきゃならない…という経験はありますよね。それを電話でするのはすごく大変なんです。本当に大変。デスクトップでやるのですら大変ですよ。だって1階に置いてある財布からクレジットカードを取りに立ち上がりたくないじゃないですか。

オートコンプリートやオートフィルなどのブラウザ上の機能によって、フォーム入力に関連するユーザーエクスペリエンスをかなり改善することができます。実際、フォーム入力をして送信するのに、オートフィル機能を使用した方が30%早くできることが分かったんです。だから、ウェブディベロッパーにこのことについて考えるように強く打診しています。

ユーザーにフォームを提出してほしいんですよね?じゃあ、そのフォームが素早く簡単に提出できるようなものにしなきゃならないですね、なら、オートフィルを取り入れましょう。

 

M: どうしてディベロッパーはそうしないんだと思いますか?取り入れるのが難しいことなのか?いくつかの属性を加えるだけのことだと思うんですが、どうでしょうか?

 

A: 実際、難しいことではないんですよ。基本的にオートコンプリート属性を設定する必要があって、通常の選択項目や入力要素を他の要素と置き換えるような派手な設定をしないようにするだけですね。

私が思うに、そういったディベロッパーのほとんどは、ただオートフィルといったことについて考えていなかったり、気付いていないだけじゃないでしょうか。そのフォームでオートフィル機能が動作するかを確認して、テストランするというちょっとした追加の努力をすればいいだけなんですよ。

 

M: ネイティブではなく、DIVといった代替えになるカスタムUIを作成する人にとっては、ひとつの挑戦になると思うんですが、オートフィル機能もそういうことになると思いますか?

 

A: 正直なところ、うまくいかないこともいくつかあるとは思うんですが、それは大きな問題のひとつです。

例えば、すごく美しいドロップダウンにもこだわりのあるカスタムされたフォームを作りたいとなると、結果として、DIVを使うことになります。すると、ブラウザーは「あれ、これはフォームのはずなのに」と認識することができなくなるんです。そして、そうなってしまうとオートフィルは機能しなくなります。

 

M: オートフィル機能に関連してアクセシビリティについての問題も多くあると思います。あなたから見ると、デザイナーとディベロッパーがいて、それぞれ独自の体験を提供できるようなものを作り上げたいと思っているわけです。

一方で、ブラウザサイドで作業する人間からすると「ブラウザに仕事をさせてよ」という意見になります。そこに中間点のようなものがあると思いますか?つまりどうすれば、ディベロッパーは、少なくとも、その製品独自でありつつ、同時にスタンダードを守ることができるカスタムエクスペリエンスを作り出すことができるのでしょうか?これはウェブ制作における大きな挑戦のひとつですよね。

 

A:そうですね、今使っているウェブページでもフォームの外観を変更するためにできることはたくさんありますよ。HTMLが提供している選択や入力要素がありますよね。そういったものを、カスタマイズする方法がたくさんあります。

確かにカスタマイズできないものが一つだけあって、それは選択要素でのドロップダウンの外観はカスタマイズできません。でも、それ以外は全てページの見え方などカスタマイズが可能で、ブラウザもフィールドがそこにあることを認識します。

 

M: では、あなたから見て、オートフィルやその実装にとっての最大の挑戦とは何だと思いますか?

 

A: そうですね、正直思うのは、ディベロッパーがオートフィルについて考えないということですね。オートフィルを想定したフォームのテストをする必要性が高いという風には考えないんですよ。自分で作成し、自分で100回の入力テストをしたとすれば、ユーザーが異なる精神状態であるという事実について考えません。ユーザーは疲れている状態かもしれないし、電話でできるだけ早くフォーム入力をしようとしているかもしれない。

つまり、ディベロッパーはちょっとした追加のステップを踏む必要があるという事実について、しっかり考えていないと思います。

 

M: ブラウザーの互換性という点でいうと、お話にある機能はGoogle Chrome固有のものなのか、それともオープンソースだけどクロスプラットフォームというものなのでしょうか?

 

A: それは良い質問ですね。オートフィル機能のためのオートコンプリート属性に限って言うと、標準化されていて、異なる全てのブラウザで重要視されています。と言いつつ、ひとつ「オートフィルオフ」機能は、オートフィルオフ属性なんですが、それは全てのブラウザで対応していません。ただ、クレジットカード情報を入力する必要があるフォームであれば、主要ブラウザでは対応しています。

 

M: 実際の使用感として、それぞれのブラウザに小さな癖のようなものはありますか?当然ブラウザ固有のものになるということですからね。

 

A: そうですね…少し違ったUIもあります。例えば、ドロップダウンの代わりにキーボードウィジェットを統合させているものとかですね。でも、どのブラウザでも大体同じ感じだと思います。

 

M: あなたはGoogle ChromeのUI自体に関わっていますよね。

 

A: はい。

 

M: 実際にご自身でChromeのデザインコードを構築しているのですか、それとも、そのプロセスに関しては、UXデザイナーと一緒に作業しているのですか?

 

A: まずデザインチームがいて、UIエレメントがどう見えるべきかを導き出すサポートをしてくれています。実は、今年大幅なデザイン改変を予定していて、実装としてもより美しいものになり、コードのクリーンアップにもなると思います。ほとんどの人には影響のないことだとは思いますけどね。見た目としての変化にはならないので。でも、私たちからすると、コードがかなり整頓されることになります。

 

M: あなたがUIを作成する実際のプロセスというのはどのようなものなんですか?というのも、僕はフロントエンドのコーディングをやっているんですが、ネイティブアプリの話になると、隠れたアートみたいな感じなんです。

あなたが実際に取り組んでいることはかなり細かい内容で、通常ユーザーが気付かないかもしれない部分ですよね。問題なく動作しているんですから。ただそれが崩れてしまうと、その作業がユーザーの目に触れるということですよね。

要は、ChromeのデザイナーチームとUIを作成したりテストしたりする実際のプロセスというのはどういうものなんですか?

 

A: そうですね、プロセスについて少しお話しします。通常は、まず最初に、プロダクトマネージャー、エンジニアとデザイナーが集まって、その機能に望むものについて話し合います。

だいたいの場合は、そこでデザイナーが、その機能がどんな感じに見えるのかをいくつかコンセプト的な試作として出してくれます。プロダクトマネージャーからのフィードバック、エンジニアからのフィードバックを受けて、実際に構築していくことができるのか? 問題が起きそうなケースとしてどのような想定が必要か? といったことを詰めていきます。そういったことを反復させながら、公開するものに近づけていくような感じです。

私は、クロスプラットフォームチームに所属しています。つまり私たちが構築したものは、全てのChromeプラットフォーム上で機能しなければならないということです。「Chrome」はひとつのプラットフォームだと思うかもしれませんが、実際はWindowsとMacがあって、それぞれ以前は異なるUIを使用していました。でも、単一のスタンダードができました。それがAndroidとiOSです。そこで、私たちはそれぞれの異なる試作をして特定のプラットフォームに関連づける作業をする必要があります。あるサブセットでしか機能しないものもあるんです。

とにかく、デザイナーはエンジニアからそういったあらゆるフィードバックを受けます。「こっちではこれはできるけど、あっちでは無理!」みたいな感じです。それを反復して、デザインの完成版のような最終ラインに到達したら、それが “実装するもの” ということになります。

 

M: 実際のW3Cでデザイナーの仕事をするという意味で、クロスプラットフォームでなければならないものをデザインしているということだと思うんです。例えばPayment Request APIとかは、僕もそのチームと仕事をしていたんだけど、他で行われていることをよく理解している必要があって、結果として作成したUXが他と大きく違いがないものになってしまう。それは、デザイナーやディベロッパーにとって試されるところでもあると思うんです。

本能的には「より良い」ものにしたい一方で、他とかけ離れたものにはしたくないものですよね。目立ってしまうので。

 

A: 興味深い質問ですね。ここでいう難しさは、スペックにありますよね。私たちは、UIがどう見えるべきだとか特定しないようにしています。ユーザーエクスペリエンスがどうあるべきかについて話し合うようにしています。

適切なコールバックを備えられるかとかを、UXを構築するために考えているんです。でも、UIそのものを標準化したいとは思っていません。それは、ある意味絶妙なバランスだと思います。APIをデザインするときにはUIについて意識しなければならないものなので。でも、私たちはできる限り一般的なものにしようとしていますね。そこから、追加として異なるエクスペリエンスが作れると思っています。

 

M: ブラウザについても同時並行で作業しているんですか? それとも、個別に進めているんですか? ブラウザ上の作業をしていると、全ての人にとってベストではない方向に引っ張られてしまうようなことがあると思うんです。でも、それは問題ないことで、ある意味妥協でもある一方で、完全な格差のようなものは持ちたくないですよね。

 

A: それはスタンダードによるところが大きいですね。正直なところ、Chromeでの使用に重きを置いている人もいれば、それ以外のブラウザの場合もあります。このAPIを何としてでも使用したいとなれば、実際に使用してみて、他のベンダーのものも試しながらフィードバックももらうという場合もあれば、最初から複数の異なるブラウザベンダーと一緒に作業を進める場合もあります。だから、正直スタンダードによって異なりますね。

 

M: Chromeは10周年を迎えようとしています。オートフィルや他のブラウザとの相互関係の将来についてどうお考えですか?

というのも、状況はどんどんよくなってきているように思うからです。Darrenと対談したとき、Flexboxの実装は悪夢だったと言っていました。それはスタンダードが変わり続けたからだそうです。でも、CSSグリッドでは、ブラウザを越えたコラボレーションが多く素晴らしい。エンドユーザーにとっても、それを使用するディベロッパーにとっても素晴らしいことです。プラットフォームとしてのChromeの将来について、特にオートフィルの将来についてどうお考えですか?

 

A: オートフィルに限って、というのはとても難しいですね。限界があるとすれば、それはブラウザベンダーの協力が欠如していることだからです。実際、これについては多くの議論がされていたと思います。例えば、Payment Requestに関しては、SafariとChromeの間で多くのコラボレーションがあります。実際に私たちが直面している問題は、オートフィルがディベロッパーがどのように採用するかに依存するということです。そうですよね?

もし、ページ上のフォームがどういうものか認識しづらいものだとすれば、オートフィルは機能しません。だからこそ、私が思うのは、私たちはディベロッパーが興味をもち、オートフィルというエクスペリエンスを改善するために提供しているツールとして使ってくれるかを重要視しています。

 

M: 今までに、広く使用されていないということで、何か機能を削除したことはありますか?というのは、エンジニアとして見て、Chromeというプロジェクトに参画することで、このオートフィル機能に心血を注いでいると思うんです。そして、それがユーザーエクスペリエンスとしても最高だとわかっていて、調査からもオートフィルがあらゆる取引を簡易化し、より良いものになったとわかっているわけです。

でも、もし使用されなかったら、どう対応する? というか、それが最も大きなことで…

 

A: とても難しい質問ですね。いくつかの廃止を経験してきましたが…とても困難なものもありました。とても大変なんです。いくつか見方があるんですが、まずひとつは、その機能を使っているウェブサイトにおけるユーザーインタラクションがどれだけあるかです。当然その数値が大きいと、多くのユーザーに対してマイナスになるポイントを作りたくないわけです。その数値がとても小さかったとしても、事業モデル全体がそのAPIへのアクセスがあることに依存しているようなウェブサイトや企業をいくつか含んでいるかもしれません。そういうこともあり、それがかなりニッチなものであっても、廃止するのはとても難しいことです。

全般として、こういった折り合いをどうつけるか? ということについて議論が続いていると思います。私が特化して関わったものに、セキュリティとTLSに関連するものがあります。ウェブを全体として安全なものにする場合です。何かの機能を廃止するために、何らかの接続を壊す必要があるかもしれません。

すごく心が痛むことですが、インターネット上に古いサーバーがあって、更新もされず、ページ全体からするとわずかなパーセントではあっても、ユーザーがそのウェブサイトを開こうとしても開けないというのはやはり煩わしいものです。

 

M: 最終的には、Chromeの観点では、ユーザーエクスペリエンスが最優先ということですよね。

 

A: そうです。

 

M: そして、安全とセキュリティですよね。HTTPSがそうです。あなたの方が上手く説明できると思うんですが、分割点のようなもので、HTTPSで読み込まれていないサイトは、「これは安全ではありません」というメッセージが表示されます。そうですよね?

 

A: Chromeでは長い間、HTTPをニュートラルなもの、ただのプレーンテキストであり、TLSはないと示してきました。

 

M: ごめんなさい、TLSって何ですか? 僕みたいなデザイナーじゃない人間のために。

 

A: TLSとは、HTTPSを構築する基盤となるプロトコルのことです。HTTPSはとても安全です。で、HTTPがあり、それはエンドツーエンドのセキュリティとなるものが何もないものです。HTTPウェブサイトはただ表示されるだけで、ニュートラルなスタンダードみたいなもので、ウェブ上のほとんどのサイトがHTTPでした。でも、それが変わったんです。

数年前までは、HTTPSは全体の25%だったのが、今では逆になり75%がHTTPSです。そこで、UIにも変更を加えてHTTPSに対応するものにしたんです。だから今ではHTTPのウェブサイトを開こうとすると、そこに「安全ではない」と表示されます。そうすればどういうことか理解できますよね。

 

M: その決断はとても大変なものだと思うんですが。いくつかの点では、ディベロッパーにユーザーのセキュリティが最優先だと言い聞かせなければならないと思います。ただそれと同時に、自分がしていることがウェブを壊しているとは感じませんか?

 

A: ウェブを壊しているようには感じていません。誰もがこの状態になっていくのを長く目にしてきていますし、このことについて長く話をしてきましたし、段階を踏んで進めてきました。だから、最初は「安全ではない」というメッセージをパスワードやクレジットカード入力フォームがあるページに限定して表示するところから始めました。そこから、入力フォームがあるページやシークレットモードで表示されるウェブページに適用させました。

そして現在は、全てのHTTPウェブサイトに適用されています。現状からも分かるように、HTTPSの採用は大きく増加していて、現時点で全体のページロードの4分の1未満にしか影響はありません。

 

M: つまり、ユーザーを守ることについて話してきたということですね。

 

A: そうですね。ユーザーにはどのウェブサイトを読み込むと自分の情報が安全ではなくなるのかを知る権利があると思います。そのサービスを使い続けるか、別のものを使うかを判断するのに役立つと思うんです。

 

M: 現在のユーザーはそういうことがわかるようになって、賢い選択ができるようになったと思いますか? それとも、ユーザーに対しての教育の一環で、「ほら、気をつけて。ウェブには安全じゃないものもあるから、よく考慮しないといけないよ。」ということですか?

 

A: 正直にお話ししますね。文字通り何十億人ものアクティブユーザーがChromeを使用していますが、実際に理解しているかどうかというのは難しい問題です。十分な数の人たちが理解しているとは思います。反応をしているので。

ユーザーが実際サイト作成者に連絡して、「こんにちは、このサイトはとてもいいと思うんだけど、安全なものにしてくれたらいいのに。」と伝えることができます。この警告メッセージを開始してから、実際にそういう動きをする人を見てきました。

 

参照リンク : Using Autocomplete for Optimal Form UX – Designer vs. Developer #24 – Google Chrome Developers CC BY 3.0)
当記事はクリエイティブ・コモンズ・ライセンス(Creative Commons license / CC license)に基づいて編集しています。

共感いただけましたら、いいね!シェアいただけますと幸いです。

ASOBO DESIGN™ とは

ASOBO DESIGN ロゴ

ASOBO DESIGN (アソボデザイン)へようこそ!デザインの制作に関わることは何でもご相談ください。

チラシ・ポスター・パンフレットや、名刺・ショップカード・DMなどの各種印刷物、看板・ロゴマーク・パッケージデザインまで幅広いグラフィック・広告デザインに対応いたします。デザイン制作だけでなく、印刷から納品まで一貫して対応(※)しており、展示会・キャンペーン・販促宣伝活動等に貢献致します。※一部媒体を除きます

お問い合わせ

デザインの見積もり・制作依頼

SSL カード決済対応 銀行振り込みの他、各種クレジットカードでのお支払いにも対応しています。 デザイン料金はクレジットカード対応

ピックアップNEWS

実用的な折チラシデザイン
書籍「実用的!折りチラシデザイン」に作成したチラシが掲載されました。

チラシデザインが書籍に掲載されました
書籍「タイトルまわりのデザイン表現」にチラシデザインが掲載されました。

チラシデザイン集に掲載されました
書籍「実用的なチラシデザイン」にデザインが掲載されました。

雑誌掲載事例
デザイン総合情報誌「MdN」にWEBサイトが掲載されました。

メディア掲載事例について
インディーズCDの制作ガイドに、デザイナーとしてのインタビュー記事が掲載されました。

インターナショナルファッション誌 "En Vie Fashion Magazine" 内にデザインが掲載されました。

Adobe MAX Japan にて制作デザインが展示されました。

NEWS&PRESS情報一覧

事業概要 / ご利用規約

平日11時〜18時は電話でのお問い合わせも承ります。
050-5243-3791
問い合わせ専用となります。具体的な依頼の進行はメールでのやり取りとなりますので、予めご了承ください。タイミングによっては営業時間内でも応対出来ない場合もございます。その際はお問い合わせフォームをご利用ください。

お問い合わせフォーム