concept design
Takyaway
なぜか？
ソフトウェアを提供する側が意図するメンタルモデルとユーザが抱くメンタルモデルに齟齬がある場合、バグではないがユーザにとってはとても使いづらいソフトウェアになってしまいます
shu-san.icon例としてのDropboxやOSのゴミ箱機能の話がおもしろかった
あのゴミ箱、経験のあるエンジニアなら言われなくても薄々感づいていると思いますが、ファイルを捨てるためのものではありません。むしろ、うっかり捨てたファイルを簡単に復元するための機構です。
もし大抵のエンジニアが「ファイルを復元できる」機能を設計しようとすると、せいぜい「ファイルの復元」なるメニューが、画面の端にあるメニューバーから辿れる多数のサブメニューの1つとしてぽつんと置かれるだけではないでしょうか。
これだと、あらゆる機能がひたすらネストしたメニューの奥底に眠ってしまうことになり、機能はきちんと実装されているのにユーザーにとってはわかりづらく見つけづらい、とにかく使い勝手の悪いソフトウェアになってしまいます。
更に言えば、これは実現方式としても優れています。OSレベルで削除したファイルを復元するのはなかなか大変ですし、場合によっては復元に失敗するでしょう。しかし「ゴミ箱」は削除予定のファイルを移動するための特別なフォルダというだけなので、復元もまたファイルの移動で簡単に実現できます。
メンタルモデルは、ソフトウェアで仮想的な実体、つまり概念（concept）の集合体で作られる
概念がソフトウェアの中心にあって、プログラムは概念を実現する目的で記述されるべき
建築の例えで言えば、まず居住者にとってどういうものがあれば、どういう気配りがなされていれば居心地の良さや優れた体験を得られるか、をまずデザインしよう、ということです
Concept Designをしっかりしようねということ
開発者（プログラマ）、UI/UXデザイナー、そしてユーザーの3者がメンタルモデルを共有することが重要
shu-san.iconこれは本当にそう。ユーザーが満たしたいメンタルモデル≒ユースケースを理解できていれば、実装する必要がある・ないの判断もつけやすい。理解できずにあいまいなままだと、ソフトウェアとしてのインテグリティ（完全性）を追求してしまい、設計としては美しいがユーザーが利用しない機能を生み出してしまう。（自分もたまにやってしまう）
shu-san.iconユーザーのメンタルモデルを満たす上で「本当にこの機能は必要か？」を開発者全員が考えるべき
メモ
オブジェクト指向設計では、UI/UXの設計は関心事ではなく分離して設計されていた
UI/UX設計→デザイナーが設計する
ソフトウェア設計→エンジニア