はじめに

前回の記事では、

SLXの内部名称を

Collection
 └ Genre
     └ Title
         └ Item

から、

Collection
 └ Folder
     └ Category
         └ Title

へ変更した理由について書きました。

名前は変わりました。

役割も整理できました。

でも、

それだけでは、

利用者にとって使いやすいアプリになったわけではありません。

むしろ、

ここから新しい悩みが始まりました。

内部構造は、

本当に利用者へ見せる必要があるのでしょうか。

私はまた、

同じところで立ち止まりました。

構造は残したい

正直なところ、

4階層という構造は減らしたくありませんでした。

Collection
 └ Folder
     └ Category
         └ Title

開発を続けるほど、

この構造には意味があると感じるようになっていました。

将来、

機能が増えても対応しやすい。

検索もしやすい。

バックアップもしやすい。

内部には、

しっかりした構造が必要でした。

だから、

データ構造を単純にすることは考えませんでした。

でも、利用者は違いました

利用者は、

Folderを使いたいわけではありません。

Categoryを理解したいわけでもありません。

やりたいことは、

物を登録すること。

必要な時に見つけられること。

それだけです。

そう考えた時、

あることに気付きました。

開発者が必要とする構造と、利用者が求める体験は同じではありませんでした。

そこで考え方を変えました

それまでは、

内部構造から画面を考えていました。

4階層だから、

画面も4階層。

データ構造がこうだから、

操作もこうなる。

そんな考え方でした。

でも逆でした。

利用者は何をしたいのか。

どこで迷うのか。

どこで止まるのか。

そこから画面を考える。

最後に、

その画面を支えられるように、

内部構造を設計する。

いつの間にか、

設計する順番そのものが変わっていました。

登録と整理を分けました

この考え方から生まれたのが、

登録と整理を分けるという考え方でした。

登録するときは、

分類まで決めなくてもいい。

まず登録する。

必要になったら整理する。

登録
 ↓
あとで整理
 ↓
必要なら分類

内部では、

すべて4階層の中へ保存されています。

でも、

利用者にそのことを意識してもらう必要はありません。

利用者には、

「登録できた」

という体験だけを提供する。

それが、

私の目指したかった設計でした。

「分類なし」は構造を隠す仕組みでした

以前の記事で、

「分類なし」

という考え方について書きました。

当時は、

登録先を決められない時の受け皿だと思っていました。

でも、

振り返ると違いました。

「分類なし」は、

利用者が内部構造を意識しなくても登録できるようにするための仕組みでした。

画面では、

ただ登録しただけ。

でも、

内部では正しい構造へ保存されている。

利用者には、

構造ではなく体験を見せる。

そんな考え方が、

少しずつ形になっていきました。

パンくずは残しました

だったら、

階層は全部隠せばいい。

そう考えたこともあります。

でも、

全部隠してしまうと、

今どこにいるのか分からなくなります。

だから、

操作の中心にはしない。

でも、

必要な時には分かるようにする。

そのために残したのが、

パンくずリストでした。

構造を押し付けるのではなく、

必要な情報として見せる。

それが、

今のSLXの考え方です。

この頃から言葉になりました

以前の記事で、

私は、

データ構造は強く、利用体験はシンプルに。

という言葉にたどり着いたと書きました。

でも、

この言葉は最初から考えていたものではありません。

「分類なし」

「あとで整理」

「パンくず」

「名前のリファクタリング」

一つひとつ積み重ねた結果、

振り返ると、

全部同じことを考えていました。

利用者には、

できるだけ考えさせない。

でも、

内部では強い構造を持たせる。

片方を選ぶために、

もう片方を諦める必要はありませんでした。

内部構造は強く。

利用体験はシンプルに。

この考え方が、

少しずつSLXの軸になっていきました。

おわりに

以前の私は、

シンプルなアプリを作るには、

シンプルなデータ構造が必要だと思っていました。

でも今は少し違います。

作りたいのは、

シンプルなデータ構造ではありません。

シンプルに感じられる利用体験です。

内部では、

4階層を維持する。

利用者には、

必要な操作だけを見せる。

その二つは、

矛盾するものではありませんでした。

構造を強くすることで、

利用者には自由でシンプルな体験を提供できる。

それが、

私なりに

データ構造は強く、利用体験はシンプルに。

という考え方を、

実際の設計へ落とし込んだ答えでした。

前回の記事

「名前も設計の一部だと気づいた話」

シリーズ

このシリーズでは、個人開発しているコレクション管理アプリ SLX（StockLedgerX） の設計思想が、どのように変化していったのかを時系列でまとめています。

シリーズ一覧はこちらです。

▶ SLX開発録〜設計思想ができるまで〜

次回は、

なぜ画面はデータ構造をそのまま表示しないのか。

UIとデータ構造を分けて考えるようになった理由について書いてみようと思います。