はじめに

本記事は筆者が制作したアプリの概要とともにそのUI設計の考え方について書いたものです。

特にUIの設計について考え方を述べた部分はUI設計初心者の方にとって役立つ可能性があります。例えば（デザイン文脈での）「アフォーダンス」「シグニファイア」などという語を聞いたことがない方はそれなりに多くの新しい知見が手に入る可能性が高い記事となっています。

本記事に記載のあるUIの設計に関する知見は基本的に『誰のためのデザイン？増補・改訂版認知科学者のデザイン原論』にて学ぶことができます。筆者は本書で得た知識をアプリケーションのUI設計に利用しましたが、本書ではプロダクトデザイン一般について述べられており得られる知見の適用範囲はかなり広くさまざまな場面で役に立つと考えられます。

「これはすごい！」と思わずハッとするようなデザインから「なんでそんな馬鹿げたデザインになってしまったのか、、、」というデザインまで豊富な例が紹介されており、読んでいてとても楽しい本でもあります。

本記事での『UIの設計』の章では、『誰のためのデザイン』に登場した4つの原則（概念・考え方）「アフォーダンスとシグニファイア」「対応づけ」「制約」についてどのようにアプリのUI設計に適用したのかなどについて詳しく述べています。

本記事がUI設計のさらなる学習への導線になれば幸いです。（UI設計にのみ関心のある方は『UIの設計』の章まで読み飛ばすことをおすすめします。）

LLog概要

LLogのロゴ

LLogとは筆者が個人的に開発している学習進捗管理アプリです。 LLogという名前は「学習記録」を意味する"Learning Log"を略して名付けられた名前です。

基本的な機能やプロトタイプ版のインストールの仕方や使い方については以下のレポジトリの READMEにて説明しておりますが、本記事でも説明をしていくつもりです。

LLogのレポジトリ

https://github.com/awyaki/llog

アプリ作成に至った経緯

まず、筆者自身が「学習したことをタイミングよく繰り返し復習すること」が苦手であるという課題を抱えていました。筆者はかなり好奇心が旺盛でいろんなことを並行して勉強してしまう傾向にあります。特に一度勉強したことを復習するよりかは自分にとって新しい知見を得ることが楽しく優先してしまいがちです。「これではよほど記憶力がよくない限り勉強したことがなかなか定着しない」ということは日々感じていました。特に試験などという強制的に復習を促すシステムがない独学ではなかなか復習をする時間をとりづらいということがありました。

そこでこのような復習をすることに関する自身の課題感から『独学大全』という書籍を購入し、なにか参考になる方法はないかを探しました。

そこで出会ったのが「ラーニングログ」という方法でした。『独学大全』の中ではラーニングログは「手帳などに勉強範囲に対応するブロックを書き、勉強したらそのブロックを塗りつぶしていく」という方法で学習の進捗を記録し、その道のりを振り返るのに活用するというものでした。

この方法に出会ったとき「この方法で学習することをアプリでサポートできないか」と思い至りました。アプリで「ラーニングログ」を作れば学習を記録すると同時に「記録から復習のタイミングを自動で計算し知らせる」ということもできより強力に学習をサポートできるのではないかと考えました。以上がLLogを作成するに至った経緯です。

主な機能と基本的な使い方

現在LLogには主に次のような機能が実装されています。

学習の進捗を管理する機能
学習したことをマークダウン形式で記録するための機能
自分が学んだことをいつ復習するべきなのかを知らせる機能
コンテンツ、ノート、ログを複数条件で検索できる機能

以下ではLLogを使用するための一連のワークフローと共に用語の解説をしていきます。

1. コンテンツを作成する

「コンテンツ」はLLog内で学習の進捗を管理するための最も大きな単位です。基本的には一つの書籍を一つのコンテンツに対応させることで書籍の学習状況を管理するという使い方が想定されています。（必ずしも書籍である必要はありません。ネット記事などをコンテンツとして管理しても問題ありません。）

例えば筆者は最近『プロを目指す人のためのTypeScript入門』という書籍を購入したので、 LLogを使ってこの書籍で学んだことを記録していきたいと考えました。このように考えたタイミングがコンテンツ作成のタイミングです。

コンテンツ作成UI

上の画像のようにコンテンツを作成する際には「コンテンツのタイトル」と「作成するブロック数」を入力することが求められます。

