デザイナーとコーダの溝を埋める、テクニカルディレクションにおけるXDの活用事例

2018/12/16 の札幌 Adobe XD meetingで発表したスライドです。

Transcript

1. デザイナーとコーダーの溝を埋める テクニカルディレクションにおける XDの活⽤事例 1 2018/12/16 札幌 Adobe XD meeting #01
2. 半⽥ 惇志 ➤ ձࣾɿ24-7/ύϯη ➤ ςΫχΧϧσΟϨΫλʔ/ γχΞΤϯδχΞ ➤ ϒϩάɿThinking Salad ➤ ཆ໋ञ͸͡Ί·ͨ͠ 2
3. #SBDLFUTָ㥨ֹ麓ֺג劤׾⳿׃ת׃׋կ 3
4. 13&$44׮⡲׶ת׃׋կ 00$44ծ4."$44ծ#&.׾ك٦أח׃׋ ⚥鋉垷⟃♳ぢֽ$44،٦ؗذؙثٍ IUUQQSFDTTJPKB 4
5. 5 ϚʔΫΞοϓઃܭʹ͓͚Δ9%ͷ࣮ྫ ςΫχΧϧσΟϨΫλʔ͕ඞཁͳཧ༝ ͜Ε͔Β໨ࢦ͢΂͖ϫʔΫϑϩʔ
6. ςΫχΧϧσΟϨΫλʔ͕ඞཁͳཧ༝ 6
7. テクニカルディレクターの仕事 ➤ インフラの選定 ➤ ⾔語・フレームワークの選定 ➤ 要件→実装への落とし込み ➤ WFのチェック ➤ ミドルウェア・CMSなどの選定 ➤ 開発環境に使⽤する技術の選定 ➤ エンジニアのための情報整理 7
8. ひと⾔でいうと プロジェクトにおける技術的な 判断と整備をする⼈ 8
9. テクニカルディレクターの仕事 ➤ インフラの選定 ➤ ⾔語・フレームワークの選定 ➤ 要件→実装への落とし込み ➤ WFのチェック ➤ ミドルウェア・システム（CMSなど）の選定 ➤ 開発環境に使⽤する技術の選定 ➤ エンジニアのための情報整理 9
11. 11 頻繁に編集するなら 更新しやすい仕組み作る？ ・⼿動更新？⾃動更新？ ・ブログ？カスタム投稿タイプ？ ・横⻑のやつは⾃動？⼿動指定？
12. テクニカルディレクターの仕事 ➤ インフラの選定 ➤ ⾔語・フレームワークの選定 ➤ 与件の実装への落とし込み ➤ WFのチェック ➤ ミドルウェア・システム（CMSなど）の選定 ➤ 開発環境に使⽤する技術の選定 ➤ エンジニアのための情報整理 12
13. 13 ϚʔΫΞοϓઃܭʹ͓͚Δ9%ͷ࣮ྫ
14. 本スライドの登場⼈物 14 ディレクター デザイナー テクニカルディレクター
 （TD） コーダー
