#yhassy

[overmars]

もし、デザイン原則が「大胆であれ」「シンプルに」「ユーザー第一」みたいなのばかりだったら、デザイナーの振る舞いを定義してるだけで、プロダクトがなぜ存在するかは語ってないことになる。 デザイン原則だけで会社やプロダクトが連想できないなら、それは原則がプロダクトの哲学じゃなくて、デザイナーの心得になっているから（そのつもりで作っているならアリだけど）。 「何をどうデザインすべきか」に迷うとき、立ち返る先がそういうデザイン原則だと答えが出ない。プロダクトの存在理由に立ち返えることができる『何か』でないと、判断に軸がなくなる。

src

[overmars]

デザイナーのAI不安って大体「モックアップが自動生成される」方向に向かいがちだけど、実際に一番時間を食ってるのは制作そのものじゃなくて、作ったものをエンジニアに伝えてコードにしてもらう翻訳プロセスの方。AIが本当に消しにきてるのはこの翻訳コスト。問題はそのあとどんな仕事をするか。

src

[overmars]

デザイナーの日々の業務にあるやもや

AIへの期待と焦燥感

リソース不足と孤独感

プロセスとコミュニケーションの不全

デザインの価値とキャリア

src

[overmars]

デザインの仕事と価値提供が変わる理由

現在起きている変化は単なる作業の自動化や効率化を超えたものであり、これまでのデザイナーの仕事の枠組みそのものが大きく変化する可能性があります（ズラしたリフレーミングしたりする形で）。この答えは、置かれた環境や周囲からの期待によって異なってくるでしょう。例えば、人によってはファシリテーターのような役割を担うこともあれば、特定の領域における深い知識と直感を活かして精密な設計を行うこともあるでしょう。また、従来にはなかった挑戦的なデザインを生み出し続けるという立ち回りも考えられます。

クライアントやステークホルダーが求めているのは、具体的な成果です。たとえば、Webサイトがユーザーを獲得できているか、アプリが継続的に利用されているか、プラットフォームがビジネス目標を達成しているかといった結果に注目しています。そして、その成果を生み出すプロセスが、手作業で丁寧に作り込まれたものであろうと、AIによって生成されたものであろうと、大きな問題にはならないことがほとんどです（丁寧に人が作ることが成果に直結すると評価されている場合は別ですが）。

この視点に立ったとき、私たちデザイナーがすべきことは何でしょうか。それは、おそらくこれまでのデザインの価値観を守り抜くことではないのかもしれません。

src

[overmars]

4つの組織タイプから考えるデザインの始め方

競合価値観フレームワークというものをもとに、組織のペルソナ像を把握し、物事をどのように進めていくかの考え方が記載 https://yasuhisa.com/could/article/cvf-design/

[overmars]

組織が大きくなるとデザイナーが小さくなる問題

小さい組織だと課題発見と解決のための活動に第一線で関わりたいのであれば最高の仕事環境。分野を絞ってスキルを伸ばしたい方には向いていない。

大きい組織になると課題が発生。

期待値のすれ違いで誤解が生じる

新しい人が働きにくくなる

『気が利く人』が便利に使われて消耗する

組織が期待するデザイナーの役割は何か明文化する。 明文化しなくても通じ和えた「甘え」をそのまま引き継ぐと、大組織の仕組み（縦割り）・文化・政治によってデザイナーの仕事が徐々に限定され縮んでいく。

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

仕事は「やる気」「情熱」だけでは続けられない。お金・地位などのインセンティブはもちろん、活動をサポートする制度・仕組みやワークフローを作る必要がある。

頑張れば誰かが見てくれて、評価してくれるとは限らない。期待値のすれ違いにならないために、組織が期待するデザイナーの役割は明文化していくと良い。

[overmars]

どこに重心を置くか

デザインツールの機能を学ぶことに重点を置くべきか、コミュニケーションスキルを磨くべきか、それとも事業について学ぶべきか。結局のところ、スキルレベル、キャリアの目標、所属する会社によって変わる。問題は自分の立ち位置をマクロな視点で捉える機会や話し相手がいるかどうか。

仕事環境や責任範囲によっては、Figma の機能を使いこなす必要ないし、プレゼンスキルも磨く必要もない。将来どうしたいかによって、学んだほうが良いかもしれないが、その人が頭の中に描いている計画による。

[overmars]

それ、課題じゃないですよ

「アクティブ数が増えない」 「コンバージョン率が悪い」 「リリースした〇〇が使われない」 「オンボーディングがうまくできていない」

デジタルプロダクトの改善する際に取り上げられるフレーズたち。これらのフレーズが多くの会話やアイデア発散の起点となることがあります。しかし、これらはすべて課題ではなく、症状です。

デザイナーに限らず、課題としっかり向き合いたいと考えてはいるものの、そもそも「課題」という言葉の解釈が異なることがあります。人によっては症状を課題と呼んでいることがあり、こうした言葉の解釈のズレを置き去りにすると、進め方に対する意見の食い違いが発生します。同じ言葉でも違う解釈になってしまうのであれば、「症状」と「課題」と言葉を別々にしたほうが良いのではと思い、使い分けています。