
デザインワークを透明化する「ライブデザイニング / モブデザイン」という手法
2018.5.11『Design & Collaboration』というイベントに登壇させてもらいましたDMM.comの河西紀明(@norinity1103)です。この記事はそのフォローエントリーとなります。
今回は、デザインワークを中心としたチームコミュニケーションの際に、デザイナーがプレゼンスが発揮でき、プロセスを透明化することができる「ライブデザイニング(英:Live Designing)/ モブデザイン」という手法を紹介します。
ライブデザイニングとは?
ライブデザイニングはライブコーディング(英:live coding)のように、大きなディスプレイで、デザインワークのプロセスをリアルタイムでゲストに視聴してもらう手法です。実際のツールの操作手順や制作課程を見てもらえるため、より詳細に成果物の完成までのプロセスや、設計ノウハウ、ツールの操作やテクニックを学んでもらうことができます。
日本でも少しずつイベントが開催されるようになりました。
https://d-cube.connpass.com/event/20711/
従来的にはエンターテインメント性が高く、やや一方向的なプレゼンテーションの傾向がありましたが、今回はこれをチーム開発に応用します。
デザイナーはプロダクト開発に必要な途中成果物ができあがるまでのプロセスを「生々しく」オープンな状態にするのです。
デザイナーにとっては多少、勇気のいることですがよりシームレスな開発体制を実現するために必要なアプローチです。

<おおまかな手順>
1. ドライバー(デザイナー)は実施するライブデザインのゴール(成果物)テーマに対する議題設定をして、参加者にアナウンスする
2. SketchまたはFigmaなどを利用して、作業ボードをInVisionやProttなど各自の手元の端末で確認できるツールに即時反映できるようにしておく
3. ゲスト向けにプロトタイプや共有URLを事前に公開し、参加者の手元デバイスでレビュー&フィードバック出来るようにしておく
4. ツールの熟練者としてドライバー(デザイナー)は成果物の作成課程を踏みながらファシリテートし、設計上の課題や悩んでいる部分について参加者の意見を募る→特に要件や機能的な部分
5. 全体時間の10%をふりかえりに使い、実施課程で洗い出された調査課題や検討事項をタスク化し、次回に備える
・所要時間:1h~2h(だれすぎないように)
・人数:2名〜6名 (多すぎるとカニバるので)
・場所:できるだけ見通しの良いところ(興味を持ってもらいやすい)
※ルールは柔軟に
モブデザインとの違い
モブプログラミングを応用したモブデザインという手法も見られるようになりましたが、こちらも似たワークですが、手順に大きく変わりないです。
明確な定義はありませんが、概ねゲスト聴講型がライブデザイニング、参加型がモブデザイン区分されます。往々にして複数のゲストを初期フェーズから能動的に参加してもらい、だれずにファシリテートすることはかなり難易度が高いです。
デザイナー以外のステークホルダーに参加してもらうためには、デザインワークに対しての興味関心を得なければ円滑に進まないケースが多いので、目的の設定に応じて段階に行うことをおすすめします。
ブラックボックス化されがちなデザインのプロセスを見せる
ペーパープロトタイプやマイクロクレームで初期設計を、チームワークとして行う現場もかなり増えてきました。しかし、1次成果物(ワイヤーフレームやサイトストラクチャ)を作成したり、Low-fi/Hi-fiプロトタイプをUIツールで描き起こす作業はデザイナーの専任的な作業となっているでしょう。
非デザイナーの多くはこの見えないプロセスを「魔法」と形容します。それは良くも悪くもブラックボックス化されているということです。ライブデザイニングではこれらのデザインワークのプロセスを惜しみなくチームメンバーに晒すという試みです。
多くのメンバーは「魔法のプロセス」目の当たりにして、表現を具体化するまでのスピードや、一種の最適解にたどり着く道筋に対して関心を示すでしょう。
デザイナーとってそれは、あらゆる悩みや葛藤を見せることと同義で、非常に勇気のいることかもしれません。共業を実現し、エンジニアなどの相補的な信頼関係を紡ぐための自己開示の1つとして一歩踏み出しましょう。
ただし、これはテクニック自慢ではありません。チームにとって価値のあるプロダクトを作り上げるための漸進的な手段の1つとして自覚し、その時間をむだにしないために最大限の工夫をする必要があります。
あとは、いい感じにしておいて☆ → なるはやで
いえ、より良いプロダクトのために一緒に考えましょう。

会議のドライバーとしてメンバーを導く
チーム開発におけるライブデザイニングは、デザイナーの主催する一方向なイベントでなく、多機能業種のコラボレーションの場です。つまりデザインワーク自体を開発に関わるメンバー一体で行うことを示します。
最高のイベントに出来るように準備し、その時の参加メンバーのリアクションやリクエストに応じてアクションを替えていかねばなりません。
また、デザイナーはGUIツールの習得者です。UXD、IA、UIDなど特化した専門知識を利用して、画面上に「評価できる成果物」の具体化をリードするためのドライバーとなります。

