私、設計スキルを学ぼうと思っていて、本とか読んで、インプットだけはやっていたんですが、設計スキルを発揮するにふさわしい複雑な問題には出会ったことがなかったです。設計というプロセスを挟むことによって、時間はかかるようになるし、いつでもどこでも必要とは思っていないです。本を読んだ今でも、設計プロセスをむやみやたらに挟むのは良くない派です。いえ、設計プロセスの一つである、ロバストネス分析をやってみると問題が単純化するよという例が得られたので、今回記事を書いてみることにしました。こんなUIが与えられているとします。Keepに保存ボタンがついているものです。このUIでは、何かしらリストを追加したり、リストの内容を変更したりすることができます。保存ボタン付きのリスト。リストの一行に保存ボタンがついているのではなく、リストを含むセクション全体に対して、保存ボタンがついている。何やら、複雑そうな気がします。これを一度ロバストネス分析をやってみることにします。以下の図において、赤い丸が、ユーザが行う操作で、緑の丸がブラウザ上におけるエンティティです。グレーの丸がサーバ上のエンティティになります。注目は赤枠で囲われている箇所です。このUIだと、フロントでサーバ上のリストにある要素か、ない要素かを保存しておく必要があって、実装が複雑になりそうです。APIとしてもRESTだけで表すことはできず、どうしてもリストに削除フラグなどを仕込んで、削除フラグが立っているリストの要素に対してだけ、削除を実施するなどの工夫が必要です。私はこのロバストネス分析をやってみた結果、この実装はやりたくないなと思いました。したらもっと単純な実装になるUIになるのかなと考えた結果、世の中のリストUIを見ているとリスト全体を含む塊には保存ボタンがついていないことに気づきました。モードレスなUIです。