「手順」は改善ではなく解体すべき

「UX的に〜」禁止令 その２

「UX的に〜」禁止令 https://savage.vc/articles/84f0edf5-595e-4933-b48b-f674bc9698c9 の続き。UXデザインっていうと、 「使いにくい手順を使いやすい手順に改善する」 ってなりがちだけど、それダメ。使いにくい手順は改善ではなく解体すべき。

「使いやすい手順」は排他する

ユーザ間においても、同じユーザの使用コンテキスト間においても、排他する。

不毛な改善ループ。 「ユーザがこのゴールを達成するために必要な手順はどう設計されるべきか?」 (塊は画面単位だったり、セクション単位だったりで考えて。) - A -> B -> C- > D -> Goal - A -> C -> D -> B -> Goal - AB -> DC -> Goal - DCBA -> Goal - 「個人的にはこの手順が使いやすいと思います、なぜならー」 x 100人分の個人的には意見のノイズよ。

- 現場からのフィードバック - 「8割のユーザの9割がこのコンテキストで使うはずだから、そのコンテキストから見れば この手順が最適」 - 一番声のでかい人、制作会社から見て決済持ってる人の「使いやすい手順」で改善 - Saas 作ってて、声の(課金額)大きいお客さんの受託っぽくなっていく - コレジャナイ感

逆説的だが、使いにくいものができてしまう大きな原因は、デザイナーが使いやすいものを作ろうとすることにある。使いやすさへの作為が使いにくさを生むのである。なぜなら作為は小さな適合とそれ以外のすべての大きな不適合を作り出すからだ。使いやすさを作為してはいけない。

「手順を解体する」とは

ある製品の使用者が「操作手順がわからない」と言う時、我々は、デザインとして手順が明確でないことを指摘する前に、製品には決まった操作手順があるはずだと使用者が考えるようになってしまったことを憂うべきである。一般に行われているシステムの要件定義は、使用者の行動シナリオを拠り所とするので、製品は手続的でモーダルなデザインになってしまう。しかしデザイナーは本来、使用者が手順を気にせずに済むデザインを考えなければいけない。

X: 8割のユーザの9割が使うコンテキストで、使いやすい手順を設計する ◯：任意のユーザが任意のコンテキストにおいて、ユーザ自身が使いやすい手順で使える、UIの設計

ユーザの使用時まで最適化(手順 / 機能)を遅延させる

機能：ユーザがそのサービスを使って何を成したいか 手順：その機能を得るにあたってユーザはどの手順でそのサービスを使うか 使用時に新たに作られる機能：使用の試行錯誤の中で、サービス提供者もユーザも、思っても見なかった機能が作り出される

web/appエンジニアの皆様であればこれ親近感ない？ そう、Rest。 Webの発展を長年にわたって支えてきたRest API の思想です。現代においてもステートレスHTTP API設計のデファクトでありベスプラ。 少数に絞った規約を守ってリソースへのアクセス手段を提供することで、機能をフロント側で組み立てることを可能にする。

シンプルさは究極の洗練である。— Leonardo da Vinci この言葉を知ったとき、筆者は真っ先に Webのことを思い浮かべました。 Webの特徴を一言で言い表すならば、シンプルさに尽きると常々考えていたからです。

箸しかり、包丁しかり。 less is more とは。ユーザによって無限に習得され利用される道具の持つ潜在性であり可能性。

URIはリソースを表現する名詞にする。 URIはリソースの名前です。 すなわちURIは名詞であるべきです。しかし、この作法は守られないことが往々にしてあります。 -略- HTTPメソッドのうちGET POST PUT DELETE は、これら4つで「CRUD」 という性質を満たすため、代表的なメソッドと言えます。 CRUDとは、Create (作成)、 Read (読み込み) 、 Update (更新)、 Delete (削除)というデータ操作の基本となる4つの処理のことです。 -略- このようにHTTPのステータスコードはなじみのある数字ですが、 実はクライアントの挙動を左右する重要な役割を担っています。 Web サービスや Web APIを設計するにあたって、 ステータスコードをどのように選択するかは重要です。レスポンスに間違ったステータスコードを割り当ててしまうと、クライアントが混乱しシステム全体の挙動に支障をきたします。 仕様で定められたステータスコードの意味を正しく理解しましょう。

あるいはRDBの正規化も。

第3正規化とは、第2正規形を満たした上で、主キー以外の列に依存する列（推移的関数従属）を別テーブルに切り離す作業です。 例えば「社員テーブル」内の「部署コード」に従属する「部署名」を「部署テーブル」として独立させます。 これにより、主キー以外の値の重複を排除し、データの冗長性をなくして、更新や削除に伴う不整合（更新時異状）を防ぐことができます。

教科書的にはでデータの一意性とかで説明されることが多いが。本質は使う側(SQL/Applicationのコード)に対して、用途や最適化を開くこと。 正規化された永続層があれば、SQL/Application 側でいかようにも使える。

リアル物理道具の箸や包丁のように、

- URL: /resourceName/${id} - Method: GET / POST(PUT) / PATCH / DELTE - StatusCode: Nxxx - xx JOIN yy ON

提供するのはリソースへのアクセス(URL/Method)であり、 返すのはフィードバック(StatuCode)。 ここに機能も手順も含まれていない。

なぜか。機能も手順もユーザ側で確定、最適化されるべきものだから。 テーブル設計をするなら、HTTP API 設計をするなら、その規約を守るべき。UIを設計する時も同じ。「使いやすい」を提供することなどできない。「ユーザがユーザなりに使いやすく使える可能性をできるだけ残す」ことしかできない。その謙虚さを持ってそのために。 最適化の遅延をさせることが大事。

