デザイナーが集まってインプットUIを話し合ってみた

暗黙知になっていることをクラスメソッドのデザイナーみんなで共有してみようの会として、UIの共有会を開催しました。 今回は入力フォームのルールについて対話しました。

• コトの経緯や第一回はこちら

ひとまず今回に関しては、情報共有して認識を合わせることが目的のため、「クラスメソッドではこうしてます！」みたいなものではない点はご了承ください。

テキストフィールド

フォームにおける「テキストフィールド」について、チーム全員でどうしているか、またはどうあるべきか、について対話をしました。「テキストフィールド」は１行テキストを入力する箇所であり、ここでは主にフォームやダイアログで使用される部分を指すこととします。

テキストフィールドのパターン

デザインパターン

デザインパターンとしては４種類を上げました。（ここではどれが正解、というものでもありません）

A. 下線のみ B. 線の矩形 C. 塗りつぶしの矩形 D. 文字の入力ルール（ex : 半角英数◯◯文字以上）の位置を検討したもの

Android画面作成時の注意

Android画面を作成する場合、事前に開発担当者と方向性を決定しておいたほうが良さそうです。

何も確認がなされない場合、ラベル（ユーザーネーム）、プレースホルダー（例）やまだたろう）が存在する場合でも、ラベル名がインプットフィールドに入っている実装されるケースが頻繁に起こりえます。

Androidの標準ルールにおいて、プレースホルダーがそのテキストフィールドのラベル名を果たします。故に、意図の齟齬が起こりやすい箇所となります。

左のように意図しても右のように伝わってしまいやすい

項目の順番は何が正解か

アクセシビリティ的観点としてテキスト読み上げの順番なども考慮し、ラベル（ユーザーネーム）、文字の入力ルール（ex : 半角英数◯◯文字以上）の順番にするのも良さそうです。あえてプレースホルダーに例文（ex：例）やまだたろう）を置かないという形です。

パスワードを隠すUI

パスワード入力時、実際の英数字を伏せる表記「＊」「●」。このどちらを選ぶのかについてはその時々の文脈、ブラウザや入力フィールドのパスワード処理に任せるのが良いのではないか、という総論になりました。 また「＊」はワイルドカードとして、クレジットカードの番号を隠すために頻繁に使用されることもある、という認識をしておきます。

参考資料：

<input type="password">の項目

エラー文言

バリデーションエラーの振る舞いはどうするべきでしょう。最も考慮すべきは位置をどこするかですが、エラー文言が長い場合を考え下にするのが良さそうという総論になりました。 またエラー文言が出現した際に、テキストフィールドの位置がずれてしまう問題に関しては許容しようという認識合わせをしました。

ユーザーネームにエラーが出現するとパスワードのテキストフィールドは下にずれてしまうが、許容する

テキストエリア

「テキストエリア」は複数行テキストを入力する箇所とします。

文字数をオーバーしたとき

テキストエリアに入力できる文字は有限です。そこでユーザーに入力文字数のオーバーを知らせる振る舞いを考えます。

Twitterはリアルタイムに文字数を円で表現し、オーバーすると赤色の数字でオーバーした字数を警告する

しかし、どこまでもリッチに、というのは現実的に難しいケースも存在します。今回は基準として、「Submitを超えたときに警告を出す」としました。 またユーザーのリテラシー、使い方やその製品の文脈をテックリードと話し合うことも重要と認識を揃えました。

「Submit」ボタンを押したところでエラー判定する形を最低限の基準とした

プルダウンメニュー / ピッカー

「プルダウンメニュー（プルダウン、ドロップダウンメニュー）」「ピッカー」について対話しました。ここでは日程や時間などを選択する際に表示されるドラム形式の選択メニューとします。Androidはダイアログで表示され、iOSは項目を選択すると画面下から表示されます。

参考資料：

ios Human Interface Guidelines

「Pickers」

Material Design

「Date pickers」

「Pickers 」

過去の現場でどんなものを作った？

まずはチームメンバーが直近で作成したUIを持ち寄りました。

• Aさん 誕生日入力。iosピッカーを採用。
• Bさん 誕生日入力。カレンダーUIを採用。採用の理由は「ユーザーがやりやすそうだという結論が出たから」「実装との兼ね合いが大きかった」とのこと。
• Cさん 誕生日入力。ピッカーを採用。「1600年などを入れることはできないためある程度限定的にできる」「25〜30歳をターゲットなど初期値をそこに合わせて出した」

あるべき形とは

モバイル端末に置ける誕生日入力は半角英数が良いのではという意見がでたものの、それはリテラシーが高いユーザー向けなのでは、という議論にもなりました。

参考資料：

最速の生年月日入力フォームを求めて

総論としてはカレンダーよりもピッカー。リテラシーの高いユーザは半角入力が良いのでは、という形になりました。また年月日ごとにボックスを区切るのは避けよう、という認識をあわせました。

年月日はボックスを区切らないようにする

スイッチ / チェック / ラジオ

「スイッチ」は項目のオンオフを選択し、状態設定の切り替えを行うものです。iosのUIとなり、Androidではダイアログで処理されます。

チェックボタン（チェックボックス）は複数の回答の中から複数選択を許可するものです。

ラジオボタンは複数の回答の中から単一選択をするものです。

checkとradioは混同しやすいので、どういった役目を持つのか注意が必要です

複数選択の特殊なケースについてどうするか？

「すべてを選択できる」と「個別に選択できる」が共存するケースが存在します。

たとえば、このようにすべてを選択するとABCすべてを選ぶことが可能です

どのような形にするのが正解なのか対話しました。

「すべて」「全選択」を選択すると「月火水木金土日」が選択される。曜日は複数選択できる

こちらは実際に採用されたUIです。上記は曜日の個別選択が円形になっているのが特徴的です。チェックボックスを並べる形と比べて、選択しやすいUIに整理されています。

このように、特殊なケースは動線とセットでどういうふうに見せ方をするか、特にどんなラベルをつけるのか、について留意する必要がありそうです。

さいごに

以上、インプットの共通認識について確認しました。

ここでの総論は、あくまでも共通で使いやすい基準となるUIであり、確定した正解ではありません。

ユーザーにとって使いやすい形は状況、文脈ごとに提案する必要があります。上記を認識した上で、より良いものを選び取っていきたいです。