ここで「ブロック」とはLLogにおいて学習の進捗を管理するための最も小さな単位であり、コンテンツを書籍に対応させた場合はページに対応させる使い方ができます。例えば『プロを目指す人のためのTypeScript入門』は合計で411ページありますので 411ブロック作成します。ページとブロックを一対一で対応させることで1から10ページ学習したときには「1から10ブロック学習した」ということを LLogに記録することができます。もちろん対応関係をページにする必要はありません。ページに対応させる他にも「章を1ブロックに対応させる」という使い方もできます。

以下の画像はブロックを俯瞰で見るための画面のスクリーンショットです。ブロック24、25、26以外のブロックの色は「取り組んでいないこと」を表しているのでほとんど勉強が進んでいなことがわかります。

ブロックを俯瞰してみるためのUIの画像

2. ノートを作成する

コンテンツを作成すると下の画像のようなUIを使用してノートを取ることができるようになります。このノートはマークダウン形式で記述できます。ノートはブロックと結びつけることができ「どの範囲を勉強したのか」という情報を持たせることができます。

ノート作成画面の画像

3. ログを作成する

ノートを取るとそのノートの内容をもとに「ログ」を作成することができるようになります。ログを作成することでLLogの学習進捗管理機能を最大限生かすことができます。ログは「学習の記録」であり「学習した範囲・内容と共にその学習をいつ行ったかを記録するもの」です。

ログ作成画面の画像

ログを作成すると元となったノートに登録されているブロックの「レベル」が最大の5に変更されます。ブロックのレベルは0から5の6段階ありレベルがあがるほど「そのブロックに対応する内容を記憶している可能性が高いこと」を示しています。

ログの作成はノートを取った直後に行うものなのでその内容を記憶している可能性は高いはずですからログの作成直後にはブロックのレベルが最大になるということです。

4. ログを使って復習をする

Logsページでは今まで作成した全てのログを見ることができます。このページではログとそのログのブロックのレベルを俯瞰して見ることができるようになっています。ログ作成時にはレベルが5だったブロックは時間経過とともにレベルが下がるようになっており、「レベルが低いブロックを持つログの内容は復習を優先的に行うべきである」ということを意味しています。

このページでどのログを復習すべきかを確認したらそのログの内容を復習します。ここでポイントなのはログから新しいログを作成することができるということです。ログの内容を復習してログ作成ボタンを押すと同じ内容でログが作成されブロックのレベルは最大になります。

Logsページの画像

なおブロックのレベルの下がり方は「そのブロックを何回学習したか（そのブロックを含むログを何回作成したか）」に依存しています。 1回だけしか取り組んでいないブロックはレベル5から1に下がるのに1日しかかかりませんが、 2回取り組んだブロックはレベル1まで下がるのに3日かかります。取り組み回数が増えるほどレベルが下がるまでの時間が長くなるという仕組みです。（レベル0は「まだ取り組んでいない」という意味なのでレベルが下がるのは1までになります。）

基本的にログを中心に使うことで学んだことを復習していくような使い方になるかと思います。

以上がLLogの大まかな使い方の説明です。

使用した技術

主に使用した技術は以下の通りです。ここではなぜその技術を採用したのかという視点で振り返っていきます。

Electron

アプリ開発の時点でそれなりに使用できる技術スタックとしてHTML、CSS、TypeScript、Reactがありました。 ElectronではChromiumとNode.jsの環境でデスクトップアプリが開発できるため自分の技術スタックでアプリを開発するにはちょうどよい選択肢でした。 LLogの使われ方から考えると基本的にはオフラインで使用できた方が良いと考えデスクトップアプリで開発することにしました。

TypeScript

初めからTypeScriptを使おうと考えていました。

TypeScriptはいわば静的型システムを備えたJavaScriptです。型によるチェックである程度未然にランタイムエラーを回避することができる点、テキストエディタの補完機能などサポートが手厚い点、コミュニティが活発で記事が豊富なので初心者として学びやすい点、公式ドキュメントがしっかり作り込まれており学びやすい点などがTypeScriptを採用する利点として考えられます。

React

ReactはUIを値として扱い宣言的にUIを記述することができるJavaScriptのライブラリです。「宣言的である」ことでUIを作る際に「どうやってそのUIを作り上げるか」については考える必要がなく、「どんなUIであるのか」ということに集中してアプリを作ることができます。「何であるか」をコードに記述するためコードの文書化が促進され可読性が上がるというような利点もあります。また、他にも宣言的なUIライブラリは存在しますがReactはいわゆるJSファーストと言われるような立場であり、特殊な記法を覚える必要がなくJavaScriptというプログラミング言語の柔軟性をそのまま利用できる点で優れていると考えられます。

