2022.06.17
「noteらしさ」を共通言語化。noteが作る、全員参加型のデザインシステム

「noteらしさ」を共通言語化。noteが作る、全員参加型のデザインシステム

note社では社員が急増する中で「noteらしさ」を、どう共通言語化していった? デザインシステム構築プロセス、その考え方について、デザイナー沢登達也さん、UXエンジニアuto-usuiさんの登壇レポートをお届けします。

0 0 2 2

※2022年3月10日に開催された【Frontend Talk 〜デザインシステム構築のリアルな裏側〜】より、note株式会社のUXエンジニアuto-usuiさんと、デザイナー沢登達也さんのセッションをお届け。書き起こし形式で編集したものをお届けします。

目次
【1】社員急増に伴って、デザインシステムが必要に
【2】コードとデザインをつなぐ
【3】デザインをみんなで使う
 └トーンオブボイス
 └イラストシステム
 └デザイン原則

+++

【1】社員急増に伴って、デザインシステムが必要に

沢登:
こんにちは、デザイナーの沢登です。今日は、noteのデザインシステムの始まりとこれからについてお話しします。

まず、noteのフェーズですが、まさに社員が増えているところ。また、1プロダクトではありますが、マイクロサービス化が進んでいます。社員の急増にあたり、MVV(ミッション・ビジョン・バリュー)の浸透も進んでいます。

一見、順風満帆に見えますが、いろいろな課題も見えてきました。

+++

・UIの品質…人が増えることで似たようなコンポーネントが増えてしまった
・スキルセット…スタイリングをデザイナーがやっていて属人的な面が大きい
・noteらしさ…人が増えたことで「noteらしさ」の解釈が多様になってきた

これらの課題を解決するため、僕とusuiさん、2人でどういうアプローチを取ればよいか考えて活動しています。

ここからは「コードとデザインをつなぐ」と「デザインをみんなで使う」の2点についてお伝えできればと思います。

+++

【2】コードとデザインをつなぐ

uto-usui:
noteでUXエンジニアをしているuto-usuiです。私のほうでは「コードとデザインをつなぐ」という題目で話をしていきます。

noteに入社したのは2021年で、デザインとエンジニアリングの横断する課題を解決するために頑張っています。

+++

まず、UXエンジニアが何をしているのか。ざっくりですが、「なんかいろいろなところにいる人」です(笑)デザインチームとフロントエンドチームのどちらにも属しつつ、いろいろなプロジェクトをやっています。どこからでも問い合わせとかレビューを受け付けていたりもします。

役割は「ルールを配っていく」こと。蓄積された今までのnoteの資産から、ルールを抽出したり、目指したい方向に向かって行くための道具を作って共有したり。具体的にやっていることはこんな感じです。

+++

マークアップとかスタイリング、figmaをコードに起こすところ、その自動化、デザインのルール決めですね。関わっているプロジェクトで言うと、こんな感じです。

+++

デザインシステムとアクセシビリティ、パフォーマンスですね。アクセシビリティとパフォーマンスは、デザインシステムより前からプロジェクトとしてありまして、どれもワーキンググループになっています。

いろいろなチームの人がいるので、いろいろな意見が聞けるのが良いところ。出た意見や、やりたい方向性をデザインシステムで吸収していく。そのためのツールとして提供していくイメージ。

やっていることをブレイクダウンすると

「ルールをツールでラップすること」

かと思います。ルールを配るんだけど、それをツールに適用して配っていくことで、ルールを意識せずとも良くなっていきます。「いろいろ決まりがあるな、覚えなきゃ」ではなくて、「使っているだけで、使ってる方もサービスもユーザーさんもみんなが幸せになれる」といった状態を目指しています。

そして「デザインシステムを作ろう」につながります。なぜデザインシステムを作りたいのか。分解すると、こういう感じです。

+++

「一貫性のある体験」は「UX」、「noteらしさの定義」は「ブランディング」とも言えます。「開発のヒント」は「社内向けのナレッジ」ですね。

特に最後に書いてある「みんながデザインに関わる」は「夢」になっていて。みんなが安心してデザインに関われる環境を整備していく。ここが目的です。この場合の「みんな」は、デザイナー、エンジニアだけじゃなくて、ほかの業種の社員のみなさんです。

そして実際、何を作っていくのか。カテゴライズすると本当にいろいろな項目があります。

+++

noteのデザインシステムのプロジェクトでは、それぞれにオーナーがいます。もちろん「動いている部分」と「動いていない部分」がありますが、一番上にあるように、デザイン原則に紐づいた運用をそれぞれがして行く方針です。デザインシステムチームは「そのオーナーの集まり」と思ってもらうとわかりやすいかと思います。

その中で僕はコンポーネントライブラリーをやっています。次にコンポーネントライブラリーの要件です。

+++

