はじめに
以前の記事で、
私は、
データ構造は強く、利用体験はシンプルに。
という考え方にたどり着いたと書きました。
4階層構造も、
「分類なし」も、
あとで整理も、
全部そこへ向かうための試行錯誤でした。
でも、
その考え方を実際に画面へ落とし込もうとした時、
また一つ悩みが増えました。
内部では4階層。
でも、
利用者には4階層を感じてほしくない。
では、
画面は何を見せればいいのでしょうか。
最初はそのまま表示していました
最初の頃は、
データ構造をそのまま画面へ表示していました。
内部が
Collection
↓
Folder
↓
Category
↓
Title
なら、
画面も同じ順番です。
それが一番自然だと思っていました。
実際、
間違っているとも思っていませんでした。
でも、少しだけ気になりました
使っているうちに、
少しだけ気になることがありました。
例えば、
ゲームを一つ登録したいだけなのに、
Folderを選び、
Categoryを選び、
ようやくTitleへ辿り着く。
確かに、
内部では必要な操作です。
でも、
利用者は、
本当にそこまで考えたいのでしょうか。
私は少しだけ、
立ち止まりました。
画面は誰のためにあるのだろう
その頃から、
画面の見方が少し変わりました。
画面は、
データベースを表示するためのものではありません。
利用者が、
やりたいことを実現するためのものです。
そう考えると、
内部構造をそのまま見せる必要はありませんでした。
見せなくてもいいものがありました
例えば、
「分類なし」。
これは内部では必要です。
でも、
利用者が登録するとき、
最初に見たい情報でしょうか。
あるいは、
FolderやCategoryという言葉。
開発者にとっては必要です。
でも、
利用者がやりたいことは、
そこではありません。
画面には、
見せなくてもいい情報がありました。
見せた方がいいものもありました
逆に、
内部には存在しないのに、
画面では必要なものもありました。
例えば、
パンくずリスト。
「今どこを見ているのか。」
利用者には分かった方が安心できます。
でも、
パンくずというデータは、
データベースには存在しません。
ここで初めて、
気付きました。
画面は、
データ構造をそのまま映す鏡ではない。
画面には、
画面として必要な情報がある。
データ構造には、
データ構造として必要な情報がある。
その二つは、
必ずしも同じではありませんでした。
振り返ると当たり前でした
今思えば、
当たり前のことです。
データベースは、
保存するためのもの。
画面は、
使ってもらうためのもの。
目的が違うのだから、
役割も違う。
でも、
開発を始めた頃の私は、
その二つを同じものだと思っていました。
だから、
画面も、
データ構造に引っ張られていたのだと思います。
おわりに
以前の私は、
データ構造が決まれば、
画面も決まると思っていました。
でも今は違います。
画面は、
データ構造を見せる場所ではありません。
利用者が、
迷わず使えるようにする場所です。
だから、
内部構造はそのままでも、
画面は自由でいい。
この考え方になってから、
画面を設計することが少し楽になりました。
もしかすると、
設計とは、
データ構造を考えることではなく、
「何を見せて、何を見せないか」を決めることなのかもしれません。
前回の記事
「データ構造は強く、利用体験はシンプルに」を設計へ落とし込んだ話
シリーズ
▶ SLX開発録 〜設計思想ができるまで〜
次回は、
画面とデータ構造を分けて考えるようになったことで、
自然と生まれた UiState という考え方について書いてみようと思います。