はじめに
前回の記事では、
画面はデータ構造を映す鏡ではない。
そんなことを書きました。
利用者に見せたいものと、
内部で管理したいものは、
同じではありませんでした。
でも、
その考え方になってから、
今度は別の悩みが生まれました。
画面には、
何を見せればいいのだろう。
何を見せない方がいいのだろう。
最初は、全部見せようとしていました
開発を始めた頃の私は、
情報は多い方が親切だと思っていました。
タイトル。
画像。
分類。
進捗。
自由項目。
ステータス。
せっかく管理できるのだから、
全部見せた方が便利だろう。
そう考えていました。
機能を追加するたびに、
画面も少しずつ賑やかになっていきました。
当時は、
それを悪いことだとは思っていませんでした。
便利になっているはずでした
画面に表示される情報は増えました。
できることも増えました。
それなのに、
使いやすくなった感じがしません。
むしろ、
少しだけ息苦しい。
何となく見づらい。
どこを見ればいいのか、
一瞬迷ってしまう。
そんな違和感が残るようになりました。
利用者は、本当に全部見たいのでしょうか
そこで、
少し立ち止まって考えました。
例えばゲームなら、
最初に知りたいのは何でしょう。
タイトル。
画像。
持っているかどうか。
たぶん、
そのくらいです。
Folder。
Category。
自由項目。
更新日時。
そういった情報は、
必要になった時に見られれば十分です。
利用者は、
全部を見たいわけではありませんでした。
その時に必要なものだけを、
知りたかったのです。
「持っている情報」と「見せる情報」は違いました
この頃から、
一つの考え方が生まれました。
持っている情報と、
見せる情報は、
同じである必要はない。
内部では、
将来のために情報を持っていていい。
でも、
最初の画面では、
利用者が次の行動を迷わない程度の情報だけでいい。
その方が、
画面はずっと軽くなりました。
見せないことも設計でした
以前の私は、
画面には、
できるだけ多くの情報を並べることが親切だと思っていました。
でも今は違います。
見せることだけが設計ではありません。
見せないことも設計です。
利用者が迷う情報なら、
最初から見せない。
必要になった時だけ、
取り出せればいい。
そう考えるようになってから、
画面を作ることが少し楽になりました。
おわりに
振り返ると、
私は「全部見せること」が親切なのだと思っていました。
でも実際には、
情報を減らしたわけでも、
機能を減らしたわけでもありません。
必要な時に、
必要なものだけを見せる。
ただそれだけで、
画面の印象は大きく変わりました。
もしかすると、
画面設計とは、
「何を追加するか」
ではなく、
「何を最初は見せないか」を決めることなのかもしれません。
前回の記事
コレクション管理アプリで、「画面はデータ構造を映す鏡ではない」と気づいた話
シリーズ
このシリーズでは、個人開発しているコレクション管理アプリ SLX（StockLedgerX） の設計思想が、どのように変化していったのかを時系列でまとめています。
シリーズ一覧はこちらです。
▶ SLX開発録 〜設計思想ができるまで〜
次回は、
この考え方から自然に生まれた、
画面専用の状態管理について書いてみようと思います。