前回のおさらい

前回の「フローチャート」では、機能、すなわちやりたいことを順番に並べるお話をしました。必ずしもフローチャートの形式で作図する必要はなく、テキストで書き連ねてみることが大切です。今回の「ユーザインタフェース (UI)」は、ユーザとの対話をデザインするお話です。

UIを見る眼

みなさんは、普段からUIと接していると思います。スマホやパソコンはもちろん、テレビ、洗濯機、電子レンジ、ATM、コンビニの支払いなど、機械と接するときには、必ずUIが存在します。これらの中には、ほとんど意識せず快適に使えるものもあれば、一瞬考えないと使えないものもあります。ひどいときには考え込んでしまったり、イラっとすることもあるでしょう。

競争が激しいコンシューマ向けのUIは、よく考えて作られていることが多く、また少しでも不快感を与えてしまうとユーザは離れてしまうので、淘汰されてしまいます。一方で、公共のシステムや社内システムなど、使う人に選択肢がない場合、一般的にはひどいUIになりがちです。また、ひどいUIは著しく生産性を低下させる危険性があります。

たとえば、このようなメッセージが表示されたらどう感じるでしょう。不愉快ですよね。エラーコードなんて知らないし。ここまでひどいのは稀かも知れませんが、ユーザの知らない言葉や表現方法が使われると、コミュニケーションが成立しません。

次も有名なダメな例です。一瞬どちらを選んだらよいのか、迷いませんか？「取り消す」という言葉と「キャンセル」の意味が似ているので混乱を招きかねません。日常会話と同じく、誤解のないように、言葉を選ぶ必要があります。

こちらは、少し前に話題になったコンビニのコーヒーメーカーのインタフェースです。日本を代表するプロダクトデザイナーの佐藤可士和氏によるデザインです。おそらく誤操作が頻発したのでしょう、コンビニの方が貼ったと思われるシールが機械を埋め尽くしています。建築家の丹下健三氏は、「美しきもののみ機能的である」（『人間と建築』(1970)）とおっしゃっていますが、もはやその影もなくなっています。

http://kashi57move.blog.jp/archives/52205147.html

ありきたりの表現ですが、UIを作る時は、使う人の気持ちになって考えることが重要です。自分がひどいUIを使わされているときに感じる違和感や不満は、そのまま優れたUIを設計するヒントになります。これはソフトウェアや機械の操作のUIに限らず、資料作成やプレゼンテーションなどの情報提供の際に気を付けるべきことと同じです。すなわち、UIの設計で大切なことは、使ってくれる人とどうやってうまくコミュニケーションを取ればよいかを考えることに尽きます。

ユーザインタフェースってなに？

インタフェースとは、直訳すると「界面」です。使う人と、ソフトや機械との境界面です。昔は、マンマシンインタフェースなどという言葉も使われていました。

界面というと静的な印象を受けますが、実際には人間がソフトや機械に働きかけ、ソフトや機械が人間に働きかけるといった、動的な相互作用（インタラクション）です。ヒューマンインタラクション、ヒューマンコンピューターインタラクションなどという言葉もよく使われています。

このようなインタフェースやインタラクションを作り込むのは設計者やプログラマーの仕事ですが、非プログラマーであるあなたは、彼らに指示をしなければいけません。あなたはユーザがどのように対話するかをデザインしてください。

一方で、最近ユーザエクスペリエンス(UX)という言葉もよく耳にします。単に使いやすいUIだけではなく、ユーザの経験までデザインしよう、ということです。よく使われる例ですが、コーヒーが飲みたいという要求に対して、百数十円の缶コーヒーを提供することもあれば、帝国ホテルの1,650円のコーヒーを提供することもあるでしょう。その価格差に見合う経験をデザインしなさい、ということです。

UXは国際標準化されています（ISO9241-210, 2010）。このお話は奥が深いので、別の機会に譲ることにしますが、UXをデザインするにしても、基本的なUIができていることが大前提です。いくら帝国ホテルでも、頼んだものと全然違うものが出てきたら台無しですよね。

https://www.imperialhotel.co.jp/j/tokyo/restaurant/rendezvous/menu.html

もう一例だけ見てみましょう。あなたは東京の明日の天気が知りたいとします。パソコンかスマホで、天気予報サイトを開いて、地域や日時を入力すると、すぐに結果が画面に表示されるでしょう。一方で、Alexa、Googleアシスタント、Clova、Siriなどのスマートスピーカーや音声対話型ソフトを使って、「明日の東京の天気は？」と声を掛ければ、「晴れです」などの答えが返ってくるでしょう。

