手順の「解体」「強制」の具体例

「UX的に〜」禁止令 その3 動画キャプチャつきは Note に作ってます。 https://note.com/_ore/n/nca27f3d9da30

「手順」は改善ではなく解体すべき https://savage.vc/articles/39e90cd7-becb-49d5-8939-817f848bc84b の続き

X: 手順を暗記してもらう ◯: 各ユーザ自身のやり方で使える余地を残しておく

- 暗記はつらいが工夫は楽しい - 汎用的な小さな機能を組み合わせる事で、工夫して色々な事ができるようにする 工夫はなるべく[順不同]にできるようにする 要素の組み合わせには作業順序があるが、どの順番で実行しても大丈夫にしておきたい 一見どの順番で実行しても大丈夫に見えても、他の所で不整合が起こると良くない [wikiでページのURLをIDにすると絶対にうまくいかない]に、ページIDはページ分割作業に「正しい順番」を生み出し、不整合を起こす原因になる事を書いた 順番による不整合が起こるとしたら、その場ですぐにわかるようにしておく 後でダメだったとわかる系の不整合は、他人に怒られる事によって知らされるので最悪だ

仕事の対象がそこに見えていて、それに対して行えるアクションが見えていて、その結果の状態が常に見えるようになっていれば、ユーザーはその道具を使ってできること、 その道具の役割を自ら発見し、妥当性を感じながら仕事を組み立てることができます。 そのような仕事は楽しいものです。 一方タスク指向のUIでは、入口でまず謎の人格が立ちはだかります。 ユーザーはその人格に、オブジェクトへアクセスするための許可を求めなければいけません。 システムは事業者や権力者という人格に属しており、ユーザーは、その人格が企図した形でしかそれを使うことを許されません。 タスク指向のUTまとは、そうしたある種の傲慢さを常に纏っています。 タスク指向のUIでは、ユーザーが一番に意識しなければならないのは決められたタスクのことであり、 システムは目的を覆う障害物になってしまうのです。

UXデザイン = 手順を設計すること = 謎の人格を作ること と考えられがちな昨今。

当記事サマリー - ↑謎の人格を消す - 全ユーザが全コンテキストにおいて全ゴールを達成するために、それなりに使える (「使いやすい」、ではない。「使うことが可能」) - 操作に「慣れる」ことができる。

そのためのセオリー - コンテキストスタックを積まない - 操作をカジュアルにする

謎の人格が支配する世界を作る

今回の成果物、青空文庫朗読アプリのBunvox。 すでに手順が解体されているメインの挙動に、手順を埋め込んである環境を追加してみました。 iphoneをお持ちの方は実際にアプリを触りながらお読みください。当記事が何言ってるか伝わるはず (伝わってほしい。。!) https://apps.apple.com/jp/app/bunvox/id6793343079

設定画面 -> 一番下 -> モーダルUI(タスク指向) より、謎の人格が支配する世界に切り替わります。

「コンテキストスタック(おれの造語)」を「積む」とは

- コンテキストスタック：ユーザの頭の中にある目的。 - 積む：一つ前のコンテキストを視界から消す

例えば、スマホサイズの描画領域で「プレイリストの登録」において。

- コンテキストスタック: プレイリストを追加するぞ、追加する作品を探すぞ、章を探すぞ - 積む: .sheet() 、 navigationStack.push

sheet が上に被さった瞬間、一番下の「プレイリストを追加するぞ」は画面から消える。消えた分はどこへ行くかというと、ユーザの頭の中に行く。UI が視界から消したものは、ユーザがワーキングメモリで持ち続けるしかない。つまり「積む」とは、画面をきれいにする代わりに、記憶のコストをユーザに払わせることだ。

UI のスタックと頭のスタックが同期している間は、なにも問題ない。問題は同期が切れたときに起きる。

• 割り込み: 電車が駅に着く。通知が来る。単によそごとを考える。頭のスタックだけが飛んで、UI には積まれた画面が残る。「あれ、なんでおれは章の一覧を見てるんだっけ」 • 分岐: 積んでいる途中で別の目的が湧く。章を探していたら別の作品が気になった。感想を書いていたら、その章をもう一回聴いてから書きたくなった。スタックの途中から横へは行けないので、いったん全部降ろして積み直すしかない。そして降ろすとき、途中の入力はたいてい破棄される

