配属から一年 デザイン検討で意識したい5つのこと
この記事は、[CYBOZU SUMMER BLOG FES '24] (Design Stage) DAY 12の記事です。
こんにちは！サイボウズのプロダクトデザイナーのKayaです。
昨年7月にkintone デザインチームに配属となり、早一年が経ちました。
配属後は、OJT形式で3人の先輩に3ヶ月ずつメンターをしてもらいながらデザイン業務に取り組んできました。kintone デザインチームには現在7人のデザイナーがいるのですが、それぞれにデザインの進め方や考え方も様々な中で、自分に合う進め方や真似したい部分を吸収させてもらうことができて、とても充実した期間でした。
現在はOJTで学んだことを活かしながら、引き続きフォローをしてもらいつつ基本的に自立してデザイン業務に取り組んでいます。
今回、私がOJT期間を含め配属後一年の中で学んだことから、自分なりにデザイン検討時に意識したい5つのことをまとめてみました。
①そのデザインの価値をユーザーにどう説明するか？を考えること
「この新機能/改善はユーザーにとってどんな価値があるの？」を都度確認しながらデザイン検討するようにしています。
個人的に考えやすいなと思うのは、「リリースノート（kintone アップデート情報）に書くとしたらどう書くか？」という問い方です。
新機能を設計するにしてもデザイン改善をするにしても、デザイン検討の段階からリリースノートでユーザーにどのように説明するか（その改善がユーザーにどんなメリットをもたらすか）を想定して価値を明確にしておくと、デザイン案の検討や比較をするときの方針がぶれにくくなります。また、優先的にリリースすべき部分と、後続で検討してリリースする部分とを見極める指標にもなります。
②いろんなUIパターンをインプットすること
デザイン案の"勘所"みたいなものがまだまだな分、できる限りいろんなパターンを発散するため、なるべく既存サービスやデザインシステムの調査・インプットに時間をかけています。
必ずしも必要としているものが見つかるわけではないし、そのまま流用していいわけでもないですが、発想を広げたり自分のデザインパターンの引き出しを増やしたりという意味で、他サービスをたくさん調査してスクリーンショットを集め、類似の機能やコンポーネントの表現をインプットするようになりました。
業務では普段、mobbinやDesign Systems Databaseをよく使っています。
Design System Database
③ロジックとデザイン案を往復すること
慎重さゆえか、私はまずロジック（課題の分析や解決策の方針）をがっちり固めてからUIを作る、という手順を踏まなければと囚われていたところがあります。ただ、頭の中や文字ベースの思考だけだと想定しきれない部分も多く、現状起点でばかり考えていても発想が広がっていかないというのが実感としてありました。
実際に業務で思考が進まなくなってしまったとき、ある程度ロジックの部分が煮詰まったら思い切ってステップジャンプしてTo Beのデザイン案を作ってみると、新しい発見があり、ロジック部分の思考が進むという気づきがありました。最初はロジックとUIとに繋がりがなくても、理由を後付けしたり、ロジックとUIを寄せる作業をしたりすることで、繋がりを見出せることもあります。
一方で今度は具体的なデザイン案の方に過集中してしまうと、本筋から外れたり重要じゃない枝葉の部分で悩んで収拾がつかなくなったりするので、時にロジックに立ち返り、時に手を動かすというように、何度も行き来しながらデザインを考えることを意識しようと思っています。
④デザインを言語化すること
ある先輩が、FigmaやGitHubのIssueに思考過程や分析内容、他の人にもらったレビューなどを時系列に逐一丁寧に残しているのを見て、同じようにログを残すことを最近意識し始めました。
このログを残すという作業をやってみると、思考過程を忘れないということや他の人に引き継ぎやすくなるということ以上に、デザイン案に対する思考が深まるという点で効果を感じています。
作っているものに対して「どういう仮説を持ってその案を作ったのか？」「どうしてそう考えたのか？」を、誰かに説明する前提で都度言語すると、誰かの視点を意識することで検討しきれていない部分や説明が怪しい部分に気づくことができて、検討がより深まる気がします。
ちなみに最近のkintoneデザインチームの試みとして、デザインの検討ログを個人/チーム内に閉じず、kintone上のオープンな場所で発信するということをやっています。
PMやエンジニアに進捗状況を共有できることに加え、誰かに伝わるように言語化しようというモチベーションを持てて一石二鳥です👌
⑤レビューのもらい方を工夫すること
チーム内のデザイナーやPMにレビューをもらうとき、準備やテキストメッセージを書くのに時間がかかってしまったり、レビューをお願いしたものの上手く活かせなかったりと、未だにレビューをもらうのに苦戦しがちです。
その中で心がけているのは、まずは簡潔に伝えることです。前提の説明や経緯を事細かに伝えたくなってしまいますが、いろんなデザインタスクが並行している中でレビュワーには負担がかかってしまうので、できる限り重要なことだけシンプルに伝えます。
また、レビュワーが迷わないようにどんな観点でFBをもらいたいかを明確に伝えるのも重要だなと思っています。案の発散を手伝ってほしいのか、絞りたいのか、推し案の正当性を高めたいのか、など。
私はよく自分の判断に自信が持てずにいくつかの案を見せて「どの案が良さそうですか？」と中途半端に聞いてしまうんですが、「絞り込むにはどういう観点がありますか？」と聞けるようにしたいなと思っています。
まとめ
この記事では、配属後一年を経て学んだデザイン検討時に意識したい5つのことをまとめました。中にはまだ実践しきれてないものもありますが、これから着実に実行していけたらと思っています。
最後まで読んでくださりありがとうございました！
一緒にサイボウズで働いてみませんか
サイボウズでは一緒に働くメンバーを募集しています！一緒にチームワークあふれる社会を創りましょう！
この記事が気に入ったらサポートをしてみませんか？