いま、noteではNuxt 2を採用しましたが、Nuxt 3への移行が難しくなってきたので、Reactへの分割、移行する計画が立ち上がっています。ReactとVue.jsが混在する場所にはSvelteを採用するなど、3つのフレームワークが同居する状況があり、それらを横断するものが求められています。

なので、段階的・透過的に、小さくリリースして試せて、他に影響しないものを作る必要があって。そういった背景もあり、新しいプロジェクト進行と同期的に進めることで、プロジェクトに試してもらって、そこでフィードバックを得ていく。そういった進め方もしています。デザインとコードを連携させることで、デザイナーとエンジニアの距離を縮めたり、同じ方向を向きやすくなるので、連携もやっています。

目指しているのがレイヤー構造を持つライブラリーです。どんなレイヤーかというとこんな感じです。

+++

まず上から「デザイントークン」は変数とセットです。デザインの最低限のアイデンティティを表現するものですね。

次に、画像・アイコンなどの「共通のアセット」類で画面を作る「UIライブラリ」です。この3層に分けてコンポーネントライブラリを構成します。それぞれの作り方を見ていきます。まずはデザイントークンですね。

+++

手順で書いてみましたが、まずFigma TokensはFigmaのプラグインで、Figma上のカラーやタイポグラフィー、スペーシングなどを変数として保存し、JSONをGithubにコミットし、PRを作ってくれます。すごくいいプラグインでドキュメントも充実しています。ここに全てのCSSのカスタマープロパティとか、その変数になるものを格納しています。

そして Style Dictionaryはさっき作ったトークンのJSONを、css propsやSass variables、styled-componentsのJSON、tailwind.configに変換してくれるパッケージになっています。

このtransformsというAPIが便利で、単位・型をそれぞれのフォーマットに合わせて変換できるものになっているため、一度にすべての環境に配れるようになっています。それらをGitHub Actionsでフローを自動化しています。Figmaを更新すると各ドメインに対応したデザイントークンを自動でリリース出来るようになりました。

+++

次は共通のアセットですね。こちらでは直接FigmaのAPI利用してFigma上でコンポーネント化した画像を、GitHub Actionsのワークフローディスパッチを使って抽出している。そしてS3にアップロードしてくれます。S3のバケットはFastlyにつながっていて、オフロードしてくれる。ご存知の通りFastlyはイメージオプティマイザーが何でもやってくれるので、後からいくらでもURLパラメータで変換とか、クロップとか、最適化とか、エンジニアの方で自由自在に行なえます。こちらもFigmaを更新すると最適化され、リサイズ可能な画像が配信できるようになりました。今回画像のみ説明しましたが、アイコンの方はパッケージとして配信している形です。

次にUIライブラリーを構成しているのはこちらです。

+++

React LayerとStorybookとTailwind CSS、この3つがポイントです。Tailwind CSSはデザイントークンのところで生成したものを流用しているので、React LayerとStorybookについて見て行きます。

+++

ReactのUIライブラリも、レイヤー構造にしています。Stateはlocal storeで、Behaviorはイベントやアクセシビリティの振る舞いを定義しています。それらをまとめるためにComponentsが、State、Behavior、Taillwind CSSのスタイルを構成しています。

「類似コンポーネントを生成しやすい」と書きましたが、UIライブラリでいくつも類似コンポーネント内部で作るよりは、利用される各ドメインでstate・behaviorでドメインに依存した類似コンポーネントを簡単に利用できるよう、レイヤー構造にしています。

+++

そして、Storybookは定番ですが、テストやガイドの充実を重視しています。Figmaでデザインと実装を相互にパッと確認できるようにしたり。トピックとしてはatomic designをもともと採用しましたが、それをやめて機能別のファンクショナルなカテゴリーでグルーピングするようにしました。理由としては入れ子構造にする必要性を感じなくなったのと、利用用途によって見通りよくしたかったからです。

ということで、抽象的にも利用できる、拡張しやすい自由度の高いUIライブラリになっているはずです。そしてテストやFigma連携デザインとの整合性を担保しやすいUIライブラリを目指しています。このようにコンポーネントライブラリを見てきましたが、デザインとコードが同期しているコンポーネントライブラリを目指しています。

デザイナーがFigmaを更新すると、エンジニアが利用するリソースのバリューが更新されている、デザイナーとエンジニアがお互いの実装が期待通りか、いつでも簡単に確認できる、そういった世界観がいいなと思っています。

そうすることで、みんながプロダクトに集中できる環境、みんなでUXデザインに取り組める環境を作ることになると思います。コードとデザインをつなぐことで、みんなのつながりを強くできると実感しています。ということで、UXエンジニアは楽しいと言うことをお伝えしておきます。

【3】デザインをみんなで使う

沢登:
ここからは改めて僕から「デザインをみんなで使う」についてお話します。

