Yasuhisa Hasegawa

インプットの質でアウトプットが変わる デザイン案やワイヤーフレームなど、プロセスの節目でアウトプットを評価する機会があります。デザインに限ったことではありませんが、アウトプットの評価はどこかで必ず行われていますが、インプットはどうでしょうか。ここで言うインプットとは、 アウトプットをするために必要な情報を指します。 例えば以下のような情報はインプットになります。 事業戦略 企画書 PRD(プロダクト要求指標書) ガイドライン 定量・定性調査 その他、合意している情報 デザインであればムードボードや競合調査なども大事なインプットになります。デザインはデザイナーの思いつきで作られるものではなく、上記のようなインプットを頼りにしています。 アウトプットはインプットの質に左右されることが多いです。例えば、明確なターゲットユーザーの定義(インプット)がないままだと、誰に対するデザイン案なのか分からないので良し悪しの判断がつきません。レビューワーがそれぞれの価値観で意見を出すので「使いにくい」と言われても、誰に対して使いにくいのか分からないですし、修正方針も決まらないのでデザイナーが動きにくくなります。

アウトプットの質向上のためにインプットもレビューしよう
アウトプットの質向上のためにインプットもレビューしよう

インプットの質でアウトプットが変わる

デザイン案やワイヤーフレームなど、プロセスの節目でアウトプットを評価する機会があります。デザインに限ったことではありませんが、アウトプットの評価はどこかで必ず行われていますが、インプットはどうでしょうか。ここで言うインプットとは、 アウトプットをするために必要な情報を指します。

例えば以下のような情報はインプットになります。

  • 事業戦略
  • 企画書
  • PRD(プロダクト要求指標書)
  • ガイドライン
  • 定量・定性調査
  • その他、合意している情報

デザインであればムードボードや競合調査なども大事なインプットになります。デザインはデザイナーの思いつきで作られるものではなく、上記のようなインプットを頼りにしています。

アウトプットはインプットの質に左右されることが多いです。例えば、明確なターゲットユーザーの定義(インプット)がないままだと、誰に対するデザイン案なのか分からないので良し悪しの判断がつきません。レビューワーがそれぞれの価値観で意見を出すので「使いにくい」と言われても、誰に対して使いにくいのか分からないですし、修正方針も決まらないのでデザイナーが動きにくくなります。

--

--

良い感じに、が通じなくなるとき

小さな組織だと肩書きや世間の定義に囚われることなく、周りとコミュニケーションをとりながら働くシーンがよくあります。そんな現場で働くデザイナーはプロダクトのあり方を深堀するフェイズから入ることが多いですし、実装にまで携わる方もいます。分野を絞ってスキルを伸ばしたい方には向いていませんが、課題発見と解決のための活動に第一線で関わりたいのであれば最高の仕事環境だと思います。

人数が少ないうちは良い感じの間合いをとってコラボレーションする働き方がしやすいです。誰が何をしているかも見えやすいですし、少し話すだけ物事が決まって進んでいきます。

こうした小さな規模で出来ていたことが、人数が増えると次第に難しくなっていきます。組織が大きくなると、様々な領域が重なる兼任業から、特定領域のスキルと経験が豊富な専門業が増えていきます。

小規模で出来ていた『空気を読んで良い感じにコラボレーションする』働き方を、組織が大きくなってからも続けていると様々な課題が浮上します。

  • 期待値のすれ違いで誤解が生じる
  • 新しい人が働きにくくなる
  • 『気が利く人』が便利に使われて消耗する

小さな組織にあるスピード感やコラボレーションのしやすい関係性は大きくなっても変わらず残すべきですが、明文化しなくても通じ合えた『甘え』をそのまま引き継ぐと大きな組織ならではの仕組み、文化、政治によって働き方が制限されることがあります。初期フェイズからしっかり携わっていたデザイナーの仕事も徐々に縮んでいくのもその一例です。

周りが捉えるデザイナーの仕事

初期フェイズから関わることが多かったデザイナーも、組織が大きくなるにつれて次第に「作る」ほうへ比重が高くなることがあります。プロダクトのあるべき姿や施策の優先順位はプロダクトマネージャー(PM)の役割で、デザイナーはそれに対して良い見た目を作るといった関係性にいつの間にかなっていることも少なくありません。

UI と正面から向き合って仕事できるのは素晴らしいことです。デザイナーのあるべき姿のひとつですし、UI デザインに集中できる環境が用意されてるのは人によっては働きやすいと思います。しかし、作る以外にも携わりたいと考えるデザイナーにとっては『閉じ込められた』と感じるかもしれません。