どちらの場合も、「知りたいこと＝天気、場所＝東京、日時＝明日」という情報を伝えると、該当する天気予報の情報を引っ張ってきて、結果を伝達する、という機能は同じです。ですが、自分でスマホで確認するのと、音声のやりとりだけで知るのとでは、ずいぶん経験が異なります。大げさに言えば、後者は人工知能と会話している気分になるかもしれません。

画面であれ、音声であれ、共通していることは、ユーザから情報を得て、何らかの処理をして、結果を伝える、ということです。つまり、天気予報の情報を持っているあなたと、ユーザとの対話です。

日常会話で使われる言語に文法があるように、UIにも基本的な考え方があります。ずいぶん昔からUIのバイブルとして親しまれてきたApple社のヒューマンインタフェースガイドラインには、この基本的な考えが詳しく記載されていました。また、流行の変化や技術の進歩によって、UIは常に変化しています。このガイドラインも常にアップデートされているようです。

https://www.amazon.co.jp/Human-Interface-Guidelines-Apple-Desktop/dp/4775303074
https://developer.apple.com/design/human-interface-guidelines/

まずは、UIの基本的な考え方をご紹介します。時代によって言い方や表現方法が変わっても文法や作法は変わらないのと同じように、流行りのUI表現があったとしても、基本的な考え方は変わりません。

対話をデザインする

UIの目的は、

　１．ユーザから情報を得る
　２．ユーザに情報を知らせる
　３．ユーザに行動を促す

の３つです。

インターネットで何か検索したいとき、検索ワード入力画面が１で、検索結果画面が２の役割を担います。最近では、ブラウザのアドレスを入力する場所に、直接検索ワードを入力することも増え、１の実体がなくなりつつありますね。

また、２の検索結果画面には、たくさんのテキストリンクが含まれています。これをクリックすれば、そのページに飛んでくれるというものです。つまり、検索結果画面そのものが、ユーザがどのリンクを選ぶか、といった新たな情報を得るための１の機能になっているというわけです。また、３つ目は１つ目と区別しにくかったり、必ずしも必要ではない場合もあります。１と２のやり取りの途中で広告が表示されていて、ユーザの目に触れるだけで目的が達成されている場合などがあります。

日常会話風に書くと、こんな感じになるかもしれません。

検索サイト：「何をお探しですか？」（テキストボックス）
ユーザ　　：「〇〇に関連するサイトが知りたい」（テキストを入力）
検索サイト：「このようなサイトがあります。どれが関係しそうですか？」（テキストリンク付き結果）
ユーザ　　：「◇◇ですね」（テキストリンクをクリック）

UIの設計は、ユーザとの対話をデザインしていることと同じです。日常会話と同じように、少なくともユーザに不快な思いをさせないことが重要です。

では、どのようにすればよい対話をデザインできるでしょうか。ユーザに余計なことを考えさせない、余計な情報を伝えない、その上で、必要な情報を入力してもらうように心がけます。

余計なことを考えさせないとは、迷わせない、探させない、無駄な操作をさせない、ということです。

余計な情報を伝えないとは、必ずしも必要ではない情報は最初は隠しておいて、クリックしてはじめて見えるようする、ということです。見たい人だけが見られるように、設定したい人だけが設定できるようにしておく。これは、日常会話では、聞かれてからはじめて答える、ということと同じです。必要な情報を入力してもらうために、大事なことから聞くようにして、ユーザのストレスを最小限にしましょう。

　まずは一般的なGUI（グラフィカルユーザインタフェース）の基本をお話したいと思います。

GUIの基本文法（アイテム）

１と３のユーザから情報を得る、行動を促すためのアイテムには、チェックボックス、ラジオボタン、プルダウンメニュー、テキストボックス、ボタン、などがあります。一方、２のユーザに情報を伝えるためには、テキスト（文字、表）、画像（写真、グラフ）などが主で、場合によっては動画や音も使われます。また、マウスカーソルなどを移動したときにポップアップされるツールチップなども、機能を説明する手段として定着しました。ここでは、主に１と３で使われるアイテムについてお話します。

チェックボックスは、複数の候補から選択するためのアイテムです。チェックボックスは、複数選んでもよいときに使います。何も選択しない、ということも可能です。文章を選んでもらう場合は、できれば肯定文で書くことをお勧めします。