多面的なレビュー&フィードバックを得るために
ライブデザイニングに、「誰」を招待できるかによって得られるイベントの成果は大きく異なります。
初期フェーズで企画職、実装行程の開発職のメンバーを参加させることで、設計の段階で、想定リスクの洗い出しや、機能要件や仕様などの精度の高い共通認識づくりが可能となります。
気軽にステークホルダーを召喚するための信頼値を高められていると理想的ですが、いきなり「みんなで集まりましょう!!」と言われてもなかなか上手く行かないものです。
まずは、同じ課題感を持ったメンバーと少人数から初めて「小さな成功」を作っていきましょう。ある意味大げさに作業課程をオープンにすることはそれだけ目に触れる機会が増えるのできっと興味を持ってくれるでしょう。
なぜなら同じプロダクトを作っている仲間だからです。

教育的な側面
プロダクト開発においてデザイナ一職が制作する「途中成果物」は非常に多様です。経験豊富なデザイナーでない限り、それら1つひとつがどのような意味があって、なぜ必要とされるのかという原理を知るには実地体験をもとにした学習プロセスが必要です。
経験の浅いデザイナーはグラフィカルでない構造的な成果物がなぜそこまで重要な意味を成すのか理解することができないことが多いです。エンジニアリングやサービス設計など組み合わせの知見を取り入れなければならないからです。
ライブデザインというワークはリードデザイナーが育成対象のデザイナーをバディーとして参加させることで、非常に効果の高い学習体験を与えることも可能です。

最終的にプロダクトを評価するのはユーザーである
釈迦に説法のような話ですが、この原理をチームの共通認識として浸透させるために多くのデザイナーが戦ってきたでしょう。
共業により信頼値が高くなってきたチームはお互いの技能や知見をみとめ、次第にフラットな関わり方が可能になります。
内輪で忖度をしなくなったチームはより良いプロダクトのために漸進的にプロトタイプの検証・精査を繰り返し始めます。そして、自分たちだけでは判断しきれない幾つかの課題にぶち当たります。
ここでユーザーテストの実施やペルソナの必要性が再定義される事となります。それと同時にそれらの質が向上するでしょう。

実施してみた感想
DMMでも幾つかのチームで試してみましたが、参加者全員がメチャクチャ疲れるので「ふりかえり」を通して実施フローはチームに合わせて少しづつ調整しました。
それからはやるときは2〜3人ぐらいで行うケースが、比較的定着しています。デザイナーがざ〜っと作って、横にデザインに興味があるエンジニアに座ってもらって、都度質問する形です。
デザインプロセスの理解を浸透させる手段として、チーム全員で1回は経験するのは良いですが、定期的な開催を義務化するのはアンチパターンとなるので注意が必要です。当たり前ですが、デザイナーのテクニック自慢の場ではないので、当然目的やソリューションベースで実施することが望ましいでしょう。
最後に
デザインツールの進化したことによって、周りとコミュニケーションをとりながらデザインをするということが簡単になってきました。これは本来あるべきデザイナーの仕事の仕方になってきたと感じています。
特にFigma のようなリアルタイムでデザインを見せる機能をもったツールの進化は、まさにそのような未来が待っていると示唆しているのではないでしょうか。
業界的に良い方向へ進んできているとはいえ、課題は多く、デザインワークのプロセスには数多くの摩擦がありますし、実装行程によりスムーズにハンドオフするためには技術的負債や開発体制の改善など深い闇があります。
「お互いの信頼地の高いチームはどんな事業でも高い成果を残せる」という言葉が存在しまます。
デザインを途中で見せるのは恥ずかしいという考えがマインドとして根強いものがありますが、それはデザイナーに限った話ではありません。
プロダクト開発に置いてデザイナーは、ユーザーに対して一貫した体験を提供することに責任を持つ存在です。
まずは「自己開示」から初めることが、信頼関係を築く歩み寄りならば、デザイナーから一歩踏み込んで主体性を発揮してみてはどうでしょうか。
どんどん、ディスクローズしていきましょう。
実録:Figmaを利用した「UIインベントリ」の実施
本記事でも取り上げさせてもらった内容で、トライしたInterfaceInventory(UIインベントリ)の実践事例です。ぜひごっ参考までに。
以上。。
---
それではまた。
共同制作している公開イラストはこちらから無料ダウンロード出来ます
https://www.ac-illust.com/main/profile.php?id=d1pjdbX9&area=1
お仕事依頼、リクエストも受け付けております。
いいなと思ったら応援しよう!
