はじめに
前回の記事では、
「構造」と「使いやすさ」は別だった
という話を書きました。
4階層構造にすることで、データはかなり整理しやすくなりました。
ただ、その代わりに新しい問題が見えてきました。
それは、
登録しづらい
ということです。
今回は、その問題をどう考え、なぜ「分類なし」という考え方にたどり着いたのかを書いてみます。
4階層は正しかった
4階層構造にしたことで、
- データ構造は整理できる
- 拡張しやすい
- 将来の機能追加にも対応しやすい
という土台ができました。
設計としてはかなり納得していました。
だから、
構造そのものを見直そうとは思いませんでした。
登録するたびに立ち止まる
しかし実際に登録しようとすると、毎回、
Collection
↓
Genre
↓
Title
↓
Item
という順番で考える必要があります。
最初は、
「ちゃんと分類してから登録しよう」
と思っていました。
でも実際には、
登録するたびに少し考えてしまいます。
どのジャンルだろう。
タイトルはどう分けよう。
あとで変えるかもしれない。
その数秒が積み重なると、
思っていたより登録する手が止まっていました。
利用者がやりたいこと
ここで一つ気付いたことがあります。
利用者がやりたいことは、
登録すること
です。
分類することではありません。
もちろん、
整理されていた方が後から探しやすい。
でも、
登録するたびに考えさせてしまうのは、
少し違う気がしました。
でも、分類は必要だった
だからといって、
分類をなくせばいいとも思いませんでした。
分類があるからこそ、
一覧は見やすくなります。
検索もしやすくなります。
後から整理もしやすくなります。
つまり、
構造は必要。
でも、
登録のたびに意識させる必要はない。
この二つを両立できないか。
そんなことを考えるようになりました。
完璧に分類できるとは限らない
さらに考えているうちに、
もう一つ気付いたことがあります。
それは、
最初から分類を決められないこともある
ということです。
例えば、新しくゲームを買ったとします。
RPGなのか。
アクションなのか。
シリーズはどう分けよう。
あとで考えたいこともあります。
その場で決められないことは、
思っていたより多くありました。
そこで考えた
だったら、
最初は分類しなくてもいいのではないか。
そう考えるようになりました。
まず登録する。
整理はあとから。
利用者がやりたいことを先に終わらせる。
そう考えると、
今まで感じていた違和感が少しずつ繋がってきました。
この考え方から生まれたのが、
「分類なし」
という仕組みでした。
「分類なし」は手抜きではなかった
最初は、
「分類なし」という名前に少し抵抗がありました。
ちゃんと整理するためのアプリなのに、
分類しない場所を作る。
矛盾しているようにも思えたからです。
でも実際には逆でした。
分類なしがあることで、
登録しやすくなり、
結果として整理も続けやすくなりました。
今振り返ると、
分類を諦めたのではなく、
分類するタイミングを変えただけ
だったのだと思います。
おわりに
この頃から少しずつ、
設計で考える順番が変わっていきました。
最初は、
「どう分類するか」
を考えていました。
でも途中から、
「どうすれば利用者を止めずに済むか」
を考えるようになっていました。
振り返ると、
「分類なし」を作ったことよりも、
考え方が変わったことの方が大きかった気がします。
ただ、この時点でもまだ一つ疑問が残っていました。
4階層なのに、どうすれば4階層を意識させずに使えるのか。
「分類なし」は、その答えの一部ではありました。
でも、本当に目指していたのは、
利用者が階層そのものを意識しなくても使える体験でした。
その考え方は、このあとSLXの設計全体へ広がっていくことになります。