長年、チェックボックスは文字通り「✓」記号が使われてきましたが、最近はスライドしてオンオフするトグルスイッチも一般的になってきましたね。他にもトグルボタンがあります。細かいことを言えば、これらは使い分けるべきですが、これはまたの機会にします。

これに対して、かならず１つだけ選んでほしいときは、ラジオボタンを使います。選択肢は漏れ、ダブりのないMECEになっていると、ユーザは選択しやすくなります。機能はメニューと同じですが、候補のすべてを画面に表示するため一覧性は良いものの、画面の広い部分を占有してしまいます。可能であれば、選択肢を整理するとわかりやすくなります。例えば、青、赤、黄色の帽子、靴、カバンを選んでもらいたいとき、下図の上段のように組み合わせを羅列することもできますが、下段のように色と商品の種類を選んでもらうようにすれば、面積を節約できます。

メニューもひとつだけ選択する場合に使います。選択された項目だけが表示されるので、画面の占有面積を節約することができます。ただし、ラジオボタンは１回のクリックだけで選択できるのに対して、メニューはメニュー選択→項目選択の少なくとも２回の操作が必要になります。各項目の左に「✓」を付けることによって複数選択も可能ですが、操作数が増えるので、あまりお勧めしません。ラジオボタンと同様に、長々と選択項目が増えてしまう場合は、ある程度整理して、ユーザの負荷を下げる工夫が必要です。

ボタンは、ユーザになんらかの判断をしていただき、次に進むアイテムです。購入などの意思決定を促すこともある重要なものです。同様の機能に、URLなどが紐づけられたテキストリンクや、地図などの画像上の位置を選択するクリッカブルマップなどがあります。

テキストボックスは、数値や文字などのテキスト情報をユーザに入力してもらうアイテムです。最もユーザに負担をかけることを心に留めておきましょう。ソフトウェア側で調べればわかるような情報や、とりあえず収集しておこうといったような入力は、ユーザはすぐに勘づいて嫌な気分にさせてしまいます。また、期待する入力に応じて、テキストボックスの大きさを決めることも大切です。そうすれば、この入力で合ってるんだなといった安心感をユーザに与えることができます。

UIもテキストで記述できる

機能ブロック図やフローチャートも文章で表現できるのと同様に、UIもテキストで書くことができます。架空のセミナーに参加登録するモバイルアプリを例にご紹介します。このセミナーは３日開催され、事前に資料をメールで受け取ることができます。そのため、個人情報を扱うのでポリシーに同意していただく必要があります。

これをテキストで書いてみると、こうなります。何度も繰り返しますが、UIとは対話です。伝えたいことと、聞きたいことをイメージしながら設計してください。

情報の提示
① セミナーのご案内メッセージ（テキスト）
② 利用規約へのリンク（テキストリンク）

ユーザに選択・入力してもらう
③ 日時を選択（プルダウンメニュー）
④ 資料の事前送付の希望（ラジオボタン）
⑤ メールアドレスを入力（テキストボックス）
⑥ 個人情報の取扱の同意（チェックボックス）
⑦ 上記入力後、申し込み確定（ボタン）

パワーポイントなどを使って実際にレイアウトを含めて作成することもできますが、テキストだけでもUIをデザインするための情報としては十分です。それでは、次の課題で実際にやってみましょう。

課題

あなたは標準価格が数百万円の商品A、B、Cを販売しています。それぞれに共通の有料オプションP、Q、R、S、Tがあります。ユーザが希望する組み合わせの見積りを提示するWebサイトのUIを設計してください。

１ページで収まっても、複数のページに遷移してもかまいません。パワーポイントなどで作図しても、テキストで表現しても結構です。時間は７分です。

＊　＊　＊

　シンプルな課題ですが、いくつものUIの設計案が考えられます。

（１）まずは、素直な設計例をご紹介します。１ページ目に、下記の３種類のアイテムを配置します。

・製品A, B, Cを選択（ラジオボタン）
・オプションP, Q, R, S, Tを選択（チェックボックス）
・「概算見積り」ボタン

概算見積りボタンが押されたら、２ページ目に選択された製品とオプションの内容、概算見積もり価格をテキストを表示します。つまり、１ページ目はUIの目的の「１．ユーザから情報を得る」、２ページ目は「２．ユーザに情報を伝える」に相当します。