16. デザイナーの思考例 16 ➤ それぞれ異なるコンポーネント ➤ テキストのフォントサイズは共通 ➤ いいね・コメント数も共通
17. コーダーの思考例 17 ➤ フォントサイズは共通 ➤ いいね・コメント数も共通 ➤ →ここの部分だけでも共通化したい
18. コーダーの思考例 18 ➤ フォントサイズは共通 ➤ いいね・コメント数も共通 ➤ →ここの部分だけでも共通化したい ➤ しかしここの余⽩が明らかに異なる…
19. まずはテクニカルディレクターが⼊って、 全てのコンポーネントを洗い出す 19
20. DEMO 20
21. デザインプレビューから コンポーネントにプロトタイプ コーダーを迷わせない 21
22. この案件におけるワークフロー 22 デザイナー TD コーダー
23. この案件におけるワークフロー 23 ここで分解作業をめちゃめちゃ頑張る （つらい） XDがサクサク動くのが救い デザイナー TD コーダー
24. デザイナーとの共通認識を醸成する 24 ・コンポーネント整理したらこうなったんですよ ・ここの余⽩統⼀できると楽なんですけど、いいです？ デザイナー TD コーダー
25. デザイナーにフィードバックして 何となく認識を合わせる 25
26. エレメントリストがある場合 26
27. DEMO https://bit.ly/2rRRMhY 27
28. この案件におけるワークフロー 28 予め整理してくれた 分解作業が楽になった デザイナー TD コーダー
29. かなりいい感じに なってきた 29 欲を⾔えば コンポーネントの粒度を もう少し揃えたい
30. コンポーネントの粒度 30 抽象化して 「認識」 に置き換えてみる
31. なぜ認識がブレるのか？ ➤ 共通となる指針がない。共通認識、共通⾔語 ➤ ワークフローが各フェーズで断絶されている 31
32. 32 ͜Ε͔Β໨ࢦ͢΂͖ϫʔΫϑϩʔ
33. なぜ認識がブレるのか？ ➤ 共通となる指針がない。共通認識、共通⾔語 ➤ ワークフローが各フェーズで断絶されている 33
34. 34 http://atomicdesign.bradfrost.com/
46. Atomic Design Methodology実運⽤のポイント ➤ あくまで理論であるため、理論に忠実すぎる必要はない ➤ デザイナーとTD/コーダー間で共通認識が持てているか？が重要 ➤ イレギュラーはもちろんあってOK ➤ ⼤事なのは「理論に則ること」ではなく「よき成果物」 ➤ ただし「全てがイレギュラー」はただのカオス ➤ イレギュラーをあぶり出すために多数のレギュラーがある 46
47. Atomic Design Methodology実運⽤のポイント ➤ Atomic Designをそのままコンポーネント設計に反映できる訳ではない ➤ コンポーネント設計としては、⼤抵下記の2つの粒度があれば事⾜りる ➤ 原⼦/原⼦よりの分⼦ ➤ 厳密には分⼦だが、原⼦レベルに使い回したいもの ➤ 分⼦/分⼦よりの有機体 ➤ 厳密には有機体だが、分⼦レベルに使い回したいもの ➤ 有機体はコンテキストによって多くのバリエーションを⽣み出す ➤ 全てのパターンを定義するのはときにナンセンス 47
48. なぜ認識がブレるのか？ ➤ ✔ 共通となる指針がない。共通認識、共通⾔語 ➤ ワークフローが各フェーズで断絶されている 48
49. 典型的な⼀⽅通⾏のワークフロー 49 TDは基本降りてくるデザインに従うしかない デザイナー TD コーダー
50. 典型的な⼀⽅通⾏のワークフロー 50 デザイナー TD コーダー 現状ここは問題ないので、ここより上流の話
51. フェーズとして捉え直す 51 デザイン （AD/デザイナー） マークアップ設計 （TD） 情報設計 （ディレクター/IA）
52. 典型的な⼀⽅通⾏のワークフロー 52 デザイン マークアップ設計 情報設計 思考 思考 思考
53. 典型的な⼀⽅通⾏のワークフロー 53 思考 伝達 思考 思考 伝達 デザイン マークアップ設計 情報設計
54.  齟齬の壁 54
55. 典型的な⼀⽅通⾏のワークフロー 55 思考 伝達 思考 思考 伝達 デザイン マークアップ設計 情報設計
56. 典型的な⼀⽅通⾏のワークフロー 56 思考 伝達 思考 思考 伝達 デザイン マークアップ設計 情報設計
57. 典型的な⼀⽅通⾏のワークフロー 57 思考 伝達 思考 思考 伝達 齟齬 齟齬 デザイン マークアップ設計 情報設計
58. プロジェクトの成否をかけた ⼤⼈の伝⾔ゲーム 58
59. シンプルなプロジェクトならまだいい。 仕様が複雑になればなるほど、 思考の齟齬は致命的になる 59
60. 考えてから伝えても 齟齬が発⽣する 60 ⼀緒に考える
61. 典型的な⼀⽅通⾏のワークフロー 61 デザイン マークアップ設計 情報設計
62. ⼀緒に考えるワークフロー 62 デザイン マークアップ設計 情報設計
63. ⼀緒に考えるワークフロー 63 デザイン マークアップ設計 情報設計 メイン作業者がいつつも、インタラクティブに密にやりとりする
64. ⼀緒に考えるワークフロー 64 デザイン マークアップ設計 情報設計 メイン作業者がいつつも、インタラクティブに密にやりとりする
65. ⼀緒に考えるワークフロー 65 この⽮印を実現する ➤ プラットフォーム ➤ 運⽤体制 が必要 メイン作業者がいつつも、インタラクティブに密にやりとりする
66. 複数⼈での思考サイクルを早く回すには ➤ プラットフォーム ➤ 軽く ➤ 早く ➤ 扱いやすく ➤ ブラウザで確認できて ➤ コメントを付けられる ➤ = XDのプロトタイプ共有とオンラインコメント 66
67. 複数⼈での思考サイクルを早く回すには ➤ 運⽤体制 ➤ もっと気軽に会話する ➤ もっと気軽にコミュニケーションをとる ➤ = 15分でもいいので⽇次の進捗共有 ➤ = 常⽇頃からコミュニケーションが⽣まれやすい雰囲気をつくる ➤ ⼀緒にランチに⾏く ➤ 部活を発⾜する ➤ ランチ画像アップ専⽤Slackチャンネル、雑談専⽤Slackチャンネル 67
68. コミュニケーションにばかり 時間を取られるのでは？ 68
69. コミュニケーションを効率化するコツ ➤ ⾮同期コミュニケーションを上⼿く活⽤する ➤ 事前に要点をまとめ、テキストで伝えておく ➤ 必要であれば画像・動画を⽤いる。百聞は⼀⾒にしかず ➤ CloudApp/Recordit ➤ ⾮同期コミュニケーションの⼼得 ➤ https://goo.gl/c7gHyq ➤ https://goo.gl/5wBMkW 69
70. まとめ 70
71. XDの使い道は無限⼤ マークアップ設計にも使える 71
72. XDの真価は 「本質的なコミュニケーション」 を増やすことにある 72
73. コミュニケーションを はやく 正確に インタラクティブに 73
74. XDはアートボードベースの コミュニケーションプラットフォーム 74 assialiholic atsushi.handa.3