AI批評

認知的負荷（Cognitive Load）のトレードオフへの言及不足 「道具（箸や包丁）」としてのUIは、自由度が高い反面、「ユーザーに学習と選択のコスト（判断負荷）を強いる」 というデメリットを孕みます。

そうね。これは「慣れ」において解消されるべきものと考えている。 例えば、自転車に乗るときに補助輪つければコケないけど、速く走る、車体を傾けて曲がる、ためには邪魔。 なので、初見で使って分からなくて失敗する、は問題ない。こけても壊れない起こしやすい、致命的なこけかたをしない自転車(サービス)を設計すべきであり、補助輪はつけるべきではない。 問題なのは自由度の高さではなく、一回こけたら壊れる/致命傷を負う自転車。

「自転車の比喩」の限界（学習コストの過小評価） > 「初見で使って分からなくて失敗する、は問題ない。こけても壊れない起こしやすい（中略）自転車を設計すべき」 この思想は一見美しいですが、B2CのWebサービスや多くのSaaSのビジネスモデルにおいて、ユーザーは「初見でこけた」瞬間にサービスを離脱し、二度と戻ってきません。 プロ向けツールなら学習コストを払ってくれますが、一般的なユーザーに「慣れ」を期待するのは生存バイアスです。「補助輪を外した状態を基本としつつも、補助輪（ウィザードやチュートリアル）をどう重ねるか」というグラデーションの議論を切り捨ててしまっています。

web/appのチュートリを便利と思ったことないし、リアル物でも説明書とか読まなくない？ バグった時とか故障した時には読むけど。 「思い通りに使えない」に対しては使い方を変えて再チャレンジ、の手順の方が正しくないすか？ なので、「使い方ページ」みたいなのは置いとくとしても、再チャレンジを容易にする、の方が筋。

「頻度が極端に低い」または「結果だけが欲しい」プロダクト（行政手続き、確定申告、ECの決済など） ここでは「慣れ」は期待できません。ユーザーは自転車を乗りこなしたいのではなく、「今すぐあっち側にワープしたい」だけです。道具の習得に興味がないユーザーに対して手順を解体すると、不満しか残りません。ここでは強固なレール（＝手順の強制）こそがユーザーへの優しさ（ホスピタリティ）になります。

それはそう。洗濯機に慣れた現代の生活で「使いやすい洗濯板と石鹸があれば、衣類に応じて洗い方変えれるぜ、工夫して使って」って言われても無理。 でも炊飯器じゃなくて土鍋で飯炊く、くらいは4,5回チャレンジすれば食えるもんになるし、鍋ものとかラーメンとかシチューとか、も作れる。使いやすく見せてもかっこいい土鍋を作ったっていいじゃん。

筆者は「土鍋」の例えを出し、「4,5回チャレンジすれば食える」「使いやすくてかっこいい土鍋を作ったっていい」と述べていますが、現代の多くのサービスにおいて、ユーザーは「土鍋」を求めていません。 ユーザーが求めているのは「美味しいご飯を最短で食べること」なのか、「料理という行為自体をコントロールすること」なのか。 もし前者が市場の大半を占める領域（例：労務管理SaaS、確定申告ツール）で「土鍋」を提供すれば、どんなに美しくても競合の「炊飯器」に敗北して事業が終了します。

🥺

AIそれな

「使いやすさの作為が、それ以外の不適合を生む」という本質 大口顧客や一部の声の大きいユーザーの要望に応えて手順（ウィザードやモーダル）を足していった結果、画面が迷路のようになり、プロダクトの寿命を縮める「機能過多・自由度ゼロのSaaS」「SaaSの受託化」は無数に存在します。「手順の改善ではなく解体」というスローガンは、この泥沼から抜け出すための強い指針になります。

からのまとめ。

だから、まず「土鍋（道具）」として作れ

AIに論破されかけたけど（「🥺」）、それでも言いたい。

もちろんビジネスだから、炊飯器（自動化・手順の強制）が勝つ市場があるのは認める。確定申告を土鍋でやりたい変態はいない。 でもね、初手で「炊飯器」も違う。

多くの開発現場で起きている悲劇はこれ： 1. 最初から特定のユースケースに特化した「手順（炊飯器）」を作る 2. 別の使い方をしたい客から要望が来る 3. カツ丼機能、パン焼き機能、低温調理機能を「手順」の上に無理やりツギハギする 4. それら用の手順が100個ある、誰も全貌を理解できないキメラSaaSが完成する

これ、RDBで言えば「画面の都合に合わせて非正規化しまくったテーブル」と同じ。一瞬の使い勝手と引き換えに、未来の拡張性を捨ててる。

だから順序が逆。

1. まず、正規化された「土鍋（道具）」を作る - オブジェクト（リソース）がそこにあって、CRUDが直感的にできる状態。 - 手順を強制しない。 - ミスったらミスったことがその場でわかる。こけてもすぐ起き上がれる（Undoできる）頑丈さを作る。

2. その上に、薄い皮として「炊飯ボタン（ショートカット）」を載せる - 8割の人が毎日やる決まりきった手順があるなら、それは「土鍋の上に置くワンクリックのマクロ」として提供すればいい。 - ウィザードが必要なら、それはコアのUIではなく「土鍋に食材を放り込むための一時的な補助ツール」として実装する。

コアにある「道具としての自由度」を殺さないこと。 「手順」は機能じゃない。ただのショートカットだ。

「UX的にこのステップを挟みましょう」 「ユーザーが迷わないように、この順序でしか操作できないようにモーダルで縛りましょう」 そういう「UX的に〜」には、「ちょっと待て」と。 その「親切心」が、半年後のあなたのプロダクトを窒息させる。