UX MILK ALL Night - 良いUXを実現するために、まずはチーム内にデザインを浸透させている話
このnoteは2020年9月12日と13日に開催されるUX MILK ALL Nightで話す内容です。イベント開始前ですがスライドと台本を全文公開します。
なお、スライドだけを見たい方はSpeaker Deckからご覧いただけます。
---
それでは「良いUXを実現するために、まずはチーム内にデザインを浸透させている話」をいたします。
こんばんは。インクリメンツでデザイナーをしている綿貫佳祐と申します。2017年にエイチームへ入社してエイチームライフスタイルに配属された後、今年の1月からインクリメンツへと異動しました。
インクリメンツで作っているプロダクトは次の3つ。プログラミングに特化した情報共有コミュニティのQiita、社内向け情報共有のためのQiita Team、エンジニアの採用を支援するQiita Jobs。私はデザイナーとしてこれら3つ全てに携わっています。
さて今日の話を「聞いていただけると嬉しいな」と思っているのは次のような方です。
- これからUX向上のための取り組みを始めようとしている方
- 社内にUXデザインあるいはデザインの概念を浸透させたい方
こういった属性をお持ちの方々にとって、少しでも助けになれたらと思い
「UXにおいて、私がどのようにはじめの一歩を踏み出したか？」の共有をします。
逆に、今日は話さない内容はこちら。数字に現れるような成果の出し方とか、継続的な取り組みによる事業成長とか、そういった話。
それではお待たせしました。やっと本題に入っていきます。
このタイトルの「ために」「まずはチーム内」って……ちょっと変な文章の接続ですよね。自分で言うなよって話なんですけど。なんで「まずはチーム内」からなんだろうって思った方もいるんじゃないでしょうか。
私が「まずはチーム内」と考えた背景は次の3つです。
1つ目の「優れたUXデザイナーはチームや会社に『UXと向き合う文化』をインストールしている」は、正直読んで字の如くです。強いて注釈を入れるなら「私が観測してきた優れたUXデザイナーは」ですね。
優れたUXデザイナーが個人のスキルを頼りにグイグイ進めているのってあまり見ません。彼らがやっているのは、それぞれのチームメンバーがユーザー体験に向き合えるように諭す・促す営みに見えます。変な話がそのUXデザイナーがいなくなってもちゃんと回っていくんだろうな〜と思えるようなチーム作りをしているんですね。
長い目で見るとチームのうち1人だけがUX向上に尽力していては持続可能性も再現性もありません。
2つ目は「デザインはデザイナーだけでやるものではない。」
Raymond Loewyというデザイナーの方が「Design is too important to be left to designers.」という言葉を残しています。「デザインはデザイナーだけに任せるには重要すぎる」なんて訳されてますね。
考え方はまったくこの言葉の通りなのですが、個人的には「デザインの領域を広く捉えて、様々な人たちと共に作り上げたい」と思っています。そのため普段自分は「デザインをひらく」という表現を使っています。
ひらいていないデザイン、閉じているデザインって何？って話だと思うんですが
- 誰かに決めてもらったものをその通りに作るだけの作業
- 設計にせよグラフィック作成にせよ、デザイナーが手を動かし始めたら、チームメンバーが次に見るのは完成品になっている状況
こういうのは「閉じている」と思います。
デザインをデザイナーだけでやらないというのは、デザインの責任を放棄するという意味ではありません。特に事業会社にいるみなさんには共感してもらえると思うんですが、施策を考えたりユーザーの分析をしたりするのは職種関係なく実施しますよね？なのにデザイン制作になるとデザイナーで「閉じて」しまうのは違和感を覚える、という話です。
3つ目は、自分がインクリメンツに参加したタイミングでの正社員のデザイナーは自分1人でした。自分が入るまでのしばらくの間、フルタイムのデザイナーがいなかったのです。細かい歴史や状況はさすがに省略しますが、とにかく、継続的なデザインの営みが行われていなかったのです。UXに限らず、デザイン全般の営みが、です。
そのような状況ですから、デザインフローが整備されているわけはありません。デザイナーはこういう役割、といった組織の文化もありません。
経験上ここで「他にいないから自分が頑張る」ではあまり良い成果は生めないんですよね。デザイナー1人は1人なんですが、個の力だけで進めると「すごく動いてるけど何やってるかよく分からん人」が爆誕してしまいがちというか。
以上3つがあわさり、将来的なUX向上を見据えて、まずはチーム内へのデザイン浸透を考えたわけです。
「Design Scrum」と名付けた取り組みを企画し、デザイナー以外の方達に参加してもらいました。インクリメンツではスクラム開発をしているのと、ラグビーでスクラムを組んで前に進む姿は非常に「良いなあ！」と感じたのでこうやって名付けました笑
元々学生向けインターンシップで提供している内容がデザインスプリント簡略化・アレンジしたものでしたのでそれを流用しています。
そしてここで突然Tipsを提示するのですが、この手の「事業にとって必須」ではなく「プラスα」の取り組みは、いかに通常業務に影響を出さないかも大事になります。あとは取り組み開始までの時間が長引くと上手く行かない確率が上がるので、まずは形式に拘らず早く始めるのをオススメします。
もう少し内容を説明しますと、約半年間実施し、前半ではお題に沿ってサービスを立ち上げるための調査や企画をする課題、後半ではFigmaを使って自分の手でUIを作ってみる課題を作成していました。
原文ママなので若干文章が長いですが設定していたゴールはこちら。ただワークショップをやるわけではなく、終わった後に自分の活動に活かすイメージを持ってね、といったメッセージでした。
ここに参加されているみなさんには当たり前すぎるかもしれませんが、前半の内容はこんな感じです。
- 課題の定義
- インクリメンツの文脈があるので、「エンジニアの学び」って内容で考えてもらっていた
- ターゲットの調査や選定
- ペルソナとかよくある話も、STPみたいなマーケティング文脈も
- あとは極力生身の人間にインタビューしてみてね、とか
- 課題解決の手段の発散と収束
- 普段みんな「アイデア出しましょう」で3つや5つで満足してないですか？30でも50でも出しましょうって話
- 発散する筋力がビジネスやってるとつかない
- コンセプト決定
- ぱっと浮かんだキャッチコピーをコンセプトと言い張ってはダメですよ
- ユーザーの利用シーンとかまで詳細に考えた上で、これこそまさに価値である、みたいな内容を言い表せるように何度も突っ込んだり
- ステークホルダーの整理
- ユーザーって一括りにしないでとか、ユーザー同士の関わりとか
- Qiitaは広告モデルだけど、だとすると広告主とユーザーの関係は？とか
- ストーリーボードの作成
- 下手でもいいからちゃんとシーンとか文脈を思い浮かべる練習
- 普段どうしてもテキスト上だけ、あるいはエクセル上で完結することが多い
- 上記をリーンキャンバス的にまとめる
後半は、サービスを実際に形にする段階で、こんなことをやりました。
- Figmaの機能や使い方紹介（トレース含む）
- 基本的な機能を紹介して実際にQiitaをトレースしてもらう
- ナビゲーション設計
- トップページとかマイページ的なものがあるとして、無茶苦茶なリンク設計したらとても使いづらいよ、みたいな例とか
- ワイヤーフレーム
- どういう要素がどのページにあるかを俯瞰しよう
- この手の段階で作りすぎてはダメですよとか
- デザイン4原則について
- 言わずもがな
- UI Stack
- あえて突っ込んだ話をしてみた
- これは以外と、のちの会話で「ブランクステートであんまり良い表示が出来てないなあ」とかって話が出ることがあった
- 簡易的なデザインシステム
- 気を抜くと似たような色が50色くらいになるんだよ、ってのを実際に作ってもらったUIから体感してもらう
後半では実際に手を動かしてもらえるようになって欲しい、ではなく、プロダクトを作るときはこんなことを考えながら作っているよ、を共有する意味が強かったかもしれません。
毎回の進め方は
1. 2週に一度ほど、時間を確保して座学の時間を設ける
2. その回でレクチャーした内容を活かして解決できるような課題を出す
3. 次の回までに提出してもらい、私がそれにフィードバックをする
半年分の課題の詳細を説明するとそれだけで15分を全然オーバーしちゃうので省略しますが、このようにQiita Teamにまとめて毎回更新、後からも参照できるようにしてあります。
ちなみにさらっと説明していますが、毎回の事前準備で2-3時間、フィードバックでも2-3時間かけていました。どういう順番で説明しようとか、どこまで噛み砕こうとか、そういうことを考えると対デザイナーへの説明と比べて格段に難しかったです。話は逸れますがこの取り組みによって自分自身の説明する能力も上がったんじゃないかなあと思っています。
半年間やってみて起きた変化や反省をまとめると次のようになります。
良い変化
- プロダクトを作るにあたってデザイナーが何を考えているのか、Design Scrum以降少し分かるようになった。という声が出た。
- 普段でも「これはDesign Scrumで言ってた○○のことかな」と話に出るようになった
- みんなペルソナとかカスタマージャーニーとか「いかにもUXっぽいもの」を断片的には知っていたけど、一連の流れが理解できるようになって話がスムーズになった
- UX系のセミナーは「考えて終わり」が多いけど、UIにまで踏み込んだので「考えたものを作る際に注意した方が良いもの」の勘所が良くなった
苦労したこと・次回やるなら意識すること
- 実務ですぐに何か成果が出るかというと、出ない
- お互いの普段の会話とか、リスペクトとか、そういうものには効くと思う
- けど目に見えて成果になるわけではない
- おそらく理解のあるメンバーが増えることで、承認を得るための数字集めとかそういう「意味の無い作業」が減るとか、そういう見えづらい効果は出しやすいかも？
- 初めに哲学的な話から入り過ぎない
- 最初は小さな成功体験を積んでもらうような、Tips的な話題から入った方が良かった気がする
- そのせいで一区切りついたタイミングで離脱してしまう人も多かった
- サービス設計を前半、UI作成を後半にしたけど、逆のが良かったのかもしれない
最後にまとめです
- 「デザイナー以外の人がUXに理解を示してくれない」という声をよく聞くけど、自分から急接近すれば理解を得られる余地はある
- 自分も昔は「デザイナー以外の人がデザインに理解を示してくれない」とよく言っていた。けどその頃にこうやって自分から積極的にレクチャーするとかしていなかった
- 半年間座学の準備と課題の作成と各人へのフィードバックを用意するのは大変だけど、日々の会話のやり取りはスムーズになった
- 逆に言えばこれくらいやっても「会話がスムーズ」くらい
- 目に見える数字の成果を出そうと思うと多分もっと多くの動きが必要
私からの発表は以上です。ご清聴ありがとうございました。
最後まで読んでいただいてありがとうございます！