設計が製品開発に関与していることを確認する方法
いくつかの開発チーム、プロダクトオーナーチーム、デザインチームがあります。
POチームは通常、ユーザーストーリーと許容基準を記述しながら設計チームと協力し、通常は開発者がそれを構築することに関与し始めます。
私たちが発見した問題は、POがデザインに関与する必要があると考えず、デザインに関与しないこともあり、デザインに関与せずに開発を正しく実行できることです。
誰かが解決策を持っていますか、この問題をどのように解決できるかについての資料やアイデアを読んでいますか？.
デザインはフロントエンド開発者と一緒に機能する必要があると思いますが、いくつかのアドバイスが必要です。
これはおそらく、ほとんどのデザイナーが少なくとも一度はキャリアで直面したシナリオです。比較的小さな問題のように見えても、そうではないと思います。私が見つけたのは、最初はそれほど明確ではないトピックがいくつかあるということです。この問題では、以下のシナリオの一部またはすべてが非表示になる可能性があります。
- PM/POは生産的でなければならず、正当化のために結果を引き渡さなければなりません
- PM/POにはデザインの背景が（ない）あり、視覚的な方向を自分で決定できると考えています。これは「小さな問題」に過ぎないためです。
- 開発チームは実行したいだけでなく、自分自身を創造したい
- デザイナーは良くない/コミュニケーションが取れない/時間がかかりすぎる/一部のタスクに適切な結果が得られない/ ...
- ...
私が指摘したいのは、感情が関与していること、何らかの形で参加したいと思っていることです。 only（そして、私がいくつかの解決策をかなり試したと言ったら、私を信じてください）私が見つけたその問題の永続的な解決策は次のとおりです：
ビジュアルを含むすべてのチケットにはデザイナーの目が必要です。開発も含むすべてのチケットには、開発者の目が必要です。最後ではなく、最初に
これにより、POは最大で実行する必要がある作業量を決定でき、設計者は関与する必要があるかどうかを決定でき、開発者は概念を実行できるかどうか、および割り当てる必要がある時間を決定できます。これにより、期待を最大限に管理できます。
一方、これを行わない場合は、PO/PMに「十分に良い」ビジュアルを決定するタスクを与えます。これは彼女の専門知識の一部ではありません。まあ、彼女はデザイナーではないからです。実行したい機能を決定し、開発者に尋ねたことがない場合は、実行できない機能の設計時間に投資する可能性があります。
したがって、JIRA/Trello/Asanaまたはチケットツールを同様に使用している場合：ブリーフィングの後に必ずステップを含め、設計チームのリーダーが決定します：「これは設計トピックです」または「これは設計トピックではありません」。これにより、すべての関係者がそれぞれの専門知識を尊重しながら、問題が発生したことを確認できます。そして、それはそれほど多くの作業ではありません（定期的にチケットあたり2〜4分）
検討できるモデルの1つは利害関係者もデザインチームのユーザーですです。それらをユーザーのように扱います。それらをあなたの思考の中心にし、同じ種類のツールを使用して素晴らしい同僚体験を作成します。 CXとUXを正しく利用するには、同僚の経験を含める必要があります。同僚がデザインをサポートしていない場合、ユーザーに優れたエクスペリエンスを提供することはできません。
組織のデザインに対する態度はトップダウンであることに気付くでしょう。主要な利害関係者を教育し、その価値を少しずつ伝えましょう。 -Forrester（CXEU2015）によると、CFOの90％はカスタマーおよびユーザーエクスペリエンスチームがコストセンターであると考えています。チームの仕事の一部は、価値と利益を生み出す方法を示すことです。
私は有名なブランドのPO/PMをしている間、この期間を経てきました。チームでお互いに話し合う粘り強さがなかったこの問題がありました（態度の問題/仕事のプレッシャー/時間の不足）で機能することが求められたため、機能横断は絶対に必要でしたコラボレーション環境。メール、会議、電話相談は問題を解決しませんでした。主な被害者は、すべての機能の実装がもたらすROIの管理に対応できる製品チームでした。私は、経営者との協議の後、次のプロセスを思いつきました：
- POは、計画された主なプロジェクトドキュメントを内部ナレッジベースにアップロードするために使用され、提案はすべての利害関係者（技術、設計、運用、サポート）から求められました。 TLは、フォーラムの提案/クエリ/レビューで元に戻したり、マスタードキュメントに承認/承認のサインとしてデジタル署名したりするために使用されていました。
- 必要に応じて、問題を整理するためにメールまたは会議を一定の間隔で開催し、POが議長を務めました。
- 内部ポリシーが適切に維持されていることを確認するために、すべての関係者が（POとともに）デジタル署名する必要があるベストプラクティスドキュメント。
- ここで説明する必要のない他の重要なステップもいくつか実行されました。
かつては別々のチームがゆっくりと着実に結束したユニットになり、UX、CX、Techの問題が実装段階の前に確実に整理されるようになりました。
数か月後、内部調査により、設計チームを含む他の利害関係者（無視されている可能性がある）が計画段階自体にいくつかの重要な貢献/付加価値（提案の形）を行い、全体的なUXを改善していることが明らかになりましたおよびCX。
私が提案するのは参加のアーキテクチャを作成し、シームレスなプラットフォームを内部で作成する従業員向けの社内ポリシーの形で、他の人を迂回する絶対的な権限を持たないようにすることです。エゴを倒して、コラボレーションを勝ち取りましょう！そして、ブラウニーポイントが均等に分散されるようにします。
すべての分野に関与する発見および定義段階。すべての関係者からのコラボレーションが期待されることを明確にします。
すべての製品ミーティングに参加してください。リストに載らない場合は、表示してください。実際にあなたを追い出す社会的勇気を持つ人はほとんどいません。
価値をもたらす。エンジニアリングからの入力を重視するように、彼らはあなたがもたらす洞察を重視し始めます。
一緒に出てください。チームランチやビール、登山をしてください。グループが接続できるものは何でも。
すべては社会化のプロセスです。彼らがあなたが彼らの製品をより良くする方法を理解していないなら、彼らはあなたを巻き込まないでしょう。