デザイン理論:計画、リソース、コミュニケーションの問題について

デザイン理論:計画、リソース、コミュニケーションの問題について
<br />多くの中小企業ではこの問題は発生しません。中小企業はデザイナーをサポートし、後押ししてくれます。デザイナーは結果を出せるかどうか心配する必要はありません。なぜなら、あなたがやらなくても、上司、エンジニア、同僚など、あなたの後ろには自然と後押ししてくれる人たちがいるからです。この結果は、全員が力を合わせて努力した結果です。
しかし、多くの大企業では、プロジェクトが多すぎて、親が面倒を見ることができないほど子どもがたくさんいます。プロジェクトが多すぎて、上司が対応しきれません。彼らは最終結果だけを見ています。なぜデザイナーの中には、1 年にこれほど多くのプロジェクトを行う人がいるのでしょうか?利益率の高いプロジェクトがこんなにたくさんあるんですか? なぜデザイナーの中には、1 年間にあまり作品を生み出していない人がいるのでしょうか?あなたが取り組んでいるプロジェクトのほとんどは途中で失敗したり、途中で消滅したりしますか?
プロダクトマネージャーがリーダーであれば、それで問題ありません。プロダクト マネージャーはさらに大きな評価のプレッシャーを抱えており、彼らの主な焦点は結果を押し進めることです。彼らのプレッシャーの下で、デザイナーは妥協し、妥協点を見つけます。プロダクト マネージャーはさまざまなリソース (エンジニア、テスターなど) を管理する責任があり、その後結果が出ます。
しかし、重要なのは、UX デザイナーとして、PD のニーズに常に受動的に応じるわけにはいかないということです。つまり、彼らが望むことを何でもして、彼らの「ビジネス目標」によって推進されるプロジェクトに 100% のエネルギーを注ぐ必要があるのです。ユーザー エクスペリエンス デザイナーとして、Web サイトをよりフレンドリーで使いやすいものにするために、いくつかのプロジェクトを自発的に開始し、改善するための独立したエネルギーを持つ必要があります。
ここに鍵があります。デザイナーは、PD のニーズに受動的に応じることを好まず、一部のプロジェクトをリードしたい場合があります。ただし、デザイナーが開始または主導するプロジェクトでは、結果を得るのが難しいことがよくあります。現在の状況は次のようになります。構築期間が非常に長い (優先度が非常に低く、ほとんど無視できる)。リソースのサポートがありません。結局のところ、プロジェクトにはチーム、エンジニア、フロントエンド開発、テストが必要であり、一人で戦うことは不可能です。長い間確認がなく、いつ作業を開始すればよいかわかりません。
たとえプロジェクトがプロダクトマネージャーによって開始され、プロダクトミーティングでそれがどれだけの利益をもたらすかを述べ、上司がうなずいたとしても、プロジェクトを優先順位付けし、設計リソースとエンジニアリングリソースを待つ必要があります。 「このエクスペリエンスは良くないので、これを変更したい」と単純に言うデザイナーの要求は言うまでもありません...
なぜ結果が得られないのでしょうか?
「体系的な改善計画を作成しました。これは間違いなく、既存のものよりはるかに優れていると思います。周りの同僚にテストを依頼したところ、全員が良いと言い、できるだけ早くオンラインでリリースすることを楽しみにしています。しかし、需要アナリストと評価した結果、開発に30人日以上かかることがわかりました。優先度から判断すると、年末までかかる可能性があります。そのためのリソースがありません...」
「あるページに大きな問題があると感じたので、分析と改善を行いました。そのページの領域はさまざまな製品ラインに分かれており、それぞれ異なる製品マネージャーが責任を負っていることがわかりました。自分のデザインを宣伝するためには、複数の関係者とコミュニケーションを取る必要がありました。彼らからたくさんの意見をもらいましたが、その中にはまったく正反対の意見もありました。このような変更がどのような結果をもたらすかまったくわからなかったので、そのまま放置しました...」
「あれは使いにくいと思いますか?その通りです。変更したくないですよね?すでに計画のいくつかのバージョンを公開していますが、問題は同じです。第一に、リソースがないこと、第二に、関係者が多すぎることです。変更することができないため、現状維持となっています。」
もちろん、結果が出ない言い訳や理由はたくさんあります。デザイナーとして、私はそれらすべてに共感できますし、私自身もそれに遭遇したことがあります。
分析の結果、すべての原因は「計画、リソース、コミュニケーション」の問題に起因することがわかりました。 設計案自体に問題がある(潜在的なリスクがある、投資額が高いのに成果が低い、それ自体が無理など)。設計案に問題はないが、リソースが逼迫していて投資できないため、当然成果が出ない。設計案に問題はないが、複数の関係者間のコミュニケーションがスムーズに進められず、棚上げになっている。
このとき、矛盾が生じます。優れた設計プランを提供しているのに、なぜリソースからの応答が得られないのでしょうか? 論理的に考えると、十分に優れたプランであれば、優先度が高く、すべての関係者からサポートされるはずです。優れたデザインであるなら、なぜ伝えるのがこんなに難しいのでしょうか?現時点では、良いデザインが出るまで待つべきでしょうか、それとも他に方法はあるのでしょうか?
私たちのデザインが優れていると思うとき、妥協するのは難しいのです
前のページ1 2 3 4 5 次のページ 続きを読む

