こんにちわ。対よろです。

「デザイン初学者を脱した方」にこそ読んでほしい

つい先日、卒業単位数を満たしていることが確認できました。

やっと""基本的人権""を獲得できたというわけですね。
いや、マジで大変だった…………………マジで………………オォン……………………

まあ色々きっかけがあり、2019年4月から事業会社にて、UI/UXデザイナーとして長期インターンに取り組んでいました。

具体的には、LINEで完結する新卒採用サービスのWeb開発責任者として、プロダクト開発まわり全般を担当していました。
UXリサーチ全般、KPI達成のための施策の仮説検証、UIデザイン、簡単なコーディングなど、一通りさせていただきました。

ただこの期間は、ほとんどnoteやTwitterで発信してきてなかったんですね。
というのも、インターンにもかなりコミットしていましたし、大学の授業・就活準備などもあり、単純に時間が割けませんでした。

なので、ここらで一旦整理したほうが良いなと思いました。
「まあnoteでも書くか〜」という軽めのノリでやっていこうと思います。

テーマとしては、
自分がここ１年弱の長期インターンを通して、「UI/UXデザイナー」という職種の認識がだいぶ変わったなというのを感じているので、その点についてをメインに書こうと思います。

そんなわけで。いきましょう！

UI/UXデザイナー、やる事めちゃくちゃあるやんけ

この1年間で、UI/UXデザイナーの仕事についての認識が大きく変わりました。
またその業務内容について、少し解像度を深めることができたので、共有します。

長期インターンとして実務に入るまでは、UIUXデザイナーの業務について、

このぐらいの粒度でしか、業務について認識できていませんでした。
漠然としていますね。

いや正直、事業のデザイナーとして実務やってない場合、分かってもせいぜいこのぐらいだと思います。
しかしこれでは全てが曖昧です。
「近年はUIUXデザイナーの価値が上がっている」とか言われている理由も、説明できないですね。

こんな曖昧な認識から始まった長期インターンなので、入ってすぐの頃はあまりうまく動けませんでしたが、
それから業務に携わるうちに、どんどん掴んできました。

事業を作るデザイナーとして、どんな目標に対して、何をすべきなのか。
誰と、どんな動き方をしていくのか。

今は、自分のデザイナーとしてのスタンスがある程度固まってきました。
なので、その中でも重要と考えている点を、共有しようと思います。

デザイナーは、職種間を繋ぐハブのようなもの

「事業（プロダクト）は、デザイナーだけで完結しない」
というのは、考えれば理解できるところだと思います。

しかし「デザイナーだけで完結しない」とすると、どのように他職種と関わって事業を作っていくのか、想像しづらい部分もあるかと思います。
そのため「どんな職種の人と働くのか」というところを簡単に説明して、その中で自分がどのように動いてきたかを振り返ってみようと思います。

まず、プロダクトの成果に関わる具体的な職種としては、
・ビジネスサイド
・エンジニア
・デザイナー
この３職種に大きく分けられます。
（CSなど、他にも重要なポジションはありますが、ここでは割愛させていただきます。）

ビジネスサイドは、事業を成長させるためのKPI（達成すべき数値）を指標として、戦略を練ったり、施策を打ったりするポジション。
エンジニアは、言わずもがな、実際にプロダクトを動くようにする重要なポジション。
その中でデザイナーができることとしては、プロダクトの良さをユーザーに伝えるために、使いやすい画面を設計し、実際に使ってもらう、という役割として動くことができます。

ここで少し注意すべき点があります。
このままでは、この３職種間で目指す目標が違う、という事です。

ビジネスサイドは「事業をどう成長させるか」を最重要に置いている。
エンジニアは「機能や仕様をどう技術的に実現させるか」にコミットしている。
そしてデザイナーは「ユーザーへの価値提供」を最重要として置いている。

このままでは、この3職種が混在するチームにおいて、プロダクトの目指す方向性がバラバラですね。

ここで、デザイナーとしての動きを少し拡張してみましょう。

僕の場合でいくと、僕がペルソナやカスタマージャーニーを時間をかけて作っても、ビジネスサイドはどう活用していいかわからない状態でした。
しかも、ユーザーへの価値提供の観点からUIや施策を考えても、「それってKPIにどう結びつくの？」といった感じでした。
この場合、追うべき指標が明確でないのは、デザイナー、つまり僕です。