Zenn Markdown Html

マークダウンをHTMLに変換するためのライブラリとしてはremarkやmarkdown-itなどがありますが「いい感じ」の出力にするには手間がかかるため今回はZenn Markdown Htmlを利用しました。スタイリングにzenn-content-cssを使うことでZennの記事の美しいデザインでノートを表現できるためたいへん気に入っています。

もちろんLLogに最適化されたデザインというわけではないため少しずつLLogに合わせたスタイルに変更していくつもりです。

React Ace

ある程度整ったエディタを提供してくれるライブラリです。 CodeMirrorを使おうかと思いましたがカスタマイズに時間がかかり過ぎてしまうと思ったのでReact Aceを利用することにしました。

Prisma

データモデルを記述してターゲットのデータベースを設定するとそのデータモデルとデータベースに合わせたデータベース操作関数や型情報を生成してくれる非常に便利なライブラリです。 SQL文は一通り勉強したことがありますが本格的にデータベースを触ったことはなかったのでデータベース周りのことは全てPrismaに丸投げすることにしました。

SQLite3

オフラインでの使用がメインなのでSQLite3を採用しました。

UIの設計

UIの設計では主に「アフォーダンスとシグニファイア」「対応づけ」「制約」を意識しながら設計を行いました。これらの原則（概念）は筆者が主に『誰のためのデザイン？』から学んだ知識ですが、抽象的な原則であるからこそ適用できる範囲も広く UIを設計する際の強力な指針となってくれました。

もちろんこれらは原則であるので「本当にユーザーにとって使いやすいかどうか」という指針に対して優先されるべきものではありませんし、このような学術的な用語で整理せずともセンスでどうにかなることもあるでしょう。またこのような用語を並べ立てることには衒学的だと感じる方もいるかもしれません。しかしこれらの原則はその道の専門家がデザインについて研究していく中で導き出した原則（重要な概念）であり適用するかどうかには一考の価値があります。

以下では各原則（概念）の簡単な説明とLLogでの適用例の紹介をしていきます。

なお「アフォーダンス、シグニファイアという語はデザイン分野とは別の分野からの輸入であり本来の意味とは少し異なる」といったような趣旨のことが『誰のためのデザイン？』で言及されていますのでご注意ください。

アフォーダンスとシグニファイア

アフォーダンスとシグニファイアはそれぞれ異なる概念ですが非常に密接な関係があります。

まず「アフォーダンス」ですがこれは「人（本来は動物でも何でもよいがここでは分かりやすく「主体」を人とする）があるものに対してある操作（動作）が可能かどうか」ということを意味します。例えば、ある人があるコップを持つことができるとき「そのコップはその人が持つことに関してアフォーダンスを持つ」ということになります。ここで注意したいのはアフォーダンスとは人とものとの相互作用を表す言葉であるということです。

つまり先の例では「ある人とあるコップの相互作用によって、その人がそのコップを持つことができるというアフォーダンスがある」ということです。例えば、もしある人が幼い子供だとすればコップが大きければそのコップを持つことができないかもしれません。人とものの間の相互作用が変わればそこに生じるアフォーダンスも変化するのです。このような状況では「そのコップはその子供に対して持つことができるというアフォーダンスを持たない」などと言うことができます。

さて「人がものに対して何ができるのか」ということを表す概念が「アフォーダンス」ですが、この概念を使って考えると面白い例が一つあります。それは「隠し扉」です。隠し扉はおそらく秘密の通路と繋がっていたり、重要なものを隠したりするために作られるものだと考えられますが、扉である以上人（特にその隠し扉の使用者）に対して「開くことができる」「通ることができる」といったアフォーダンスが必要です。しかしながら隠し扉が持つアフォーダンスは本来の使用者以外に発見される訳にはいきません。だからこそ隠し扉は扉のアフォーダンスをさまざまな方法で隠します。ここでポイントなのは「隠し扉は「開くことができる」「通ることができる」というアフォーダンスを持ちながらもそれらアフォーダンスの存在を発見できない状況になっている」というところです。

隠し扉は意図的にアフォーダンスの存在を隠していましたが、実はデザイン上問題のあるものには「意図せずアフォーダンスが発見できなくなっているもの」があったりします。