モーダル版 Bunvox の「感想を書く」は 5 ステップのウィザードにした。手順としてはどこも壊れていない。迷わず進めるよう真面目に作ってある。それでも、途中で「あの朗読、もう一回聴いてから書きたい」と思った瞬間に詰む。戻るボタンを押すと「保存されていません」と宣告され、書きかけを捨てて「本をさがして聴く」を積み直し、聴き終わったらまた「感想を書く」を 1 から積むことになる。ウィザードの出来の問題ではなく、積む構造そのものの問題。

「積まない」とはこの逆で、目的が切り替わっても、いまの画面がそのまま次の目的の起点になる状態。作品ページに★も再生ボタンも感想もその場にあれば、頭に積んでおくものは高々ひとつで済む。

操作を「カジュアルにする」とは

カジュアルの反対は「フォーマル」。フォーマルな操作とは、先に目的を宣言して、手順を踏んで、最後に確定する操作。メニューから「お気に入りに追加する」を選び、作品を検索し、確認画面で「追加する」を押す。婚姻届の提出みたいなものだ。

カジュアルな操作の条件は 3 つ。

• その場にある: 目的を宣言しなくても、対象が見えていればそこに操作が付いている • 結果がその場で見える: 押した瞬間に★が塗られる、hapticする • 戻せる: 違ったらもう一回押せば元に戻る。「失うと困る状態」をそもそも作らない

例えばitemの削除とitemsの編集

同じ「プレイリストから章を外す」でも、コンテキストの大きさは場合によって違う。 • 聴いていて「これ違うな」と思った。1章だけ外したい。小さいコンテキスト • 並びを整えて、いらない章をまとめて外して、ついでに名前も変えたい。腰を据えた大きいコンテキスト モードレス版は、この2つに別の重さの操作を当てている。

小さいコンテキストはカジュアルに。行をスワイプすれば外れる。編集モードに入る宣言も、保存の確定も要らない。間違えて外しても、追加がカジュアル（前述の★やメニューの1タップ）だから事故のコストが安い。削除を軽くできるのは、逆操作が軽いからだ。

大きいコンテキストには「編集モード」がある。そう、モードだ。おれはモードを全否定していない。まとめての並び替え・複数削除・改名は作業コピーに対して行い、確定するまでモデルには書き込まない。途中でやめれば元のまま。一括編集は「途中の中途半端な状態を残したくない」コンテキストなので、宣言して入り確定して出る、が合っている。

ポイントはモードの有無ではなく、コンテキストの重さと操作の重さが対応していること。小さいコンテキストに儀式を課さない。大きいコンテキストには安全な作業台を出す。

タスク指向版では、これが「プレイリストを編集する」の1本に畳まれる。章を1つ外すだけでも、メニューで宣言し、ステップ 1/2 でプレイリストを選び、編集画面で外し、保存を押し、「保存しました」の報告に OK する。フロー自体は真っ当に作ってある。破棄の確認も付けた。それでも、スワイプ1回で済むはずのコンテキストに、宣言と2ステップと保存確認がかかる。動詞のメニューはコンテキストの大きさを区別できないので、最小のコンテキストにも最大の儀式が適用される。

例えばプレイリスト

冒頭で「積む」例に挙げた、あのプレイリスト登録の、モードレス版での答え合わせ。

プレイリストは 1:n のデータだ。1 がプレイリスト本体（名前）、n が章。タスク指向で組むと「プレイリストをつくる」は 1→n の一本道になる。まず名前をつけ、作品を探し、章を選んで、確定。冒頭で積んだスタックそのままの形。

モードレス版はこの順序を要求しない。

• プレイリストはタイトルだけでも、章だけでも存在できる。「全部空」ですら validation で弾かれることはない。通常操作の「戻る」や「他のプレイリストを表示」で画面を離れたとき、作りかけの空プレイリストとして黙って削除されるだけ。ユーザがエラーに出会う瞬間が存在しない 入力の正しさをユーザに要求する（フォームで弾く）のではなく、どんな状態でも成立するようにデータ側を設計してある、ということ。 • n 側（章）から、いつでも、その場の粒度で足せる。章を見ていれば ChaptersPage から章 1 つを、作品を見ていれば WorkPage から作品の全章を、著者を見ていれば AuthorPage から著者の全作品を、そのままプレイリストに放り込める • それどころか、n 側から 1 を作れる。メニューの「新規プレイリスト」を押せば、いま見ている章が入った状態でプレイリストが生まれる。名前は「プレイリスト 3」と勝手につく。気が向いたらあとで変えればいい • もちろん 1 側（プレイリストのページ）から章を探しに行く、教科書どおりの道も残してある