（１‘）これで課題には対応できてはいるのですが、もしかしたら営業サイドからは、せっかくアクセスしてくれた顧客の情報がほしい、正式な見積りを提案したい、という要望があるかもしれません。１ページ目は（１）と同じで、２ページ目に下記を追加すれは、ユーザから情報を得ることができるかもしれません。

・会社名、メールアドレス入力（テキストボックス）
・「正式見積り」ボタン

つまり、２ページ目は、「２．ユーザに情報を伝える」と同時に「１．ユーザから情報を得る」という機能を兼ねていることになります。ただし、場合によっては身元を明らかにしたくないユーザもいるかもしれませんので、そのあたりは注意が必要です。

（２）次に、一問一答形式の例をご紹介します。ウィザードと呼ばれ、最初に登場したのは1991年だそうです。

まず１ページ目で、製品を選択してもらい、「次」ボタンで次のページに進みます。

・製品A, B, Cを選択（ラジオボタン）
・「次」ボタン

　２ページ目でオプションを選択してもらいます。

・オプションP, Q, R, S, Tを選択（チェックボックス）
・「次」ボタン

　３ページ目で概算見積りと、正式見積りに誘導するボタンを配置します。

・選択された製品、オプション、概算見積り価格をテキスト表示
・「正式見積りへ」ボタン

　４ページ目で、正式見積りを送付する必要情報を入力してもらいます。

・会社名、メールアドレス入力（テキストボックス）
・「正式見積り」ボタン

ウィザードは、丁寧すぎてまどろっこしい印象もありますが、複雑なプロセスを順を追って進めるときには効果的です。特急券の券売機などがこの例と言えるかもしれません。

ウィザードで気を付けなければいけない点が「終わりが見えない」ことです。たとえば全部で10ページあるうちの7ページ目です、といった7/10などの表記を使って、あとどのくらい進まなければいけないのかをユーザに知らせることで、ずいぶん心理的負荷が軽減されると思います。

（３）次は、ウィザードとは逆に、すべてを１つのページで済ませる例です。ユーザが入力する度に、ページを更新する方法です。

まず、ページ上部には、製品とオプションを選択するアイテムが配置されています。

・製品A, B, Cを選択（ラジオボタン）
・オプションP, Q, R, S, Tを選択（チェックボックス）

これらが選択されると、その下部に概算見積りや、正式見積りのための情報を入力するアイテムが表示されます。また、上部の選択が変更された場合も、概算見積りの情報が更新されます。

（３‘）課題には、製品やオプションの選択は、複数同時に選択できるかどうかは記載されていませんでした。これまでの例は製品は１つだけ選ぶ、オプションは複数選ぶという前提で、それぞれラジオボタン、チェックボックスが使われています。これはプログラマーは知らないことですので、非プログラマーであるみなさんが言語化して伝える必要があります。

製品とオプションは、１つしか選べないのであれば、メニューに変えても同じです。

（３‘’）一方、製品、オプションが複数選択できる場合、それぞれをチェックボックスにしてもよいのですが、製品AにはオプションQとS、製品Bにはオプションなし、といった個別の設定ができません。

このような場合、下記のようにマトリクス状にすれば解決できます。ただし、チェックする箇所が増えて、画面の占有面積が増えるので、あまりお勧めできません。それより、製品は１つしか選択できないままにしておいて、「製品の追加」のように必要に応じて項目を増やしていくのが良いかもしれません。

まとめ

ユーザインタフェースは、あなたとユーザとの対話(dialogue)です。独り言(monologue)であってはいけません。対話には人間性が出ます。最低でも不愉快にさせないように配慮しましょう。ユーザがUIを使うとき、相当の心理的・認知的負荷がかかっています。これらを最小限にすることが重要です。例えば、ユーザが知らない言葉は使わず、判断を迷わせない、違和感を感じさせないように気を付けましょう。かといって、くどくど説明するのもよくありません。パワーポイントのスライド作成のノウハウなども応用できると思います。視線の流れや色使い、言葉遣いなど、参考になる点がたくさんあります。奇をてらわないこと、普通が一番です。般若心経の遠離一切顛倒夢想ですね。

これまで３回にわたってお話してきた「機能ブロック図」「フローチャート」「ユーザインタフェース」はプログラミングの基本要素です。また、特許の明細書の図で用いられる代表的な図でもあります。ぜひこれらを整理してプログラマーの方に伝えて、あなたの思い通りのソフトウェアを作ってください。