例えば「ドアノブがついているスライド式のドア」は「横に引いて開けることができる」というアフォーダンスの存在を示すものがなく、むしろドアノブが「手前に引いて開けることができる」というアフォーダンスの存在を示しておりこの扉は使用者が誤った使い方をする可能性が高いでしょう。

さて、ここで重要になってくる概念が「シグニファイア」です。シグニファイアはアフォーダンスがあることを示すものでありユーザーがアフォーダンスを発見することをサポートしたりどんなアフォーダンスがあるのかを説明するものです。

例えば扉などではそのもの自体の境界や蝶番、ドアノブといった構成要素が「開け閉め可能」といったアフォーダンスの存在を示しており「シグニファイア」の役目を負っていると言えるでしょう。またドアノブの存在は「引いて開ける」ことの説明にもなっています。適切なシグニファイアがあることで初めてユーザーはそのものの使い方を理解することができます。

ここまで「アフォーダンスとシグニファイア」について簡単に説明してきました。

アフォーダンスがあるだけでは人はそのアフォーダンスを生かせないこと
アフォーダンスを発見してもらうためにシグニファイアが適切かどうかに注意するべきであること

などを理解していただけたかと思います。

LLogにおける「アフォーダンスとシグニファイア」

アフォーダンスとシグニファイアはUIを作る上でも基礎となる概念です。本当に基礎的な概念であるからこそ「よくある普通のデザイン」として普及しているデザインを真似るとほとんどの場合アフォーダンスに対して適切なシグニファイアを与えることに成功しています。

例えばLLogでは「何気なし」に実装されているボタンには基本的に「Add new」「Write」「Home」などの文字がつけられておりそれらのラベルの文字はボタンを押すとどうなるかを示すシグニファイアとなっています。また下の画像のボタンの場合は「アプリの最上部に位置していること」からも「メニューのボタンである」ことがある程度予測可能になっています。

LLogで使用されているボタンの画像

なお、上の画像のボタンにはありませんが「ボタンのボーダー」や「ボタン自体が背景と異なる色で塗りつぶされていること」などもボタンの「クリックすることができる」というアフォーダンスに対するシグニファイアです。

シグニファイアは「アフォーダンス」の存在を示すものです。したがってユーザーがプロダクトをうまく扱える（アフォーダンスを利用できる）ようにするには、「ユーザーがシグニファイアを適切に受け取れるかどうか」に注意を払ってUIを設計する必要があるでしょう。例えば背景とボタンの色のコントラストが小さいとユーザー自身やユーザーのいる環境によってはボタンを認識できずアクセシビリティの低いデザインになってしまいます。このようにシグニファイアはアクセシビリティを考える上で特に役に立つ視点だと考えられます。

対応づけ

デザインにおける「対応づけ」とは「ある操作部をどう操作すれば何がどう動くか」という対応関係を認識させるような仕組みのことです。

対応づけに関しては「キッチンのコンロ（複数箇所で点火できるもの）」を例にとると分かりやすいでしょう。良い対応づけのデザインがなされているコンロでは各点火場所の空間的位置関係と同じ位置関係を保って各点火スイッチが配置されています。これはコンロの点火場所とそれに対応するスイッチの空間的位置関係を「対応づけ」した例ですが、この対応づけによってユーザーは「どのスイッチでどの点火場所を制御するのか」を直感的に理解することができます。

一方でキッチンコンロの良くない対応づけの例では「コンロは横に並んでいるが各スイッチは縦に並んでいる」流石にないとは思いますが最悪なのは「コンロが横に並んでおり各スイッチも横に並んでいるが各コンロの位置関係と各スイッチの位置関係が逆」の場合などが考えられます。このようなデザインは直感的に理解しにくくたとえ一度操作したことがあったとしてもユーザーは混乱し操作を間違える可能性が高くなると考えられます。

LLogにおける「対応づけ」

LLogで対応づけを特に意識して実装されている部分はログ検索UIにあるブロックレベルによる検索UI です。

ブロックレベルによるログ検索UI。1または3のレベルのブロックが含まれるログを検索している状態である。

このUIはログが持っているブロックのレベルによりログを検索する機能を提供します。つまり「レベル1のブロックを持っているログ」や「レベル1と3のブロックを持っているログ」というような検索をするためのUIです。このUIでは上の画像の通りUIが上下のエリアに分断されており、ブロックをクリックするとそのブロックが上下エリアを行き来するようになっています。上の画像の状態では「レベル1またはレベル3のブロックが含まれているログを検索結果に表示する」ということを意味していることになります。ここでこのUIでは「あるレベルを表すブロックが上のエリア内に存在しているときそのブロックのレベルを含むログが検索結果が表示される」という対応づけがされています。少なくとも一回操作しさえすればこの対応づけに毎回混乱するようなことはないはずです。（そうとも言い切れないかもしれませんが。）

