多くのソフトウェアチームが、アジャイルプロセスにデザイン作業をうまく組み込めないかと苦労しています。他のチームメンバーと緊密に仕事をしていないデザイナーは、全員（自分たちも含む）に関わる余計な業務を作り出してしまうことがあります。また、製品チーム内でナレッジをサイロ化してしまう可能性があります。
Atlassian では、デザインプロセスにおいて、アジャイルチーム全体で協同作業を行うようにしています。全員がデザインプロセスに関わるようにすることで、問題に関する複数の視点を得て、ドキュメントに頼らずにアイデアを共有します。このプレゼンテーションではその方法を紹介します。
- チーム全体がデザインプロセスに関与する
- デザイン作業をアジャイルプロセスに統合する
- より早くテストやアイデア化を行えるように、カスタマーインサイトを得る
Q & A
こちらの Q&A の範囲は、Atlassian が使用するデザインツールから、カスタマーフィードバックの扱い方法に及びます。
Q1: デザイナーと開発者は常に違うメンバーなのですか? HTML5 や最新の UI テクニックを考慮すると、基本的なコーディングスキルを持たないデザイナーにとっては難しくありませんか?
A1: デザイナーと開発者の境界はあいまいになってきています。Atlassian にはエンジニアリングのバックグラウンドをもったデザイナーがいますが、コードを一行も書けないデザイナーもいます。当社には強力なビジュアル デザイナー、インフォメーション アーキテクト、およびファシリテーターがいます。全員が異なる強みを持っており、チーム内でそれらを認識して活用することが重要です。
Q2: プロダクトチーム以外のメンバーも、マーケティングなどのデザインワークショップに参加しますか?
A2: 当社のワークショップにはさまざまな分野の参加者がいますが、全員になんらかの理由があり参加しています。通常は PM、エンジニアリングやデザインなどの代表者ですが、別の観点を追加できる場合、サポートやマーケティングのメンバーを連れて来る場合があります。
ワークショップは数日間かかる場合があり、それはコミットするには長い期間です。私は前もってアジェンダをメンバーと共有し、彼らが価値を提供できる部分はどこか、数時間だけでも参加できるところはどこか考えられるようにしています。ただし、中心的なグループのメンバーは全日程に参加する必要があります。
Q3: スケッチ、図面作成、アイデア出しにどのようにメンバーを参加させていますか? PO や開発者はそのような作業を怖がったり、またその他の理由により、参加に積極的ではないと感じています。
A3: グループ内でアイデアを共有するだけでも怖いのに、公の場での図面作成はもっと怖いと思うでしょう。この理由から、私はワークショップのこの段階では大きなグループをペアに分割することを好みます。それによって目の前に白い紙を置かれるプレッシャーがなくなります。また、お互いにアイデアを出し合って、勢いを持続させるのにも役立ちます。
これらのセッションのいずれかに参加した後、誰もがプロセスになれ、参加を本当に楽しむようになります。室内では常に多くの会話が行われ、ざわめきます。
また、あなたが傑作を求めているのではないということを、全員に知らせることも重要です。その後あなたがすべきことはアイデアの視覚化です。これはインターフェイスのスケッチや図面、箇条書きなど、グループの他のメンバーが共通の理解を得るのに役立つあらゆる形で行うことができます。もし紙に書き出した場合、ワークショップ終了後に参考用として保存しておく必要もあります。
Q4: どのようにして、デザインチームの新しいメンバーに最新情報を提供していますか?
A4: デザイン チームの新メンバー全員に新人研修を実施しています。最初に、Atlassian におけるデザイン、プロセス、およびプロダクト チームのメンバーとどのように作業しているかを紹介します。それから、私たちが開発したデザインの原則を説明し、これらがどのように実践されているか具体例を示します。ペルソナの使用、Atlassian Design Guidelines および Playbook など、当社のデザイン リソースの詳細を学べるブート キャンプ クラスもあります。
また、最初の数週間、新人デザイナーにバディを組ませてペアにしてコツを教え、もっと大きな仕事に徐々に慣れてもらいます。
新人デザイナーのスピードを上げるもう一つの方法として、第 1 週目の間にワークショップに参加させる方法があります。プロダクトチームと顔を合わせ、彼らとどのように協力して仕事をしているかを実際に体験するよい機会です。最初の数ヶ月で学習することは多数ありますが、ワークショップはひとくちサイズの問題に取り組むのに最適です。
Q5: カスタマーリサーチ手法の中で、何が一番役に立ちますか？現地調査、観察、ユーザビリティ調査？
A5: すべてのタイプのカスタマー リサーチが有益だと思いますが、プロジェクトのさまざまな段階で、さまざまなタイプのリサーチが行われます。
例えば、プロジェクトの初めでは、メンバーが取り組んでいる問題や内容を完全に把握したい場合があります。コンテキスト調査はこれに非常に役立ちます。チームの職場を訪問して彼らのプロセス、問題が彼らに与えている影響、効率を上げたいのは何かについて彼らと話します。彼らがタスクをどのように達成しようとしているか、および彼らが遭遇したフラストレーションを実際に目にするのは素晴らしいことです。
ユーザーテストと顧客インタビューは、アイデアを少し掘り下げたいときに適しています。簡単なプロトタイプを使用して、ユーザーがフロー上をどのように移動するかを確認したり、提案されたソリューションについて会話するだけでも価値ある洞察を得ることができます。
一方、A/B テストはソリューションの効果を計る素晴らしい方法です。
Q6: Atlassian のデザイナーはどのようなツールを使用していますか?
A6: Atlassian のデザイナーはそれぞれの仕事に適したツールを使用しています。昔ながらのペンと紙の場合もあれば、HTML と CSS を使用する場合もあります。
忠実度の高いデザインを作るため、ほとんどのチームは Sketch を使用していますが、Adobe 製品も使用しています。基本的なレイアウトをとても簡単に作成できるように、Atlassian パターンライブラリのすべての UI 要素はベクターオブジェクトとしてとして作成されています。シンプルなプロトタイプでは、InVision や Marvel を使用します。より複雑なインタラクションでは、Framer Studio、Origami、Axure、または手書きコードを使用します。
また、付箋やホワイトボードマーカーも大量に使います。:)
Q7: アジャイルのワークフレーム内で作業をする間、どのような問題に直面しますか?
A7: 完璧さを手放すかわりに短期間で何かを作り出したり反復的作業を行うことを学ぶのが、もっとも難しい挑戦です。デザイナーは常に高品質の作品を作りたいと願いますが、90% のものをリリースし、その後で改善するといったやり方に慣れる必要があります。
Q8: ドキュメントを減らすいくつかの方法について説明していただきました。どのような形式でドキュメントを保持していますか? あるいはすべてのドキュメントをなくしましたか?
A8: 当社では Confluence を使用して進捗状況を共有し、幅広いチームからフィードバックを集めています。ページには通常、解決しようとしている問題に関するコンテキストと、解決方法の提案およびその価値が記載されています。スケッチ、忠実度の高いモックアップ、プロトタイプへのリンクなどをページ内に記載し、ソリューションを示します。ユーザーはコメントや質問を投稿し、デザイナーはプロジェクトの進捗に応じて最新のデザインを投稿します。「ドキュメントの保持」と呼べるかわかりませんが、そこにデザイン資産とフィードバックを集めて、ページを「進化」させるようにしています。
Q9: チームメンバーが同じ場所におらず、デザインが分散している場合、どのようなアプローチをとりますか?
A9: Atlassian はグローバルな企業です。そのため、分散したチームでの作業は日常茶飯事です。Jira では、シドニー、グダニスク、サイゴンにチームがあり、私たちは常に距離を縮める方法を探しています。テクノロジーは多いに役立ちます、 Hipchat ではビデオ会議やメッセージ、Confluence では作品の投稿、共有、コメント、および Jira ですべての作品を整理します。ただし、それでも完璧ではなく、直接顔を合わせたコミュニケーションに勝るものはありません。可能であれば、プロジェクトの重要な部分においては同じ部屋に集まってもらうようにしています。それができない場合は、遠隔地にいるチーム メートとコミュニケーションを密に取り、絶えず情報を伝えるよう最善を尽くします。
Q10: 「顧客フィードバック」になりすます「ノイズ」をどのようにコントロールおよびフィルタリングしていますか?
A10: 当社では素晴らしいことに、多数の顧客フィードバックを受け取ります。当社にはユーザーのコメントを収集し、Jira プロジェクトに課題として保存する feedback ツールがあります。私は一日の最初に、コーヒーを飲みながら最新の課題に目を通します。コメントを見ながら、新しく出現した共通のコメントやパターンをメモし、それらにラベルを付けて分類します。それらのラベルを使用してすべてのフィードバックをフィルタリングし、どのくらいの数のユーザーが同様の問題を提起しているかを見つけ出します。次に、パターンが確立されたら、この問題を解決できる具体的な使用事例とともにプロダクト チームに持ち込みます。