noteにはいろいろな職種の方がいまして、こういった方々もデザインシステムを使える状態を想定しています。最初に目指すのはデザイナーとエンジニアが使える状態ですが、ゆくゆくは「みんなが使える状態」を目指しています。

+++

デザイナーやエンジニアだけが使えるデザインシステムでは、要件としては不足していて。「みんなが使える、みんなが参加できる全社お役立ちキット」を目指しています。

ここから、いくつかの事例に関して説明します。全部で3つあります。

トーンオブボイス
・イラストシステム
・デザイン原則

まずはトーンオブボイス。聞きなれない言葉ですが、「サービスの人格」や「サービスの発する言葉」を、ルール化して決めるものと捉えていただければと思います。

たとえば、SNSで公式のツイッターアカウントがどういう言葉づかいをするかなど、そういうお話です。

もともとnoteは「noteさん」という人格を2年ぐらい前に作っており、もともと事前にシステムを作る前からそういう話は動いてました。これを具体的に使えるようにしておくのが、トーンオブボイスの取り組みの1つです。

+++

「どれぐらいの言葉の温度感で、カジュアルさはどれぐらいなのか」を決め、共通認識を持つために動いています。これは主にPRとかディレクターチームなどが使えるように進めているので、PRやディレクターとワークショップしながら決めています。

+++

まとめると、トーンオブボイスとは

・サービスの人格を決める
・発する言葉やバランスがルールとして分かる状態
・noteらしい言葉遣いはどんなものかが統一される

を目指しています。こちらも絶賛開発中です。

次にイラストシステムです。イラストシステムは普段耳にする方も多いかもしれないですが、noteには社員としてイラストレーターが在籍しており、いろいろなトーンをプロダクトでリリースしながら検証している状況です。

+++

このイラストは結構種類がありますが、それぞれトーンが違っていて、大体この1年間で5種類以上のトンマナをプロダクトに反映しています。

イラストシステムと呼ぶくらいなので、システム化も進めています。

+++

例えば、左側だとFigmaのレイヤー構造でイラストが生成できたり、右側はillustratorでパーツを組み合わせ、デザイナーであればバナーぐらいなら作れる状況を作っています。このイラストに関しても、例えばPRが「外部発信のためにイラストを使いたい」というケースもあるため、社員向けにはイラストカタログを作るなどして共有しています。

イラストシステムに関しても、目指すのは「誰でもイラストを使える状態」です。そして「noteらしいイラストを提供する」というミッションがあります。

あとはリリースしながら検証していく。というのも、すごく時間をかけて議論するより、 良さそうなテイストをどんどんリリースしながら検証を進めます。

次に「デザイン原則」についてです。デザイン原則は聞いたことがある方が多いと思いますが、全てのデザインシステムのベースになる考え方で、先ほどのトーンオブボイス、イラストシステムもデザイン原則の影響を受けています。

原則を作る前にまずステートメントを作る。これが大目標です。ここからぶれるとデザインシステムは失敗…というか、方向性としてぶれてるよね、と分かるようにするために作った地図です。

+++

デザイン原則はフレームワークを使い、短い時間で「バージョン1」を作りました。基本的に正しい原則になっているかどうかは、作って使ってみないと検証できないなと。そう思ったので、素早くバージョン1を作って運用し、微調整する前提で作りました。

デザイン原則をまとめると、

・まず70点を目指してリリースして使い始めること
・「バージョン1」を時間をかけずに作ること
・使って評価

を意識して運用しています。

ここまで3点の取組みをお話しましたが、共通して意識していることは「未完成で使い始めること」です。イラストであればプロダクトに反映したり、デザイン原則であれば使って運用したりしています。

あとは「みんなで使える」こと。デザイナーだけで決めて提供するよりは、そもそも作るところからみんなを巻き込んでいます。作ったものを提供し、そのあと運用されない・使われないことが一番のバッドケースだと考えています。作る段階から巻き込んで、それが結果的に認知につながるはずです。このあたりはプロダクトと同様ですが、小難しいとか、予備知識がいるとか、特定の場所まで行かないと使えない状況が生まれてしまうと、なかなか使われない状況が起きてしまう。なので、そのあたりを意識しています。

+++

まとめです。

noteのデザインシステムはみんなが参加して、簡単に「noteらしい」を作れ、良い体験を提供するためのものとして作っています。ここまで発表しましたが、noteのデザインシステムもまだ未完成な状態です。といっても実際、完成という状態はなかなか難しいと思っていて、作って継続することに意味があると思っています。noteでは、このデザインシステムを一緒に作っていきたいという方を募集していますので、ぜひ気軽に話を聞きにきてください。

(おわり)


編集 = CAREER HACK


関連記事

特集記事

お問い合わせ
取材のご依頼やサイトに関する
お問い合わせはこちらから