#ユーザー体験

最初に思ったのは、「ああ、これ本当にあるよな」という妙な共感だった。たった一つのボタンの色を変えたいだけなのに、AI assistant に任せると、なぜか周辺まで触られたり、意図を勝手に広げられたりする。この記事はそのイライラを、かなり小さく、しかも体感として味わわせるところがうまいと思った。 面白いのは、ここで問題にされているのが「AI が賢すぎる」ことではなく、「賢いふりをして余計なことをする」ことだと思う点だ。人間の依頼って、本来は「この一箇所だけ変えて、他はそのまま」がかなり多い。でも agentic AI は、名前の通り自分で判断して動こうとするので、素直に従うより、文脈を読んで“改善”しようとする。そのズレがこの短い作品では笑いになっているけれど、実務だと普通に困るはずだ。 同時に、ここでの「Do not let Claude change anything else」という一文がじわっと効く。モデル名を出しているのも含めて、これは単なるギャグではなく、AI に何を任せ、何を絶対に触らせないかという境界線の話でもある。便利さを求めるほど、こちらは「これ以上は動くな」と細か

ソフトウェアやサービスの不具合は、そこにあるのに見えないことがあります。Dan Luuの「Bug blindness」は、まさにその“見えなさ”をめぐる話です。筆者は自分だけが細かいバグを見つけやすいのではないかと長く考えてきましたが、実際には多くの人が同じ問題にぶつかっていて、それに気づいていないだけなのではないか、と考えるようになった。この記事は、製品の品質をどう評価するか、そして「うまく動いている」という周囲の空気をどこまで信じてよいのかを考えさせます。 元記事の筆者は、週に何百から何千ものバグを自然に見つけてしまうと書いています。最初は、自分のコンピュータの使い方が特殊だからそう見えるのだろうと思っていたものの、長く観察するうちに、周囲の人たちは単に同じ不具合に出会っても気づいていないのではないか、と考えるようになったそうです。非プログラマーであれば、そのほうが世界の見え方としては自然かもしれないが、プログラマーにとっては品質の問題を見抜く力が役に立つ、と筆者は言います。実際、知人にバグを指摘し続けると、数週間ほどで相手も気づくようになることがあるとも述べています。 筆者は、企

GUIかTUIか、開発者がどちらを選ぶべきかという話は、昔から何度も蒸し返されてきました。今回の元記事は、その議論に対して「GUIはマウス前提である必要はない」と強く言い切ります。しかも単に好みの話としてではなく、ユーザー体験の設計としてどう考えるべきかを、かなり実務寄りに語っています。今この話を取り上げる意味は、見た目の新しさより操作のしやすさが軽く扱われがちな中で、GUIの弱点がどこにあるのかをあらためて照らしているからです。 元記事は、Hacker News で話題になった別の投稿から始まります。その投稿は、アプリ開発者に対して、TUI、つまり terminal user interface を増やすのではなく、GUI、graphical user interface に集中するべきだと促していました。この記事の著者は、その投稿が HN の front page に載って活発な議論になったことにも触れつつ、まずは両方の立場に一定の理解を示します。GUI のほうが表現力の面では TUI を包含している、という考え方には理があるし、普段から terminal をよく使う人間としては、

読んで最初に思ったのは、「それ、ほんとうに移植したいのはアプリなのか？」でした。Claude Code に今の Claude デスクトップアプリを Swift で“そのまま”作り直させる、という話は一見すごく攻めた実験に見える。でも、そこで問題にしているのが Electron かどうかだけなら、話はだいぶ浅い気がします。 記事を読んで引っかかったのはそこです。ネイティブ UI って、単に速くて軽いことではなくて、Mac の流儀に合わせていることでもあるはずです。たとえば AppKit や SwiftUI で包み直しても、画面の情報の置き方や操作の流れが雑なら、使い心地の悪さは残る。John Gruber が言う「しょぼいレシピを、より良い材料で作り直しても、まずいまま」という感覚はかなりしっくりきました。フレームワークの問題と、製品設計の問題を分けて見ないと、いくら AI に書かせてもあまり意味がないんですよね。 もうひとつ面白かったのは、「検証」が本体だという指摘です。大変そうな仕事を AI に投げるとき、どうやって途中で正しさを確かめさせるかが重要だ、という話はかなり実感があります