ここで私がとった行動は、
ビジネスサイドが追っている指標を理解するということです。

おそらく事業会社で働いているデザイナーさんなどには「いやそんなん知ってて当然やろ」と言われてしまうかもしれませんが、当時の僕は「KPI？なにそれおいしいの？」状態でした。
しかし、UIUXデザイナーが一人という状況で、自分の仕事の価値がわからなくなってきたので、「これは、この会社において、自分が指標においているものが間違っているのかもしれない」と気づきました。

そのため、まずはビジネスサイドが追っている指標である、KPI・KGI・CTR・CVR・CPA・MAU・DAU・などなど…これらの意味について片っ端から調べました。
次に、うちの事業がどのように回っているのかを整理する「KPIツリー」を、自分で作ってみて整理しました。

そうすると、これだけでだんだんビジネスサイドが追っている指標の意味が理解できました。
最初は「理解した」というだけで手探りではありましたが、だんだん「この施策にはどんな意味があるのか」「最終的にどうなれば成功なのか」という目線で、ビジネスサイドと議論ができるようになりました。

この視点から、デザイナーとしての視点、つまり
「ユーザーはどのような状態になることがベストで、その結果としてKPIにどう寄与して、どれだけ数字を伸ばせば成功なのか」という詳細な目標設定ができるようになりました。

これはエンジニアリングに関しても同様です。
僕がインターンしていたMicoworksではビジネスサイドが多かったため、必然的にビジネスサイドの視点で開発することが多かったですが、デザイナーにとってより重要なのは、むしろエンジニアリングの視点だと思っています。

その理由として、UIデザインは、実装なしでは実現不可能だからです。
HTML/CSSなどのフロントももちろんのこと、考えた機能の実現のためには、データベースやら、裏側の処理やらのサーバーサイドについても考えを巡らせる必要があります。
また、コンポーネントやライブラリと呼ばれるものは、デザイナーがデザインを作りやすくするというよりは、どちらかというと実装工数を減らすために存在するものだと思っています。

このように、デザイナーといっても、様々なことを考えないといけないわけです。
また、異なる領域に特化した職種と対等に議論して、チームでプロダクトを良いものにしていかなければいけません。

これを円滑に行うために、
・異なる職種の視座を獲得する
・異なる職種の知識を獲得する
これらが必然的に必要になってくる、というわけです。

また、デザイナーが「ハブ」になる、というのはどういうことかも説明します。

まあ極論ですが、ビジネスとして成り立って、実際に動くものが作れれば、それで良いわけです。という観点では、この２職種は重要です。
しかしそういう訳にもいかなくなってきて、「価値」が重要視されてきたので、デザイナーが台頭してきたわけです。

そのため、
事業にとっても、ユーザーにとっても、よりよいモノを提供できる立場として、デザイナーが存在している
と、僕は思っています。

なので、特にUI/UXデザインのインパクトをまだよく理解していない環境においては、今までの事業の視点にプラスして、デザインの考え方を浸透させていくように動いていくのが良いと思っています。

ビジネス・エンジニアリングに、デザインが歩み寄っていって、二者間を繋ぐこと。
これが、ぼくが現段階で理想とするデザイナーの動き方です。
この動きを、より解像度高く正確にできるようになることが、今後の目標ですね。

デザイナーとして、自分の専門領域に責任を持つ

先ほど、ビジネスとエンジニアリングを繋ぐハブになるために、視点と知識を獲得すべきと言いました。
しかし、デザイナーとして重要になるのは「デザインの能力」です。

ギャレットの５階層モデルで言うところの「最終的にユーザーがどうなっていれば成功なのか」という戦略部分から、「それを達成するためにどういう機能や要素が必要なのか」という要件部分、「その機能を使ってもらうために、どういう画面、要素があれば良いのか」という構造・骨格部分、「それをビジュアル的にどう見せればユーザーにとって一番良いのか」の表層部分。
これは、フェーズが 0→1 であっても、1→10 であっても変わりません。

これらを綿密に練って構成していくスキルが、デザイナーには必要です。
また、そのスキルを持っているからこそ、デザイナーとして他職種と協力して、事業を作っていくことができます。

またこのスキルは、"実践知"と"形式知"に分解できると考えています。

"実践知"とは、単純に経験のことです。
このギャレットの５階層モデルも、インターンに入りたての頃は漠然と理解していただけでした。しかし実務の中で意識していくことで、「あ、要件とか構造というのは、具体的な事業の流れでいうとこの部分なんだな」ということが分かってきます。これが実践知です。

