kintoneのプロダクトデザイナーがStructured Designと向き合った話
この記事は、[CYBOZU SUMMER BLOG FES '24] (Design Stage) DAY 14の記事です。
こんにちは、サイボウズのkintoneプロダクトデザイナーのおぎしおです！
私は、サイボウズのプロダクトデザインチームの中で、主にデザインと実装をつなぎこむ「Structured Design」の部分に注力して、毎日お仕事をしています。
Freeform DesignとStructured Design
「Structured Design」は、ソフトウェア開発におけるデザインプロセスのフェーズの話で、Freeform DesignとStructured Designの二つのフェーズがあります。
Freeform Design
アイディアを出し、デザインを作っては壊す。どんなデザインがベストなのかを固めるフェーズ
デザインは手書きでもよく、デザインの方向性、可能性を見つける
Structured Design
デザインを整理し、より実装に落とし込みやすいようにするフェーズ
デザインの案を実装できる形にする
さらに詳しい内容は sakito さんの記事に詳しく掲載されているので、ぜひこちらも併せてご覧ください！
今回は、サイボウズにおける「Structured Designに注力しているデザイナー」がどんなことをやっているのかについて、記事を書いてみようと思います。
"Structured Design寄り"デザイナーのお仕事
サイボウズのkintoneプロダクトデザインチームでは、メンバー個々人に任されている役割はあるものの、時に領域をまたがり、チームワークで業務を進めていく"サイボウズの企業理念"が根付いています。
そのため、私の役割についても、あえて"Structured Design寄りデザイナー"という表現でご紹介していければと思っています。
私は今、チームの中でプロダクトデザインチームに属しながらkintoneのデザインシステムの構築を行なっているkintoneデザインシステムチームのみなさんと一緒にお仕事をしています。
具体的にどのようなことをしているか？というと、プロダクトデザインチーム内で決まったデザインをもとに
Figmaでコンポーネントライブラリを作成
デザインの思考を整理し、デザイントークンに落とし込む
ドキュメントの整備
など、kintoneデザインシステムにデザインをつなぎこむ業務をメインに活動しています。
ちなみに。
kintoneデザインシステムチームは、デザインテクノロジスト職能がメインで仕事をしており、実装とデザインの両面に強みを持つメンバーのもと、デザインシステムの構築が行われています。
Structured Designで大事なのはコミュニケーションと情報整理
Structured Designを進めていく中で、私が大事にしているのは「コミュニケーション」と「情報整理」です。
kintoneデザインシステムチームでは、実際にデザインを作成したデザイナーのファイルをもとに"どのような意図で、そのデザインが作成されたのか"意図を読み取り、その意思を基にデザイントークン化したり、Figmaのアセットを作成し、チームに公開しています。
例えば、iconとtextで構成されたコンポーネントがあったとします。
"iconとtextが連動して同じ色となるのか" "iconやtextで利用可能な色を自由に設定できるできるのか"など、デザインの思想によってアプローチが異なります。
作成元のデータや、それまでのやりとりを読み「こういう意図で作成されたのではないか」という仮説を立てた上で、ライトに担当デザイナーにヒアリングを行います。
また、収集した情報をもとに構造の整理を行い、どのようにToken化するのか／コンポーネント設計を行うかを、検討していきます。
検討結果をもとにkintoneデザインシステムチームとすり合わせを行い、実装へとコマを進めていきます。
デザインの意思を実装としてSemantic Tokensに落とし込む段階では、Figmaから直接トークンを作成することもあります。
デザイントークンに関しての詳しい情報は、弊社デザインテクノロジストの amishiratori さんが記事を書いているので、こちらもぜひご参照ください！
デザイン基盤に関われるのも"Structured Design寄り"のデザイナーの面白み
Structured Designと向き合うデザイナーは、問題を解きほぐし、適切なサイズに分解し、ひとつひとつにこつこつと取り組んでいくといった、とても地道な作業を行う側面があります。
しかし、この業務に全力で取り組むうちに
デザインと実装面のつなぎこみ視点からデザインレビューを行える
より実装に落とし込みやすいデザイン作りのサポートができる
中長期の視点で、デザインシステムの未来を作っていける
といった、デザイン基盤の未来を考える面白さを業務の中で感じています。他にも
アジャイル開発のMVP的な思考を使って、素早く価値提供できそうなissueを作る
リサーチ結果を、素早く情報整理／構造化する
破綻しないCSS設計を考える
ワークショップなどを通じてチームの課題を見つける
など、一見Structured Designとは遠いところにありそうな『過去に注力して得た技能』が活きてくる面もあり、そこにもこの仕事の面白みを感じています。
私自身も前職ではリサーチメインの仕事をしていましたし、もしもこのように「Structured Designにチームで取り組んでみたいけど、過去の経験がないから…」と足踏みしている方がいたら、どんな小さなことでも良いので、実装がより効率的になる自社の課題をみつけ、トライすることから始めてみてはいかがでしょうか。
チームワークでkintoneの未来を支える
また、こういった"Structured Design寄り"の業務には、デザイン改善や新機能を考えるデザイナーとの協業が欠かせないため、仲間へのリスペクトを忘れずに仕事をすることも大事だなと思います。
私もサイボウズでは、育児をしながら社内制度である働き方マッチング(※執筆時の制度です)を活用し週4日の短時間で業務を行なっているため、文脈がわからず質問したり、不明点を確認をすることも多くなってしまいます。
フラットに色々な話をできるような雰囲気作りのうまいメンバーが多く、コミュニケーションも活発なため、時間制約によって生じてしまう「溝」の部分を、メンバーに支えてもらっていることを実感します。
このように個性やスキル、バックグラウンド、住んでいる場所の違うメンバーのあつまるチームで、よりよい方法を探していくところがサイボウズのプロダクトデザインチームの良いところだなと感じています。
今後も、チームメンバーと共に、kintoneの未来を支えていければなと思っています。
サイボウズでは一緒に働くメンバーを募集しています！一緒にチームワークあふれる社会を創りましょう！
スキやコメントを頂けたら執筆の励みになり、とても嬉しいです😄