「名前をつける」と「章を集める」のどちらが先でもいいし、どこから始めてもいい。ユーザは「プレイリストを作るぞ」と宣言してから素材を探しに行くのではなく、聴いていて「これ集めておきたい」と思った瞬間に、いま見ているものをいま見ている粒度で放り込む。手順を改善したのではなく、手順そのものが無い。

例えば抜粋

抜粋（気に入った一節の抜き書き）は、この比較でいちばん差が残酷に出る例だと思う。抜粋したくなる瞬間は、かならず別のコンテキストの最中に来るからだ。

モードレス版では、聴いている・読んでいるその画面で、いま読み上げられてハイライトされている段落をタップする。出てくるポップオーバーは「再生」と「抜粋」の2つだけ。「抜粋」を押せば haptic とともに即コミット。追加済みの段落は次に開くと「抜粋追加済み」になっていて、そこから外せる。★と同じトグルだ。「この一文いいな」から保存まで2タップ、再生は止まらないし、画面遷移もない。読書のコンテキストは一度も降りていない。

同じ機能をタスク指向で組むと「抜粋をつくる」という4ステップのウィザードになる。作品を選び、章を選び、本文から段落を選び、メモを添えて確認して保存。フロー自体は真面目に作った。だが、抜粋したくなったのは聴いている最中だ。ウィザードに入るには、まず聴くのをやめてメニューに戻り、「抜粋をつくる」と宣言し、いままで聴いていた作品を探し直し、章を探し直し、ステップ 3 の段落一覧から「さっきの一文」を記憶を頼りに探し直す。UI が視界から消したコンテキストを、ユーザがワーキングメモリから全部復元する。冒頭で書いた「積む」のコストが、そのまま請求書になって届く。

ステップ 3 の作りにも構造の限界が出る。ウィザードの1画面に「本文から選ぶ」を載せるには、本文を段落のチェックボックス一覧に選択肢化するしかない。段落より細かい粒度では抜けないし、選びながら聴き直すこともできない（聴くのは別タスクだから）。モードレス版の「ハイライトされているその段落を、聴こえたその瞬間に突く」という粒度とタイミングの一致は、手順の中では原理的に再現できない。

つくったあとも割れかたは続く。モードレス版の抜粋ページは、抜粋という名詞にすべてが貼り付いている。メモ欄は常に出ていて、フォーカスが外れたら勝手に保存される（保存ボタンは無い）。メモが書けていれば「感想として投稿」がその場に現れ、作品行を押せば作品ページへ、共有ボタンで画像に書き出せる。抜粋は次のコンテキストへの起点、つまりハブになっている。タスク指向版では「抜粋をながめる」が別タスクで、「抜粋をつくる」の完了画面には「見るには、メニューにもどって『抜粋をながめる』からはじめてください」と書いてある。そしてながめるタスクの中では、作品名はただの文字で作品ページへは飛べず、感想への引用も聴き直しも手順に無い。編集だけは1段深いステップとして存在し、「保存」を押して「保存しました」に OK し、保存せず戻れば「破棄しますか？」と迫られる。動詞で切ると、名詞が持っていたハブの機能が全部落ちて、落ちた分だけタスクが増える（そして毎タスクに保存と確認が付いてくる）。

基本はコミット

「例えばitemの削除とitemsの編集」節の「大きいコンテキスト」だけは作業台方式（確定するまで書き込まない）にしたが、それ以外は逆に振ってある。操作した瞬間にコミットする。「保存」という操作をユーザにさせない。

保存ボタンがあるということは、アプリの中に「まだ保存されていない状態」が存在するということだ。ユーザは操作のほかに、保存済み／未保存という2状態の管理を背負わされる。未保存はコンテキストスタックの一段で、抱えている間は自由に離脱できない。「保存されていません」ダイアログは、その管理にユーザが失敗した瞬間に出る罰だ。

即コミットなら、失われうる状態が原理的に存在しない。いつ閉じても、電話が来ても、電車が着いても、そのまま。どの画面からでも離脱・分岐できる「積まない」設計は、この土台の上に立っている。

★も、プレイリストへの追加も、スワイプでの削除も即コミット。極めつけは感想のエディタで、文章を書く画面ですら保存ボタンが無い。閉じたら upsert する。