そして"形式知"は、体系的な知識のことです。
多摩美の情デ、千葉大のデザイン系の学科など、アカデミックに情報デザインを学ぶのは、形式知ですね。
ただ独学だとしても、Amazonで買った分厚い本やなんかで、UXDプロセスやWeb要件の整理方法を勉強するなどして実務で活用できれば、形式知が活かせたことになります。
また、Apple・Googleの各種ガイドラインなんかも形式知に含まれますね。

そして、これら２種類の知識は、どちらかに偏るべきではないと思っています。
自分としては、この１年間で実践知はすごくたまったのですが、形式知の会得が少なかったなという感じなので、ここ最近はこの比率を逆にしています。

このような感じで、
「UI/UXデザイナーとして、デザイン領域に責任を持って創っていく」ことは重要だなと思います。

これは、UIデザイナーとUXデザイナーが分かれているとしても、ディレクターとデザイナーという上下関係があったとしても同じことだと思っています。
「UIだけ作れば良い」「手は動かさない」というスタンスではなく、プロダクトのデザイン全てにコミットすることが、事業に関わるデザイナーとして重要なマインドの一つだと思います。

デザインをみんなで考えるということ

「デザインはみんなで考える」
これも、耳にタコができるほどみなさん聞いていることと思います。

デザイン領域に責任を持つことは重要です。
デザイナーとしてのスキルでお金をもらう以上、常にプロダクトをより良いものにするために、スキルを磨いて、実務に活かしていく必要があります。

しかしその中で、ユーザビリティは、チーム全員で妥当性を確かめる必要があります。
というのは、デザイナーとして「こういう画面遷移が良い！かっけえ！使いやすい！」と思っても、実際に実装されてみると、
「え、これ使いにくくね？」「ユーザーがこういう操作をした場合のこと考えてなくね？」「オイオイオイ」
ということが発生してしまいます。

僕はインターンに入ってすぐに、これを盛大にやらかしてしまった経験があります。恐ろしいですね。

そのため、UIデザイン上の使いやすさなどは、チーム全員・実際のユーザーに触ってもらって議論しなくてはいけません。
そして、メインとなるターゲット（ペルソナ）にもモックなどで触ってもらい、どのような使い方をするのか注意深く観察する必要があります。

また、これは実装前のデザインモック段階で行うべきです。（そのUIの開発工数にもよりますが）
これを怠ると、実装後に「この画面全く使い方わからんやんけ！」となった場合に、その後の改善スピードが落ちてしまいます。

デザインに責任を持つことも重要ですが、決してアウトプットを過信してはいけません。
自分が良しとして作ったUIは基本的にバイアスがかかっているので、それを真にユーザーにとって良いものにするためには、他のデザイナーはもちろんのこと、ビジネスサイドやエンジニア、そして実際のユーザーに触ってもらい、テストすることが必要不可欠です。

これは、画面に向かってひたすらデザインを作るタイプが陥りがちな罠だと思います。
一人で完結しないこと。一人で満足しないこと。
UIの妥当性は、周りを巻き込んで検証すべきというのは、UI/UXデザイナーとして注意したい点ですね。

まとめ

色々書きましたが、まだ内定先もなく、道半ばではあります。

ただ、こうしてログを残しておくことで、もう少し先に進んでから「こういう考えを持ってたんやな〜」と振り返ることができるので、良い整理になったと思います。

何より、この先同じ道を通るであろう人にとって、少しでも何かのきっかけにしていただけたらという思いがあります。

cookpadのちょねださんの書かれたこのnoteの中で、

という言葉がありました。

デザイナーとして活動する中で、多くの人に頼って、助けてもらってこなければ、新卒でデザイナー入社する選択肢すらなかったかもしれません。

なので、これを読んで、現在デザイナーを目指してもがいている方に、何か気づきを与えられればいいな、と思っています。

また、ここで書いたことが全ての人に当てはまるわけではないと思っています。

それぞれのキャリアに必要な能力やスキルを見定めて、それを会得するために動く必要があると思っています。
ただ、それを判断するのも経験が必要ですし、自分も今後の経験によってキャリア設計が変わる可能性も全然あります。

今後も頑張ります。

オェ〜疲れた。6015文字頑張って書きました。

対ありです。