「デザイナー」から「見た目を作る」を切り離して考えられるのはごく一部の方のみです。組織が大きくなり、分業が進むとデザイナーを「見た目を作る担当者」と捉えてしまうのは日本に限ったことではありません。

今年の春に発表された PM and UX Have Markedly Different Views of Their Job Responsibilities は UX デザイナーの立ち位置の難しさが見え隠れします。

--

--

限定的な課題解決になる受身のデザイン

デザイナーは良くも悪くも、来た依頼に対して最大限の努力をする方が多いと思います。「〇〇の見た目を良くしてほしい」「△△を使いやすくしてほしい」といった課題を解決するには高いスキルと経験が必要ですから、専門家としての価値は出せるはずです。最初は来た依頼に対して解決策を提供する活動でも十分ですが、やることが決まった段階から始めるデザインは制約が多いだけでなく、限定的な解決にしかならない場合があります。

例えば、記事に紐づけるコメントリストをスレッド式に変えたいという要望が来たとします。やるコトが決まった状態からデザイナーが入ると、どうしても「見やすいスレッド」「返信しやすい UI」を考えて作ることが目的になります。

依頼に答えるデザイン活動も重要ですが、これを続けているとデザイナーの仕事が次第に限定的になり、付加価値を提供するという受身の立場になりがちです。

デザイナーは、例えば以下のような問いから本当にスレッド式にすべきか考えるべきです。

  • コミュニケーションをとりたくなるキッカケは何か
  • コメント投稿後に何を望んでいるのか
  • ターゲットユーザーのオンラインコミュニケーションのあり方は
  • コミュニケーションを通してユーザーはどうなっていると望ましいのか

『スレッド』という手段が決まってからこうした問いをしても遅すぎます。デザインだけでなく、手段が決まったあとから始めるリサーチは手段の答え合わせになりがちで、ユーザーの根本的な課題や動機が導き出せなくなる場合があります。

--

--

ノートのとり方を見直す

Roam Research を使った知識整理を初めてしばらく経ちます。今でもノートの書き方を微調整しながら少しずつ知識を蓄えて続けています。Roam Research をはじめ、ここ 1, 2 年の次世代ノートアプリブームの火付け役といっても過言ではない「How to Take Smart Notes」という書籍がありますが、私のノートのとり方も書籍からインスパイアされています。

70 冊の書籍を執筆したドイツの社会学者 Niklas Luhmann 博士が、どのように知識を整理したか紹介されています。カードインデックスを用いて整理するそのメソッドは「Zettelkasten」と呼ばれており、3 種類のノートを図書館にあるようなカードインデックスボックスを使って整理したそうです。

  • Fleeting notes: 疑問やちょっとしたアイデアでも構わないので、忘れずに書き残しておくノート。
  • Literature notes: 書籍など何か興味を惹く情報に出会ったときに書き残すノート。コピペは避け、自分の言葉にして書き換える。
  • Permanent notes: 上記のノートを基に、さらに深堀した内容を書き込むノート。1 ノート、1 トピックに絞ってアイデアの解像度を上げていく。

--

--

翻訳は奥が深い

大学生の頃、村上春樹作品の何冊かを英語で読んでいましたが、表紙に必ずといって良いほど目にしたのが「Jay Rubin」という表記。彼はムラカミ作品の何冊かを英訳した方ですが、英語にも関わらず『ムラカミの匂い』を感じる文体とリズムがあってとても感銘を受けました。

ある言葉で表現された文章を、他の言語で言い換えれば良いといえるほど翻訳は単純ではありません。受け取る側の文脈(文化をはじめとした背景)を考慮して言い回しを変えることもありますし、時にはまったく違う表現にする場合もあります。

書籍「ハリー・ポッター」シリーズも翻訳が難解だったことで有名です。下記の記事で詳しく読むことができます。

https://summalinguae.com/language-culture/harry-potter-translators-madness/

組織の一員として働くデザイナーにとって、翻訳者が実践している相手の文脈に合わせて巧みに表現を変えるスキルは欠かせません。たとえ作るための高いスキルを備えていたとしても、翻訳できないばかりに力を十分に発揮できない場合があります。

デザインなんて言わなくても大丈夫

例えば組織で「ページビュー(PV)」の目標値が設定されていたとします。デザイナーも一緒になって目標達成のために働かなければいけませんが、ユーザー課題を解決したいと考えるデザイナーにとって PV は少し遠い存在に見えてしまいます。だからといって「ユーザーの課題は何か?」「PV は意味があるのか?」といった質問をぶつけているだけでは関係は平行線のままです。