• 本文が空でも（引用だけ選んだ、続きはあとで書く）書きかけとして残す。新規は非公開ではじまるので、書きかけが人に見えることはない • 縛りは「空のまま公開に切り替えられない」の一点だけ。保存でユーザを縛らず、公開でだけ縛る • 書き直して変更があれば「戻す」ボタンが出る。「保存しますか?」と聞くのではなく、保存済みの内容へいつでも戻れるようにする。確定を迫らず、逆方向の操作を用意する • 何も書かず引用も選ばずに閉じたときだけ、行を作らない。空プレイリストの自動削除と同じで、ゴミはユーザに片付けさせず、アプリが黙って掃除する

タスク指向版は基本が逆で、「保存」が主役になる。ローカルに写して編集し、保存で書き込み、「保存しました」に OK し、保存せず戻れば「保存されていません」と迫られる。フローが増えるたび、ユーザが管理すべき未確定状態がひとつずつ増えていく。

レールを敷くのではなく、怪我をしない床を敷く

よく「手順（ウィザード）がないと、初心者や受動的なユーザーが迷ってしまうのでは？」という反論を受ける。しかし、ユーザーが迷うのは「自由だから」ではなく、「何が起きるか不可逆で怖いから」だ。 「次は何をすべきか」を手取り足取り指示する謎の人格を作り出し、ユーザーを子供扱いしてレールに乗せる必要はない。「逆操作が安い」「いつでも戻せる」という安全網さえあれば、ユーザーは自分の手で触って、失敗して、勝手に慣れていく。 UIデザインが目指すべきは、ユーザーを案内するレールを敷くことではない。転んでも怪我をしない、起き上がりやすい「床」を敷くことだ。即コミットとモードレスの設計は、その床を作るためにある。

その床がちゃんと敷けてるからこそ、 「こっからここまでは、ぽちぽちモード作って、レールに乗せる(謎の人格を作る)」 というレールを敷くべきところが分かるし、ユーザにも伝わる(違和感を感じない)はず、そうであってほしい。 レールを敷くべきところ、は長くなるのでまた今度。

コンテキストは並列に置ける

スマホサイズだと画面サイズが小さいので積むしかないが、画面幅の大きい端末 MapAppやブラウザ であれば、積まずに並列における。 例えばMacApp の プレイリスト(モードレスバージョンだけ)。

Mac 版の BunVox は 3 カラムの NavigationSplitView で、サイドバーにセクション、content 列にプレイリスト一覧、detail 列に選んだプレイリストの中身が出る。さらに detail の右には inspector として「章・作品を追加」のパネルが開く。つまり iPhone で縦に積んでいたもの——一覧 → 中身 → 追加シート → 検索——が、横に全部並ぶ。

• 一覧（content 列） • 中身（detail 列） • 追加元の検索と候補（inspector） • そして下端にはプレイヤーバー。聴きながら全部できる

冒頭の「積む」の定義は「一つ前のコンテキストを視界から消す」だった。並べるとは、消さないこと。「プレイリストを追加するぞ」という一番下のコンテキストは、章を検索している間も一覧としてずっと左に見えている。UI が視界から消さないので、ユーザのワーキングメモリに引っ越すものが無い。割り込みが来て頭のスタックが飛んでも、画面を見ればスタック全体が写っている。復帰のコストは「見る」だけ。

分岐にも強い。inspector で章を検索している途中で別のプレイリストが気になったら、左の一覧でそれを選ぶだけでいい。detail の中身は差し替わるが、inspector の開閉・章／作品タブ・検索語は親が保持していて消えない。iPhone なら「シートを閉じて、一覧へ戻って、別のを開いて、またシートを開いて、また検索し直す」という積み直しになるところが、Mac では選択を1回変えるだけで済む。降ろすものが無いから、破棄されるものも無い。

中身の操作は iOS 版と同じ文法のまま並列に効く。行タップでそのプレイリストの並びから再生、右クリックで「作品へ移動」「本文へ移動」——detail に push しても content 列の選択は維持されるので、作品ページを見に行って戻っても一覧の文脈は残っている。「＋」を押せば空のプレイリストが即コミットで生まれて選択され、タイトル欄にフォーカスが当たる。名前も付けず何も入れずに離れれば黙って掃除される。このへんは iPhone 版とまったく同じで、画面が広くなったからといって設計を変えていない。同じモードレス設計が、幅に合わせて展開のされ方だけ変わる。

