社内のデザインチームに向けたまとめだが、どうせなら公開する。
インターネットサービスを開発する事業会社のインハウスデザイナーという前提。

なぜ？から始められること

なぜこれをやるのか？そこに向き合うこと。
上から降りてきたタスクをこなすだけにならないように。

なぜやるのか？他にもいい方法があるんじゃないか？そもそもこの課題設定はあってるのか？さらにこの課題は解決する必要があるのか？

前提を疑い、デザインする対象を広げる

前提を前提として受け入れるのではなく、前提条件自体を「デザインする対象」として捉えられるか？

「〇〇はこういう方針だから〜」→その方針を修正した方がもっと良くなるのではないか？
「〇〇機能の仕様的に難しそう」→その仕様を見直すことでより良い課題解決ができるんじゃないか？
「仕組み上それはできない」→本当にできない？詳しい人に聞いてみたら違う答えが返ってくるかも？
「実装コストが高いと言われた」→どれくらい高いのか？具体的に掘り下げて理想と現実の制約を天秤にかけたか？

根本課題は何か？

今しようとしている課題解決の根本はなんだろう？

2週間かけてその施策を実装するより、実は2ヶ月かけて根本解決した方がトータルでいい成果を生まないか？

思考パターンをたまには変えてみよう

論理的思考で組み立てる仕事ばかりになっていないか？

発想を柔軟に、逆張り的に考えてみてもいいし、チームに対してサプライズする意識で考えてもいい。
ロジック抜きで発想したアイデアが芯を食うときもある。もちろんそのあとは論理的にまとめよう。

思考パターンを意識して変えることで、自分なりにデザインの可能性をリフレッシュしよう。

申し訳なさ、恥ずかしさと戦おう

もっとよくしたいけど、エンジニアさんにこれ以上修正依頼するのは気が引ける…
指摘したいけど、気を悪くされそうで腰が重い…
100人もいるSlackで意見しづらい…

気持ちはとてもわかる…。

けれど、プロダクト、クオリティ、未来のためにアクションしてみる方がいいかも。
どうしても気が重いなら隣の仲良い同僚にそのアクションを託してみるとか？
または、指摘/提案とセットで代替案を出したり、優先度を伝えたり、相手が話を聞きやすい工夫をしてみるとか？
とにかく、「何もしないよりマシ」のスモールアクションをしてみよう！

負債への意識

今計画しているデザインは、未来の自分達を苦しめないだろうか？

その施策単位で見るといいデザインかもしれない。プロジェクトもノリノリかもしれない。
でも数ヶ月後の機能追加時に身動きがとりづらいデザインになってないか？
似たような意図のコンポーネントがあった場合など、近い将来の変更コストが倍にならないか？
負債に対してそのデザインはどれほどの価値があるか？

また、開発のシナリオを設計しよう。
突貫開発で小さく速くリリース、はよくある話。それをリリース後に改善して磨き上げる予定は立ててるか？立ててないなら妥協ラインを見直した方がいいかも？（小さくするために妥協した成果物が下手したら1年以上世に出てしまうことへの危機感）

また、成果が得られなかったら実装を取り下げる意思決定などはできてるか？
ディシジョンツリーを作ろう。

リリースされるものがすべて

美しいデザインカンプ、素晴らしいプロトタイプ、スマートなジャーニーマップ、それらを作り切って満足してないか？

実装されたものをリリースまでひたすら触り続けよう。理想に近づいてるか？もっと良くできないか？
QA工程に気持ちを任せすぎていないか？

計画中のデザインを人の目に触れさせよう

デザイナーチームでもいい。ユーザーテストでもいい。家族でもいい。

見せて反応をもらおう。

もらったフィードバックやアドバイスをどう受け入れるかが腕の見せ所。そもそももらおうとしないのは基本的にはもったいない。

逆に、チームメンバーの仕事に意識的に目を向けよう。自分の仕事にだけ集中してればOK、ではなく、チームメンバーの仕事も自分が携わるプロダクトのアウトプットに繋がる意識を持ち、積極的にレビューしよう。赤の他人じゃないんだし、お節介くらいがちょうどいい。

表層にちゃんとこだわろう

スマートなデザインプロセスで順調だとしても、表層となる視覚表現にじっくりこだわるのを忘れないようにしよう。

数pxのレイアウト、0.1秒のトランジション、アイコンの造形、すべてに意思を持ってデザインしよう。

ビジュアルとしてバランスが悪いって言っても、これは既存コンポーネントを使い回したから仕方がない？
もしかしたらその既存コンポーネントに改良の余地があるかも。前提条件に対して働きかけよう。

共同作業の生産性を考えよう

自分1人の作業スペースではないので、チームメンバーが意図を汲み取りやすく、作業効率が高く、レビューしやすいデータ作りを心がけよう。

ルールやガイドラインが不足していることで、何を基準に作っていけばいいかわからない？じゃあそのガイドラインを作っちゃおう。自分で作るのが億劫ならチームメンバーに提案してみよう。

クオリティの目線を上げ続ける努力をしよう

現状維持は素晴らしいことだけど、世の中は常に進歩してるので維持するだけだと相対的には後退になってしまう。

1年前に褒められていたクオリティラインが今だと褒められないかもしれない。それはチーム、ひいては社会の目線が一個上にいってるからかも。

理想的には…
市場をリードするような視座でデザインしよう。

車輪の再発明になってない？

車輪の再発明を否定するわけではないけれど…
過去に同じようなモノ作ってるかも？隣の事業部がすでに知ってるかも？プラットフォームのガイドラインで定められてるかも？幅広く気にかけよう。

そこを分かった上で、あえて車輪の再発明をするのはロマンがあっていいかもね。

言葉にこだわろう

（サービスのWriting ガイドラインがある前提）

ガイドラインと照らし合わせつつ、もっと簡潔にできないか？もっとわかりやすい言い回しはないか？過去に似たような文言を考えてないか？さまざまな観点で考え抜こう。

倫理的であること、誠実であること

誠実なデザインをしよう。

どうしても、事業を伸ばすために人の行動をコントロールするデザインを求められがちだけど、その中に自分なりの境界線を見つける旅に出よう。
できればサービスブランドとして定められるといいけど、OKとNGがパキッと分かれるわけではなくグラデーションになっているはず。
誰かの言うことを鵜呑みにせず、自分の中の倫理や誠実さに目を向けよう。

おわり

ホントはもっとあるけど…。

こういうのは言葉にしていかないとなかなかチームメンバーには伝わらない。言葉にしていこうー