もし、デザイナーが翻訳者のように頭を働かせるのであれば、下記のような質問から会話を始めるでしょう。

  • PV によって生み出されるビジネスとユーザーのアウトカムは何か
  • PV はパーチェスファネルのどこを指しているのか
  • マーケティングや営業など、Web サイトと合わせた策は何か
  • どういうポジショニングで人を集めようとしているのか
  • 上記に関する調査をした資料はあるか

デザイナーにとって馴染みのある言葉は一切使わず、ビジネスの方でも分かる言葉を使って質問します。しかし、質問を通してデザイナーが知りたいユーザーの文脈や、成果物の方向性を考えるヒントを得ることができます。

最初は PV を上げるという目標に対して「?」だったデザイナーも、対話を通してユーザーの課題を解決した結果 PV も上がるというストーリーを見出せる可能性があります。

「デザイン」という言葉はビジネスでも使われていますし、装飾だけを指しているわけではないことも理解している人もたくさんいます。広く使える便利な言葉ですが、デザイン業界内でも様々な解釈があるこの言葉を他業種とのコミュニケーションに使うのは避けた方が良いと思っています。

言葉の意味や我々のスタンスを説明するより、『ビジネスの言葉』を学習し、翻訳を通して自分たちが本当に欲しい情報を摘出するほうが圧倒的に早く楽なやり方です。デザイン指標もビジネスとデザインを繋げる翻訳手段のひとつです。

歩み寄りのコミュニケーション

翻訳スキルはすべてのデザイナーがもっているべきスキルのひとつ。クライアントやステークホルダーがもつ抽象的なイメージや言葉を成果物に落とし込む過程は翻訳と重なるところがあります。課題解決と表現されるデザインですが、課題が何か明確ではない状態では解決はありません。翻訳はその課題をハッキリされるために必要ですし、そのために相手の言葉や文脈への理解が欠かせません。

特にリーダーやマネージャーの役割を果たすデザイナーは翻訳スキルがないと仕事にならないと思います。デザインチームと組織を繋げるパイプラインとして、様々な分野で使われている言葉への理解を深めていきたいところ。仕事の 3 割くらいは翻訳作業に努めているといっても過言ではないくらい労力と工夫が必要になります。

翻訳は歩み寄りのコミュニケーションだと思います。自分たちの言葉で話すほうが楽ですし、言葉が分かっている方と話すと微妙なニュアンスも受け止めてくれるのも助かります。しかし、そうした場だけ経験していると視野が狭くなるだけでなく、他業種の方とのコミュニケーションの溝を埋めるのが困難になります。

完全に理解する必要はないですが、どういう用語を使っていて、どういう意味なのか大まか理解しているだけで、コミュニケーションの仕方が劇的に変わると思います。

この記事は、筆者 Web サイトで公開した記事からの転載です。

--

--

デザインを決める5つの要素

誰もが『自分の正しさ』『良さ』といった価値観を抱きながら、目指すゴールに向かって働いています。私にしても「こうありたい」というミッションがあり、それを達成するための活動をしています。

それぞれが良かれと思って活動していたとしても、チームメンバー全員が同じ価値感をもっているとは限りませんし、優先順位も異なります。私たちデザイナーが抱える価値の重さを、他人が同じように感じているわけではありません。私はそれを「デザインの理解が足りない」ではなく、「価値観の重きの置き方が異なっている」と捉えるようにしています。

デザインフィードバックが難しい理由のひとつは、どう考えても正しいと言い切れる成果物が作れない(説明できない)ところ。ひとりが「良い」と評価したデザインが、他の人に尋ねると「そうでもない」と言う場合があります。人によって意見が変わる場合もあれば、タイミングやコンテキストで評価が変わることもあります。

デザインフィードバックするためのコツはありますが、デザインの何を重要視しているかがズレたままだと会話が成り立たない場合があります。そこで、デザイナーはデザインをするときに何を考慮しているのか自分なりに整理してみました。

--

--

私は機能から考えるのが苦手です

モノを作る立場だと、どうしても「何を作るか」といったアウトプットで考えがちです。特にリリース後の改善案件は、企画者やプロダクトマネージャから「〇〇を作ろうと考えている」といったアウトプットが起点の相談になる場合もあります。

提案 / 企画サイドでしっかり調査された上でアウトプット提案しているものの、「本当に今やるべき最適の手段か」「ユーザーの求める結果 / 成果に結びつくか」といった疑問を投げかけるタイミングがない場合があります。

こうしたアウトプットがプロジェクトの起点になると、調査(リサーチ)が「答え合わせ / 辻褄合わせ」になる場合があります。

--

--

