設計プロセス：ソフトウェア開発のプロセスに開発者を参加させるのに最適な時期はいつですか？
私は小規模なソフトウェア開発スタートアップのUXデザイナーです。
今までは、インターフェースの作成当初から開発者と一緒に仕事をしてきました。技術的に不可能であるため、最後に開発できないことを発見するために多くの機能やインターフェースに取り組む時間を無駄にしたくないからです。
また、プロセスの最初のステップ以降に遭遇した設計上の問題を開発者と共有すると、彼らが私に取り組んでいるのを見ると、彼らはプロジェクトにより深く関わり、より簡単に共同作業できるようになると思います終わり。
これまでは、この方法で作業できました。完璧に。私は本当にデザインを気にしない開発者とチームにいたので、それは簡単で効率的でした。私のコードを信頼していたので、彼らは私の推薦を信頼してくれました。私たち一人一人が彼の仕事をし、ピンポンコミュニケーションゲームのように他の人と共有しました。
今日、私は別のチームと別のアプリ開発プロジェクトに取り組む必要があり、それは非常に複雑でした。ここでは開発者はデザインに関心がありますが、彼らはデザイナーではなく、優れたデザインをどのように行うかを知りません。それで彼らは私にユーザーのためではなく、彼らのためにインターフェースを変えて欲しいと思ったのです。彼らは彼らが好きなように見えるインターフェースを選択するでしょう。しかし、彼らは最終的なユーザーではありません。
だから今、私は彼らとどのように協力するか、または私のモックアップをチームと共有する方法についていくつか大きな疑問があります。設計に関心を持つ開発者がいるのは良いことなので、私は彼らに苛立ちを感じさせたくないのですが、彼らがやりたいから、またはコーディングが簡単だからという理由で、好きなことを彼らにさせることはできません。彼らはUIフレームワークが好きで、作業中に何かを変更したくないからです。
私にとって、私はUXデザイナーなので、最終ユーザーが優先されます。私の見解が彼らの見解よりも優れているとは言いません。私が欲しいのは、私たちのアプリケーションを作成するための唯一の同じ方法です。チームの視点は1つだけです。一緒。
コミュニケーションの方法、または私を助ける良い設計プロセスについて何かアドバイスはありますか？
Sharing Mockupsステージが遅すぎます
開発者が完全に関与し、設計の背後にある理由と決定を理解したい場合は、それらをX Design Workshop-モックアップが行われる前
私の典型的なワークショップでは
- 関連するユーザーストーリーを見る
- ユーザーが考えるアイテムの概念
- ユーザーストーリーの目標をサポートする複数のUIアイデアを実行する[したがって、開発チームのアイデアに対するあなたのアイデアではありません]
- ペルソナに対するUIのヒューリスティックレビュー[これにより、開発者はユーザーの心の中に入れられます]
- ペルソナに最適なUXを備えたUIを選択してください
- 会議を閉じて、「本番準備」モックを実行します
平均サイズのユーザーストーリーの場合約90分
occasionでは、「プルランク」を設定して、確実な操縦を行う必要があります。少なくともその理由については良い対話があります。開発チームが非常に情熱を傾けていた貧弱な設計を故意に通過させました。ユーザーのテストは私が期待したとおりでした。その後、チームはそのデザインの改善だけでなく、他のデザインの提供にも非常に熱心でした。
あなた自身の質問に対する答えを幾分発見しました。設計プロセスに開発を含めるのに最適なタイミング使用している開発チームによって異なります。
あなたの最初の直感は正しいです...後でより早く開発者を入れてください。理想的には、これらは最初から設計プロセスの一部です。彼らは、ソリューションに大きく貢献できる洞察とアイデアを持っています。そして、あなたが指摘するように、彼らはまた、プロセスの後半でキャッチされた場合、将来の主要なUXの変更を必要とするであろう大きな「雑談」を前もってキャッチすることもできます。
ユーザーの観点から必ずしもUIについて考えているわけではない開発者がいる現在のシナリオについては、それがあなたの課題だと思います：開発者にUIを考えさせる- serが使用します。
開発者からUIの変更を提案されたときはいつでも、ソフトウェアを使用しているユーザーにどのように役立つかを彼らに尋ねてください。これにより、会話を開発者の目標ではなく、顧客の目標に向けることができます。
すぐに。さまざまな理由により、他の人からは決して得られないという洞察が得られます。技術的な制限に非常に早くフラグを立てることができます。プロジェクトに感情的に執着するようになります。
ビルバクストンによると、「私たちはすべてデザイナーではありません」とはいえ、「私たちはすべてデザインプロセスに参加する可能性があります」が、デザインは「数学や医学のような職業」であり、経験と知識なしには実行できません。
設計者は可能なすべての貢献を処理して評価する必要がありますが、最終的な設計は設計者の役割と責任です。
中小規模の企業で働く多くの開発者は、彼らもデザイナーになることができると信じています。残念ながら、この信念は通常、彼らの自我と結びついており、これはそれを変えるのを難しくしています。
したがって、デザイナーと開発者の役割を区別するために、いくつかのプレゼンテーションを行ったり、関連記事を送信したりして、会社のデザイナー文化を確立するように努める必要があります。
ただし、開発者からの可能なデザインの貢献を高く評価し、奨励する必要があります。また、製品開発において非常に重要な創造的活動であるソフトウェアを開発することで、開発者が最も得意とすることができることに対して、報酬と評価を与える必要があります。
次のBill Buxtonの図は、製品開発のフェーズを示しています。
革新的なデザインを作成する場合は、プロジェクトの開始時にエンジニアの役割を最小限に抑えます。
参考：
Bill Buxton、ユーザーエクスペリエンスのスケッチ（2007）
私は平均的なルタバガとほぼ同じデザインの才能を持つ開発者です。
あなたは間違った質問をしているのではないかと思います。おそらく「デザイナーとして、私のチームの開発者の信頼を最も早く得るにはどうすればよいですか」と尋ねる必要があります。
私が一緒に仕事をしたほとんどの「デザイナー」は、彼らがデザイナーになったと経営陣から言われ、どのツールを使用するかなどの社内ルールブックが与えられた開発者でした。彼らのマネージャーはそれらの使い方を知らず、彼らはコードを生成しなかったので、生産性を測定する方法を知っています。
開発者がこのような環境の出身である場合、あなたは彼らの信頼を勝ち取るために深刻な困難を抱えています。
私は最近、本当にその名にふさわしい優秀なデザイナーと仕事をする機会がありました。私の芸術的能力が1から10のスケールでsqrt（-1）を測定することを知っているので、彼はすぐに私の信頼を勝ち取りました。彼は私の提案を聞いて取り入れましたが、それらを本当に見栄えよくしました。
私は開発者であり、私のチームのデザイナーは私たちとかなり密接に協力しています。私たちはそれをセットアップして、デザイナーがデザインを私たちに与えたときに質問を出し、入力を与える機会を持っていますが、決定が確定しているとき、デザイナーは決定を下し、投票は獲得しません。
気にする人から入力を得るが、だれが入力を提供するのか、誰が決定を行うのかの間の明確な境界を確立します。
開発者が製品に情熱を注いでいる場合、彼らはあなたに良いアイデアを与えることができるかもしれませんが、彼らはチームのデザイナーではないことを知る必要があります。