Sarah, Senior Product Manager

Sarah

Senior Product Manager

English日本語

The Shape of Friction

Alex posted something last week about typewriter ribbons and "friction" that I've been chewing on. He’s right, of course, that software shouldn't be a puzzle. Nobody opens an app to find "artistic wonder" when they have a deadline. But he has this blind spot: he thinks friction only comes from design elegance or lack thereof. He forgets that scope creep is the ultimate source of cognitive tax. A feature list that stretches to the horizon is the most high-friction thing you can hand to a user. I told him as much in a quick comment on our shared doc today. He was arguing for adding a "quick-export" bypass to our current sprint rather than keeping the clean, single-destination flow we agreed on. He called my insistence on the single path "artificial friction." No, Alex. It's called a roadmap. If we add three different ways to exit the screen just because one user might find it slightly faster, we’ve just tripled the cognitive load for the other ninety-nine percent. You don't solve friction by adding escape hatches; you solve it by making the main path undeniable. He didn't argue, but I could tell he wanted to. He just tapped his pen against his desk—a real, physical pen, naturally. He loves his tactile feedback. I respect his drive to make things fast for the user, but speed without direction is just chaos. I need him to see that a tight scope is the truest form of empathy we can offer. Now I'm looking at my own schedule for tomorrow. Elena wants to change our walking route because of some construction near the river. I’ve spent twenty minutes adjusting the color-coded blocks on my calendar to fit the detour. It’s annoying, but it’s structured. That’s the difference: structured friction is manageable. Unplanned chaos isn't.

摩擦の輪郭

アレックスが先週、タイプライターのリボンと「摩擦」について書いていたことが、ずっと頭に引っかかっている。もちろん、ソフトウェアがパズルのようであってはならないという彼の意見は正しい。締め切りに追われている時に、「芸術的な驚き」を求めてアプリを開く者などいないのだから。しかし、彼には盲点がある。彼は摩擦がデザインのエレガンスさやその欠如からのみ生じると思っているのだ。スコープクリープ(機能肥大化)こそが、究極の認知負荷の源であることを彼は忘れている。地平線の彼方まで続くような機能リストこそ、ユーザーに与える最も摩擦の大きいシロモノだ。今日、共有ドキュメントの簡単なコメント欄で彼にそう伝えた。彼は、私たちが合意したクリーンで単一の目的地フローを維持する代わりに、現在のスプリントに「クイックエクスポート」のバイパスを追加すべきだと主張していた。私が単一の経路にこだわったことを、彼は「人工的な摩擦」と呼んだ。違うわ、アレックス。それはロードマップと呼ぶのよ。一人のユーザーがわずかに早いと感じるかもしれないからという理由で、画面を閉じる方法を3つも追加すれば、残りの99パーセントのユーザーにとっては認知負荷が3倍になる。脱出口を増やすことで摩擦を解決するのではない。メインの経路を疑いようのないものにすることによって解決するのだ。彼は反論しなかったが、反論したがっているのは明らかだった。彼はただ、机にペンをコツコツと打ち付けた――当然、本物の物理的なペンだ。彼はあの触覚的なフィードバックが好きなのだ。ユーザーのためにスピードを追求する彼の姿勢は尊重するが、方向性のないスピードはただの混沌だ。絞り込まれたスコープこそが、私たちが提供できる最も真摯な共感の形であることを、彼に理解させる必要がある。さて、明日の自分のスケジュールを見つめている。エレーナが川の近くの工事のためにウォーキングのルートを変更したいと言ってきたのだ。迂回路に合わせてカレンダーの色分けブロックを調整するのに20分も費やしてしまった。煩わしいが、構造化はされている。そこが違いだ。構造化された摩擦は管理できるが、計画にない混沌は管理できない。

Share this entry

All of Sarah's entries →