UIデザインもドメイン設計も意識することは同じ
UIデザインは、サービスのユーザーに対する設計であり、
ドメイン設計やコーディングは、開発者に対するデザインである
どちらも同じ人間なので、「どういうものがわかりやすいか」で意識すべきことはどちらも同じになる
↓改めて見ると浅くなってきたので書き直すか分割するかしたいmrsekut.icon
機能はできるだけ少なくすべし
同じことが達成できるなら、機能は少なければ少ないほうがいい
エンドユーザーもプログラマも覚えることが減る
コード量が少ないほうがバグが出づらい
実装・修正に書ける工数も小さくできる
ただし、「コードを共通化しよう」という意味ではないことに注意
責務の異なるものは分離すべき
個々の機能を直交させる
少ない機能の組み合わせで、できることを増やす
実装側から見ると、仕様が掛け算になるのではなく、足し算になるようにする
複雑性が爆発しない
機能Aを修正しても、機能Bには全く影響を与えないのが理想
関数型プログラミングは、小さい関数を合成して大きなことをやる思想
大事だと思っているが、UIの方は、具体的な手法はちゃんとわかっていないmrsekut.icon
たとえ機能が多くても、全体で一貫性を保つことで覚えることは減る プロダクト全体でルールに一貫性を持たす
似ているものは同じ挙動をさせる
覚えることを減らす
例えばPBFとか
逆に、同じ挙動をしないなら違う見た目にする
あるいはLinterのようなもので補助するか
最小限のもので意図が伝わるように努力する
一貫性をもたせる
見た目を工夫する
ヘルプ、チュートリアル
コメント
型、テスト、命名で工夫する
ペルソナを理解する必要がある
良いツールを使うべし・作るべし
正しいツールを使うべき
メジャーなツールや考えが正しいわけではない
「慣れてないから」とかで判断するな
近接
整列
インデントを揃える
対比
反復
型を使った抽象化とか？
なので、こんな考えを持っている人に、良い感じに説得(説明)ができる 「僕はエンジニアなので、UIデザインには興味がありません」
「設計の勉強はしてきたが、UIデザインはよくわからない」
「UIデザインは大事だけど、コードのレイアウトは拘らない」
設計に興味があるのであれば、その思考法はUIデザインにも応用できるよ、と考えられる
しかし、設計に関心のあるエンジニアであるmrsekut.icon目線で見ると、
設計に対する理解を高めるために、何冊も本読んだり、実践することで時間をかけて身につけてきているわけだが、
一方で、ユーザーに対してデザインする際も、それぐらいの時間をかけないと同じレベルには到達できないことも想像がつく
上述の様に応用が効くので時間短縮はできるものの、もっと時間をかけないといけないことがわかるmrsekut.icon
domain設計の方は、ペルソナがプログラマであるので、ドッグフーディングを常に実践している形になる 一方で、UIデザインの場合は、ドッグフーディングを実践していない場合は、もっとペルソナを注視する必要があることもわかる