作品を載せるのがポートフォリオ? UXが付く肩書きは、何をしているのか詳しく聞いてみないと分からない課題がありますが、ポートフォリオも同様のことが言えます。 Web サイトにも同様のことが言えますが、デジタルプロダクトはリリース当時の状態に留まることなく改善が続くものばかり。また、チームで作ることがほとんどなので「これは私が作りました」と言い切れないですし、「UX を担当しました」とポートフォリオで説明されていたとしても、具体的に何をしたのかよく分かりません。 デザイナー向けのポートフォリオは大きく分けて 2 種類あります。 過去の作品を見せるギャラリー : 「すごい!良いデザインですね」と言われるようなビジュアルが並んでいる 就職のために必要なツール : 「ぜひ一緒に働いてみたい」と言われるための情報が揃っている 両方の役割を果たしているポートフォリオはありますが、「見せる / 魅せるポートフォリオ」のほうに比重を置いたものを多く見かけます。良いビジュアルを作るのが主な仕事であれば、ギャラリーのようなポートフォリオのほうがスキルが伝わりやすいです。しかし、UX デザイナー / プロダクトデザイナーだとどうでしょうか。

UXデザイナーならではの 1年の振り返り方
UXデザイナーならではの 1年の振り返り方

作品を載せるのがポートフォリオ?

UXが付く肩書きは、何をしているのか詳しく聞いてみないと分からない課題がありますが、ポートフォリオも同様のことが言えます。

Web サイトにも同様のことが言えますが、デジタルプロダクトはリリース当時の状態に留まることなく改善が続くものばかり。また、チームで作ることがほとんどなので「これは私が作りました」と言い切れないですし、「UX を担当しました」とポートフォリオで説明されていたとしても、具体的に何をしたのかよく分かりません。

デザイナー向けのポートフォリオは大きく分けて 2 種類あります。

  1. 過去の作品を見せるギャラリー : 「すごい!良いデザインですね」と言われるようなビジュアルが並んでいる
  2. 就職のために必要なツール : 「ぜひ一緒に働いてみたい」と言われるための情報が揃っている

両方の役割を果たしているポートフォリオはありますが、「見せる / 魅せるポートフォリオ」のほうに比重を置いたものを多く見かけます。良いビジュアルを作るのが主な仕事であれば、ギャラリーのようなポートフォリオのほうがスキルが伝わりやすいです。しかし、UX デザイナー / プロダクトデザイナーだとどうでしょうか。

良い見た目(UI)を作ることは仕事の一部ですが、それは全体からするとほんの一部でしかありません。 UI を作る前に実施する調査であったり、コンセプトをまとめてチームの視点を合わせるといった仕事もあります。今は 0→1 でアプリを作ることがマレなので、オンボーディングの改修といったアプリの一部だけ携わる場合も少なくありません。

このように「表面化しにくい」「作るだけではない」「同じ状態で残らない」なか、どう過去を振り返れば良いか分からないデザイナーはいると思います。私自身「コレを作りました」と言い切れるものは数年作っていませんし、成果物を作るのは現場で活躍しているデザイナーに任せている状態です。

「成果物は作っていないけど、事業に貢献しているデザイナー」はどんなポートフォリオを作れば良いのでしょうか。ギャラリーのようなポートフォリオは作れないかもしれませんが、過去を振り返ったり就職に役立つポートフォリオは作れるはずです。

事業貢献の観点でまとめる

こうした課題に取り組むために昨年から実施しているのが、過去行ってきた施策のデータベース化です。下記のようなテーブルを Airtable で作っています。(クライアント名や運用フィールドは非表示です)

--

--

UIコンポーネントは表層的な解決手段
以前「デザインシステムを作る前にデザインのシステムを理解しよう」という記事で、組織がもつデザインのシステム(仕組み)の理解を深めることが重要であると書きました。 「えいや!」で UI コンポーネントが揃ったライブラリを作ることは難しくありません。しかし、組織にとって意味のある UI コンポーネントになっているかは別問題です。

たとえコードの書き出しまで出来るデザインシステムを作ったとしても、ある一部の人たちが楽になるだけの最適化に止まる場合があります。作り手視点のメリットだけでなく、組織への貢献という広い視野が抜けていると「作ってみたけど浸透しなかった」ということになります。

UI コンポーネントを作るだけでも様々な要素の積み上げで成り立っています。簡略化された図ですが、UI コンポーネントを作る前に様々な課題を解決しなければいけません。

--

--

Yasuhisa Hasegawa

Yasuhisa Hasegawa

He designs content for web and elsewhere. A Freelance designer living in Tokyo.