<<:  JavaScript を使用してソートアルゴリズムを実装する方法

>>:  CSS3は子供のころの紙飛行機を実現する

推薦する

JavaScript キャンバス テトリス ゲーム

テトリスは非常に古典的な小さなゲームで、私もそれを書いてみました。しかし、できるだけ簡潔で論理的なコ...

vue keepAlive キャッシュクリア問題事例の詳細な説明

Keepalive は Vue プロジェクトでのキャッシュによく使用され、基本的な要件を満たすのに非...

パーソナライズされた検索エンジンを使用して、必要なパーソナライズされた情報を検索します

現在、多くの人がインターネット上で生活しており、インターネットで情報を検索することは日常的な作業とな...

完璧なアロエベラジェルを選ぶには?完璧なアロエベラジェルの本物と偽物の見分け方

最新のパーフェクト アロエ ベラ ジェルのパッケージ ボックスには、赤いフォントで完璧な英語の文字が...

VMWare Linux MySQL 5.7.13 のインストールと設定のチュートリアル

この記事では、参考までにVMWare LinuxにMySQL 5.7.13をインストールするチュート...

React双方向データバインディングの原理についての簡単な説明

目次双方向データバインディングとは双方向データバインディングの実装データ影響ビュービューはデータに影...

HTMLとCSSを使用して、自分だけの暖かい男「Dabai」を作成します

最終結果はこんな感じです、かわいいでしょう… PS: HTML と CSS の知識があればベストです...

Vue は書籍管理ケースを実装します

この記事では、書籍管理を実装するためのVueの具体的なコードを例として紹介します。具体的な内容は次の...

docker run 起動パラメータ コマンドを表示する方法 (推奨)

runlike を使用してコンテナの docker run 起動パラメータを表示します。 pipを...

マウスを動かしたときに画像のズーム効果とゆっくりとした遷移​​効果を実現するCSSのサンプルコード

transform:scale()比例したズームインまたはズームアウトを実現できます。 transi...

最も完全なpackage.json分析

目次1. 概要2. 名前フィールド3. バージョンフィールド4. 説明フィールド5. キーワードフィ...

Vue での ref の使用法とデモンストレーション

ref 定義:要素またはサブコンポーネントの参照情報を登録するために使用されます。参照情報は、親コン...

win10 での mysql5.7.21 の詳細なインストール手順

この記事では、MySQL 5.7.21のインストールとインストール中に発生した問題を参考までに紹介し...

Linux 環境に MySQL 8.0 をインストールするプロセスの紹介

目次序文1. Linux は yum ソースを変更します (MYSQL のインストールが遅い場合は試...

Vue で Google サードパーティ ログインを実装するためのサンプル コード

目次1. 開発者プラットフォームの構成問題を解決する1. 開発者プラットフォームの構成1. 開発者プ...