みなさんこんにちは、かじりです。突然ですが、80点から100点を目指すことと、0点から20点を目指すのでは20点という幅は同じですが、学習時間やコストは全然違うと思います。という理論に基づいて、JavaScriptを極めていくことと、別のスキルを伸ばすことを比較した時に、別のスキルを伸ばした方が効率という観点でいいと思い立ちました。 なので最近は、マーケティングやバックエンド、インフラ、デザイン、SEOなど幅広く学習しています。どれが自分にハマるかわかりませんが、３ヶ月くらいはこの方針で学習しています。
長くなりましたが、今回はデザインを学んだまとめです。
https://www.figma.com/resources/learn-design/lessons/
こちらのページを学んでいるのですが、12のレッスンのうち8レッスンを2時間くらいで読みました。自分がデザインと思っていたことは、早い段階で違うことがわかりました。綺麗なものを描く、どうやって組み立てるとかそういったことは5パーセントくらいしか出てきていないです（体感）。
気になった箇所をそれぞれ抜き出していきます。DeepLで翻訳済みです。原文はリンク先をご覧ください。
デザイナーの仕事は、画面上でピクセルを動かすことだけではありません。ボタンやタイプシステム、インターフェイスなどを作ることはすぐにできますが、それだけではデザイナーの仕事のすべてを網羅することはできません。デザイナーとは、問題を発見し、適切な質問をして、クライアントのために、あるいは自分自身のために、最良の解決策や選択をすることなのです。
https://www.figma.com/resources/learn-design/ethics/#:~:text=The%20reality%20as,or%20even%20yourself.
これですね。ボタンや文字、インターフェイスを作ることはすぐにできる。問題を発見し、適切な質問をして、対象となる人のために最良の解決策や選択をする。
いつも会社で開発している時にやっていることとまるっきり同じで驚きました。
職種としては私はエンジニアです。 スタートアップの自社開発企業です。
営業やカスタマーサクセスの方がお客様から聞いてきた課題、私や他のエンジニアが直接お客様から伺ったフィードバック、あるいはCEOからの新しい機能の提案を聞きます。それらに適切な質問を行い、最良の製品を作り上げます。
最初の頃はプログラミングそのものが難しく、プログラミングすることが自分の仕事だと感じていました。
しかし、実際に仕事をすると、適切な質問を行い、最良の解決策や選択を見つけることが仕事だと感じます。なぜなら、質問が適切でなく、解決策が間違っている場合に、完成品もまた、間違ったものになります。つまり、どれだけ優れたプログラミング技術を持っていても、適切な質問を行い、最良の解決策や選択を見つけることができなければ宝の持ち腐れです。逆に多少技術が伴っていなくても、適切な質問を行い、最良の解決策や選択を見つけることができれば良いのです。（汚いプログラミングだと、スケールさせづらいなど別の課題はあります）
このように、適切な質問を行い、最良の解決策や選択を見つけることはプログラミング、デザイン。何においてももっとも重要であると思います。抜き出して話しているので背景などが適切に伝わらない可能性もあります。figmaのtutorialを全て見てみることをお勧めします。
https://www.figma.com/resources/learn-design/lessons/
余談ですが、最良の解決策というのが難しく、お客様がこうしてほしいといったものを鵜呑みにはできません。なぜなら私はSaaSを作り上げています。１人のお客様への最適解が全ての利用者の最適解にはなりません。そういったところに別の会社がつけいるスキはあると思いますが。。
ダニエル・ブルカは、「エンジニアが近道をしてパフォーマンスを犠牲にしたとき、それがどのようにユーザーエクスペリエンスを損なうかを理解する必要があります。同様に、デザイナーがエンジニアにパフォーマンスに影響を与えるような変更を求めた場合、そのエンジニアはデザイナーが全体的に最良のデザイン決定を下すことができるように手助けをするべきであり、ただ単にデザイナーの要求に従うべきではありません。優れたデザインを実現するには、このような尊敬に満ちたコラボレーションが必要なのです」
とても同意します。しかし、私の場合、スタートアップということもあり、どうしても資金面が絡んできます。私はもっと正確にプログラミングを書きたいし、デザイナーはもっと自分が望むデザインを作り上げたいだろうと思います。しかし、先ほどの
「デザイナーとは、問題を発見し、適切な質問をして、クライアントのために、あるいは自分自身のために、最良の解決策や選択をすることなのです。」
を思い出してください。クライアントや自分自身とありますが、自分の会社も対象に入ると考えています。そうでなければ、会社の資金は底をつき、事業を継続できず、何も提供できなくなってしまいます。
自分が描きたいプログラムを、自分が描きたいデザインをすればいいのではありません。もちろん、それが理にかなっていれば良いのです。会社に価値を提供でき、お客様にも価値を提供できる。それらがとても大きな価値であり、時間に見あった価値を提供できるならば、その提案は正しいものだと思います。
もしかすると若干論点がずれているかもとは思いますが、エンジニア、デザイナー、会社、全てがコラボレーションすべきだと思っています。
デザインには多くの場合、視覚的な要素や存在があります。デザインを視覚的に具現化するには、見て楽しい、体験して楽しいものであることが理想です。使いやすさを重視した総合的なデザインを心がければ、美しさは後からついてくることが多いのです。
これはあまり意識できていなかったのでためになりました。
そういった体験をしたことはないのですが、心に留めておきたいと思います。
見て楽しい、体験して楽しいものであることが理想。 美しさは後からついてくる
リサーチの目標は、次のことに答えることです。対象となるお客様は誰か？なぜ彼らはあなたの製品を使うのか、あるいは使おうとしているのか？彼らのモチベーションは何か？あなたの製品に何を期待しているのか？あなたが解決しようとしている問題を、彼らは現在どのように解決しているのか？その他、あなたやあなたの製品開発に関連すると思われる質問をしてください。インタビュー対象者には、自由形式の質問をしましょう。彼らから洞察力を得て、あなたに心を開いてもらい、あなたが知らなかったアイデアを共有してもらおうとするのです。
会社でよくリサーチをするときにどうリサーチすればいいんだろうと思い、色々調べるのですが、上記のようにまとまっていることはあまりなかったと思います。直近でリサーチする機会があるので生かしていきたいです。
このインタビューは、対面でも、オフィスでも、お客様のいる場所でも行うことができますが、常にそれが望ましいです。もし、あなたが食料品店で買い物をする人向けの製品を作っているのであれば、食料品店に行って、そこで買い物をしている個人に話を聞くのがいいでしょう。Luke Wroblewskiは、「他社がやっていることを見るのはやめよう。既存の、あるいは潜在的な顧客ともっと多くの時間を過ごすことから始めよう。" とルーク・ウォレスキーは念を押しています。
これは覚えがありすぎて個人的にとてもダメージを受けるのですが、よく競合他社を参考にします。競合他社は所詮競合他社です。完全に同じことをしようとしていません。もし完全に同じことをしようとした場合、資金力で上手いことやればなんとかなるかもしれませんが、、、
大体は少し違った観点から似たような課題を解決すると思います。 例えば、大手が作っている製品は世界中のたくさんの人をターゲットに作られているので、誰が使ってもわかるように作られます。しかし、それが個人の使いやすさにマッチするとは限りません。自分だけをターゲットにするなら、もっと使いやすくできる部分がきっとあるでしょう。
まず、自分のターゲットに聞き取りを行い、次に競合他社も参考にしていきたいです。今はビザスクなど聞き取りできる環境があり良いですね。
リサーチを行う際には、人々が製品に何を求めているのかを考える必要があります。彼らの過去の行動を理解するための質問をしなければなりません。製品に何を求めているのかを直接聞いても、有益な洞察は得られないことが多いのです。彼らが以前にどのように問題に対処したか、あるいは直面したかに焦点を当てましょう。
先ほどの「リサーチとは」に関連してきます。 確かにそうです。あなたが何か困っていたとして、「じゃあそれを解決してあげるよ、何が欲しいの？」と言われてもあまりパッと思いつきません。どうやって解決したらいいかわからないから困っているのです。なので、上記で挙げたことは理にかなっていると思います。多分何かしらの方法で解決しているはずなので、それをうまくソフトウェアやデザインに落とし込めると解決できるでしょう（とても難しいですが。）
プロトタイピングのように、ピクセルで構築した以上の体験を共有するためには、ストーリーを共有することで、全体的な体験を把握しやすくなります。
ちょっと端折っているので、原文を読んで欲しいところではあります。
プロトタイピングを共有するときに、一部を適当に作ってプレースホルダー的に作ることがあるが、それをうまく伝えないと、プロトタイピングだと思わなかったよ。製品だと思って作ってしまった。みたいな無駄な時間が発生するかもしれない。という注意事項だったと思います。気をつけます。
シンプルさとは、ノイズを減らすことと、必要な情報を難読化することのバランスです。しかし、単純化しすぎるとリスクがあります。アプリデザインの経験則としては、お客様が標準的なアクション（お客様が最初に製品を使いたいと思ったアクション）を3～5回のタップで実行できるかどうかが重要です。
シンプルにかくのが大事だとわかってはいますが、きっとこれからデザインを学んでいく上で、どうしても複雑に書いてしまうんだろうなと思っています。
3~5回のタップというのを基準に作り上げていけたらいいなと思います。
多分それ以上のタップ数になるということは、自分がその課題をうまく理解してソフトウェアやデザインに落とし込めていないんだと思います。
これ以外にも、諦めないで続けていこう。大体の人は途中で諦めてしまうけど、その先でもっと楽しくなるんだよ！！というような基本的なことも書かれており勉強になりました。
こちらの記事も参考になるかも知れません