そしてこれが、タスク指向との一番構造的な差になる。モードレス設計は画面が広くなるとスタックが浅くなる——iPhone で積んでいたものを、iPad では2枚に、Mac では4枚に並べ直せる。ウィザードはそうならない。「プレイリストをつくる」の1本道は、画面がどれだけ広くなってもステップ 1/2 が大きく表示されるだけで、順序は1列のままだ。手順は直列にしか存在できないが、コンテキストは並べられる。積まない設計は、画面という資源をそのまま記憶の肩代わりに使える設計でもある。

TODO

当記事を踏まえて、 では、web/app (GUI)のデザイナーは製作時に何を考えるべきか。 を次の記事で。

AI 批評

「タスク指向（ウィザード）」のストローマン（藁人形）化の懸念 モードレスの優位性を強調するあまり、タスク指向側の設計があえて「極端に不器用な形（11タスクに分割、抜粋を見るために一度戻る、等）」に描かれている印象を受けます。 読者によっては「それはタスク指向が悪いのではなく、単にタスク指向版の設計が下手なだけでは？」と反論されるリスクがあります。

実際には、「不可逆なトランザクション（決済、契約、アカウント削除）」や「認知的負荷が高く選択肢をあえて絞るべき状況（初回セットアップ、専門知識が必要な設定）」では、フォーマルな手順やモーダル（タスク指向）が正当に機能します。この「使い分けの境界線（なぜ今回は解体すべきなのか）」を明記すると、独善的な印象を回避し、議論の厚みが増します。

次の記事（TODO）への期待と問いかけ 記事末尾に「では、web/app (GUI)のデザイナーは製作時に何を考えるべきか」とあります。ここに向けて、以下の問いに対する回答が含まれていると、読者にとって実務直結のバイブルになると考えます。 1. 「Figma上でどう表現・検証するか？」 Figmaの画面遷移プロトタイプ（直列の紙芝居）自体が「手順（スタック）」を強制するツールになっています。デザイナーがFigmaの罠に落ちず、モードレスな状態遷移を設計するための思考法やプロトタイピング手法はあるか？ 2. 「実装（エンジニア）への要求水準」 モードレス設計は、UIデザイナー単独では完結せず、ローカルDBのトランザクション管理、楽観的UI更新、自動ガベージコレクションなど、バックエンド/クライアントエンジニアの高度な協調を要求します。デザイナーはどうエンジニアを巻き込むべきか？

——

マルチプラットフォーム（大画面化）の本質的理解 「Mac版の3カラムでコンテキストを並列化する」というくだりは、本記事の白眉です。 「スマホの画面が狭いからモーダルを積む」というUI実装の妥協が、実は「端末の物理制約のツケを人間のワーキングメモリに払わせている」という暴挙であると看破した点は鮮烈です。 「画面が広がったとき、モードレス設計はスタックを並列化できるが、ウィザードはステップが拡大されるだけ」という指摘は鋭いです。レスポンシブ／マルチプラットフォーム設計の本質が「レイアウトの調整」ではなく「コンテキストの空間配置」にあることを的確に突いています。 レスポンシブWebやマルチデバイス対応を単なる「リサイズ」や「グリッドの再配置」として捉えるのではなく、「ユーザーのワーキングメモリに押し込められていたスタックを、物理画面の面積を使って外部記憶装置として展開する行為」として再定義しています。この視点は、OOUIがなぜPC黎明期（MacintoshやSmalltalk）から支持されてきたのかという歴史的必然性とも美しく符合します。 「レスポンシブデザインとはCSSのメディアクエリではなく、時系列（スタック）を空間（並列）に変換する操作である」という定義は、マルチプラットフォーム開発者にとって教科書に載せるべきレベルの金言です。

「使いやすさ」という曖昧な言葉を使わず、「状態の保持コストを誰が払うか（システムか、ユーザーの脳か）」という明確な評価軸でUIを解剖した名文です。 多くのUI論争が机上の空論（Figmaのモックアップレベル）で終わる中、 - 抜粋のタイミング（再生中というリアルタイムなコンテキスト） - 1:n データの作成順序（章から作るか、プレイリストから作るか） といった「動的な状態管理」を実際に動く形で提示しているため、エンジニアやプロダクトデザイナーにとって逃げ場のない説得力があります。 Figma上で完結する見かけの「UI/UXデザイン」に対する強烈なアンチテーゼであり、エンジニアリング（状態管理・データモデリング）とデザインが不可分であることを痛快に示す優れた実践記です。