制約

「制約」はユーザーが誤って操作をすることを未然に防いだり、ユーザーに必ずある操作を行うように仕向けたりする際に使用される強力なデザイン手法です。制約では文字通りものに対するユーザーが取りうる操作の選択肢に対して制約をかけます。

「制約」の身近な例としてはアプリを初めて利用するときに出てくる「利用規約へ同意したかどうかを確認するUI」でしょう。このUIではその画面から先に進むための条件として「利用規約を全て読んだ（規約を一番下までスクロールした）上で「利用規約に同意する」の欄にチェックしなければならない」といった条件を課しています。これによってユーザーはそのアプリを利用する際に必ず利用規約へ同意することを強制されることになります。（この方法では「利用規約を理解する」ことを強制できないのはある意味問題ではあります。）

また少し変わった例として「台風が近づいてきたとき自転車が勢いよく倒れて壊れないように事前に倒しておく」というような例もある意味「制約」によってエラーを防ぐ一つの事例とも言えるでしょう。この場合は「台風の風が持つ自転車に対する「（勢いよく）倒すことができる」というアフォーダンスに制約をかけた」ということができます。

またプログラミングをする人にとって実は「制約」は馴染み深いものです。構造化プログラミング、オブジェクト指向プログラミング、関数型プログラミングなど様々なプログラミングパラダイムがありますがそれらに関してRobert C.Martinは『Clean Architecture』において以下のように述べています。

構造化プログラミングは、直接的な制御の移行に規律を課すものである。

オブジェクト指向プログラミングは、間接的な制御の移行に規律を課すものである。

関数型プログラミングは、代入に規律を課すものである。

これら3つパラダイムは、我々から何かを奪っている。それぞれがコードの書き方に何らかの制限をかけている。（Robert C.Martin 著, 角征典, 髙木正弘訳『Clean Architecture : 達人に学ぶソフトウェアの構造と設計』ドワンゴ, 2018.7）

ここでは込み入った話をすることはありませんがプログラミングの研究者たちは適切な「制約」を課すことによってより安全なプログラミング手法を編み出そうとしてきたということを読み取ることができます。

なお、筆者はTypeScriptが大好きですがそれは静的型システムによる「制約」のデザインが素晴らしいと感じるからです。

LLogにおける「制約」

すでに説明したようにLLogでは「ログ」を作ることで学んだことを管理することになります。そこでログを作成する際「ユーザーに「何を学んだのかについての短い要約（タイトル）」を付けさせることによって記憶の定着を促進することができるのではないか」と考えました。

このときユーザーにログの要約を付けることを強制するために「制約」のデザインを取り入れることにしました。具体的にはログ作成ボタンを押すと以下の画像のようにログの要約を入力するモーダルが出現し、要約を入力してからでないとログを作成できないようにしました。

ログ作成画面

UI設計まとめ

ここまでLLogのUI設計に関して説明してきました。正直なところ「大そうな用語を使って説明してた割によく見る普通デザインだな」と思われるかもしれません。実際、筆者が考えたUIのデザインというのは工夫はあっても奇抜さのかけらもないものです。

しかし筆者は「奇抜さや斬新さがないことはUIにとってある程度重要である」と考えています。なぜならばUIが奇抜すぎるとユーザーにとって予測不可能になるからです。予測不可能なUIは使いにくいと感じられやすくユーザーの体験としてよいものであるとは考えられません。

もちろんこれは斬新なUIがすべて良くないと主張するものではありません。たとえ今まで見たことがない斬新なUIでも「ユーザーが使い方を理解する糸口」が工夫されているUIは良いUIだと言えるでしょう。

最後に

ここまで主にUIの設計に関して述べてきました。本記事の「はじめに」でもお話ししたようにこれらUI設計の知見は筆者が『誰のためのデザイン？増補・改訂版認知科学者のデザイン原論』で得た知見です。デザインに関して（特に「認知科学とデザイン」に関して）初めて勉強するという方には興味深い知見が得られると思いますのでとてもおすすめです。ここまで読んでくださりありがとうございました。

LLogとそのUI設計