以前の会社で、私は会議に座り、製品に3年間含まれている機能を再設計するかどうかを議論していました。首相は私たちがそれを1人で残すべきだと考えました。 それから誰かが2021年のオリジナルデザインスペクションを引き上げました。その機能は、もはや存在しない問題を解決するために構築されたことが判明しました。 作業していたベンダーAPIは? 18ヶ月前に修正されました。 彼らは、私たちが彼らに与えたものをどのように使用するかを学び、誰も私たちが可能な限りそれを正しく再構築するべきかどうかを尋ねるために戻ったことはありません。 あの会議は私と一緒に止まりました 夫は 「必要が発明の母であるならば、ユーザビリティは父であるべきだ」これは、私が最近よく考えてきた言葉で、ユーザビリティは、最初のニーズが解決されてから長い間、時にはそのニーズが完全に変化してから長い間、製品をどのように変革し続けているかです。 何か書いた Products keep changing even when they look the same 今日乗っている自転車は、最初のバージョンと全く似ていないように見えます。それらの初期のデザインは不便で、不便で、実際には危険な種類でした。 進化したのは、使いやすさについての私たちの理解でした。より良い材料は、そうですが、精密なエルゴノミクスとバランスを向上させました。各世代は、人々が実際にこれらのものを乗っているのを見ることから学びました。 私はこのパターンを見続けています。最初のバージョンは必要性を解決します。それ以降のすべては? それは解決策を実行可能にすることです。 Why "it works" is a trap チームは「It Works」をターンラインのように扱います. Feature shipped, problem solved, next thing please. 機能が発送され、問題が解決されました。 しかし、「それが機能する」ということは、通常、ユーザが摩擦にもかかわらず目標を達成する方法を発見したことを意味するだけではありません。 私は、ユーザーが1つのアクションを完了するために3つの確認スクリーンをクリックする必要があるフローをしばらく前にレビューしていました。なぜ3つの確認?現在のチームの誰も私に言えませんでした。我々は古いチケットを掘り起こし、2年前、データ損失のバグがあったことを発見しました。 彼らは6ヶ月後にバグを修正しました。3つの確認スクリーンは残りました。なぜならそれが「効いた」ので、ユーザーはそれを乗り越え、ダウンオフは恐ろしくありませんでした。 それはユーザビリティが進化するのではなく、ユーザビリティが閉じこもっていることだ。 What actual evolution looks like 実際のユーザビリティの進化は、機能を追加することではなく、人々が実際にあなたが作ったものをどのように使用するかを基にした精製です。 ATMは、おそらく私が考えることができる最も明確な例です。ファースト世代のATMは、まずあなたに現金を与え、それからあなたのカードを返しました。シンプルで機能的で、必要性を解決しました。 後者のデザインは、最初にカード、次に現金の順序を逆転させたが、新たな発明ではなく、別の問題を解決しなかったが、人間が実際にどう振る舞うかではなく、機械論理が彼らがどう振る舞うべきかを示唆した。 同一のコア機能は、理論ではなく現実を中心に形作られています。 Why do products stop evolving? 私が見たことから、製品はいくつかの予測可能な理由で使用可能性を向上させない。 オリジナルデザイナーは去って行き、何故物事がやり方で動くのか誰も知らない。 メトリックは上手く見えますので、ビジネスケースはありませんが、ユーザーは問題に取り組むことを学んだばかりです。 システムは、一つを変えることで他の三つを壊すほどに相互に関連づけられ、小さな改善は危険すぎると感じる。 あるいは、チームは新しい機能に移行しました. 既存の機能を改善することは、次なるものを構築するよりもエキサイティングではありません。 Allare slowly eroding your product's usability. ゆっくりとあなたの製品の可用性を損なう。 What I've noticed about features that improve vs features that stagnate 常に改善し続ける機能は、通常、それらを大切にしている人がいます。オーナーは、人々がそれをどのように使っているかを観察し、小さな挫折に気付いて、改良を推し進めています。 停滞している特徴は孤児で、誰もももはやそれらを所有していません。彼らは「十分にうまく」働き、それは決して良くなることを意味します。 私が働いていたチームは、この実践を「採用レビュー」と呼んでいた。毎四半期、彼らは6カ月以上前にリリースされた機能を調べて、「今、人々はこれを実際にどのように使っているのか?」ではなく、「彼らはそれをどのように使っているのか」と尋ねました。 その後、彼らは実際の使用パターンに基づく改善を優先し、新しい機能リクエストだけではない。 刺激的な仕事ではありませんが、歳をとる製品と、歳をとるだけの製品の違いがあります。 When evolution goes wrong 時にはチームが過剰に正しくなり、ユーザーが苦労し、なぜその方法で機能するのかを理解せずにすぐに再設計するのを見る。 私はチームが不必要に複雑な流れのように思えたことを単純化するのを見た。三つのステップが一つになった。 割引率が3倍に この3つのステップは、ランダムな複雑さではありませんでしたが、ユーザーがより良い決定を下すのに役立つステッカーでした。 良い進化には、人々が何をしているのかだけでなく、現在のデザインがなぜ機能しているのかを理解する必要がある。 The products that never stop improving 私が実際に好きな製品は、必ずしも最高の機能を持っているわけではありません。 Google Search は、20 年間にわたってその基本的な目的を変えていないが、ユーザビリティは進化し続ける。Autocomplete、Instant Results、Knowledge Panels、およびFunctional Snippets. Each one is based on learning how people actually search, not how Google thought they would search. Google Search は、ユーザーが実際にどのように検索するかを学ぶことに基づいている。 Slack はチームチャットを発明しませんでした. 彼らはそれをどのように機能するかを改良し続けました. Threading, reactions, better notifications, smarter search. Small improvements that add up over time. これらは劇的な再発明ではありません。彼らは、本物の人々が製品を使用しているのを見ることに基づいて慎重で継続的な進化です。 What this means for how I think about design now Need は製品の最初のバージョンを作成する可能性がありますが、ユーザビリティの進化は、第 10 版があるかどうかを決定します。 私が今自分に尋ねる質問は、私が尋ねた質問とは異なります。それはまだ正しいためではなく、存在しているためだけに私たちは何を保持していますか? もはや適用されていない私たちの設計を形作った制約は何ですか? ユーザーは実際に修正することができることを取り組むために何を学びましたか? そして、おそらく最も重要な質問は、チーム内の誰が既存の機能を向上させ、新しい機能を構築するだけでなく、誰が責任を負うのかということです。 Something worth trying 数ヶ月ごとに、既存の機能を選択し、現在の技術、ユーザーの現在の理解、および現在のビジネスコンテキストで新鮮に設計しているふりをします。 同じようにデザインしていませんか? 通常、答えはノーです。そして、そのとき、次の質問は、「何があなたをより良くするのを止めているのですか?」です。 時には、それは本当の制約ですが、多くの場合、それはただの惰性です。そして惰性は、実際に製品を進化させるチームと競い合っているときに高価です。 Where I've landed on this ニーズは製品を発明するが、ユーザビリティはこれらの製品が関連しているかどうかを決定する。 発明はあなたを市場に連れて行き、進化はあなたをそこにとどめる。 これを手に入れるチームは、単に船を運んで移動するのではなく、実際に何が起こっているのかを観察し、それから学び、改善します。 特に、実際に動いているときには。 Because "working" is just the starting point for what a product can become. なぜなら、「働く」ことは、製品が何になれるのかの出発点にすぎないからだ。

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

なぜ「機能する」が製品デザインで最も危険なフレーズなのか

About Author

コメント

ラベル

この記事は

Related Stories

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

タップして稼ぐ：テレグラムはソラナより先に次の100億人の暗号通貨ユーザーを獲得する可能性がある

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

タップして稼ぐ：テレグラムはソラナより先に次の100億人の暗号通貨ユーザーを獲得する可能性がある

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps