社員急増で生じた「noteらしさ」の解釈多様化　UXエンジニア×デザイナーが目指す“全社お役立ちキット”

noteのフェーズと今持っている課題

沢登達也氏（以下、沢登）：「noteのデザインシステムのはじまりとこれから」について発表します。今日はエンジニアとデザイナーの1名ずつ話すので、自己紹介はそのフェーズでします。今日は「なんで始めたのか」という経緯と、「コードとデザインをつなぐこと」、「デザインをみんなでつかう」という3点についてお話しします。

今回盛り込めなかった内容が非常に多いので、ハッシュタグで質問をしていただくか、記事にする予定もあるのでそちらを読んでいただけるとありがたいです。

「なんで始めたのか」から話していきます。まずnoteのフェーズの説明からすると、noteは社員が非常に増えて、1プロダクトではあるんですがマイクロサービス化とMVVの浸透が進んでいます。なので社員がミッションを掲げたり、バリューを実行するということが増えています。

順風満帆かと思いきやいろいろな課題が見えてきました。課題が3つありまして、UIの品質は人が増えることで似たようなコンポーネントが増えてしまったり、スキルセットはスタイリングをデザイナーがやっていたり、けっこう属人的な面が大きかったり。人が増えたことで「noteらしさ」の解釈が多様になってきているという課題が見えてきました。

これらを解決するために僕とusuiさんの2人で「どういうアプローチを取れば良いか」というのを考えて活動しています。「コードとデザインをつなぐ」というところと、「デザインをみんなでつかう」利点についてこれから話していきます。ではusuiさん、お願いします。

UXエンジニアの役割は「ルールをくばっていく」こと

uto-usui氏（以下、usui）：では「コードとデザインをつなぐ」という題目でお話ししていきます。内容と時間の関係上、駆け足になってしまいますがよろしくお願いします。

uto-usuiと申します。noteでUXエンジニアをしています。noteに入社したのは2021年の春くらいで、デザインとエンジニアリングを横断する課題を解決するためにがんばっています。趣味はいろいろあるので気が合う方はお友だちになりましょう。

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

実際に何をやっているかというと、「ルールをくばっていく」というのが役割かなと思っています。今まで蓄積されたnoteの資産からルールを抽出したり、目指したい方向に向かっていくための道具を作って共有していくということですね。具体的にUXエンジニアがやっていることは（スライドを示して）こんな感じです。

マークアップやスタイリング、Figmaをコードに起こすところやその自動化。あとはデザインのルール決めですね。関わっているプロジェクトでいうとこんな感じです。design-systemとaccessibilityとperformanceですね。accessibilityとperformanceはデザインシステムより前からプロジェクトとしてあり、どれもワーキンググループになっていて、いろいろなチームの人からいろいろな意見が聞けるところが良いなと思っています。

そこで出てきた意見や、やりたい方向性をデザインシステムで吸収できる部分をツールとして提供しています。「ルールをツールでラップする」と書いたのですが、やっていることをブレイクダウンしていくと、ルールを配るんだけど、それをツールに適用してきちんと配っていくとルールを意識せずとも良くなるというか。

「いろいろ決まりがあるな、覚えなきゃ」というよりは、サービスやユーザーなど使っているほうもみんなが幸せになることを目指しています。つまり、「Design System つくろう」というところにつながっていくということですね。

「なんでデザインシステムを作りたいんだっけ」というのを分解するとこういう感じで、UXやブランディング。あとは社内向けのナレッジとかですね。特に最後に書いてあるところが夢になっていて、みんながデザインに安心して関われるような環境を整備していくということが目的になっています。この場合の「みんな」はデザイナー、エンジニアだけではなくて他業種の社員のみなさんもです。

実際に作っているもの

実際に何を作っていくのか。カテゴライズをしていくと本当にいろいろな項目があるなと思っています。noteのデザインシステムのプロジェクトではそれぞれにオーナーがいます。もちろん動いている部分と、まだ動いていない部分はあるのですが、1番上のデザイン原則に紐づいた運用をそれぞれがしていくという方針です。デザインシステムチームというのはそのオーナーの集まりのようなものです。

コンポーネントライブラリの要件とレイヤー構造

その中で僕はコンポーネントライブラリをやっています。ということでコンポーネントライブラリの要件ですね。今noteではNuxt2を採用しているのですが、Nuxt3への移行がちょっと難しくなってきたので、Reactへ分割や移行をする計画が立ち上がっています。

ReactとVueが混在する場所にはSvelteを採用するなど、3つのフレームワークが同居する状況があって、それらを横断するものが求められています。なので段階的・透過的に小さくリリースして試して、他に影響しないものを作る必要があります。新しいプロジェクト進行と同期的に進めていくことで、プロジェクトに試してもらって、そこでフィードバックを得るという進め方もしています。

デザインとコードを連携させていくことで、デザイナーとエンジニアの距離を縮めたり、同じ方向を向きやすくしています。ということで、「レイヤー構造を持つライブラリ」を考えています。

レイヤー構造はこんな感じですね。「デザイントークン」は変数のセットです。デザインの最低限のアイデンティティを表現するものですね。次に画像やアイコンなどの「共通アセット類」があって、一番下に画面を作る「UIライブラリ」があります。この3層に分けてコンポーネントライブラリは構成されています。それぞれの作り方を見ていきます。

構造1 デザイントークン

まずは「デザイントークン」ですね。手順で書いてみたのですが、Figma TokensはFigmaのプラグインで、Figma上のカラーやタイポグラフィー、スペーシングなどを変数として保存して、jsonをGitHubにコミットして、PRを作ってくれるすごく良いプラグインで、ドキュメントも充実しています。ここにすべてのCSSのカスタムプロパティや、Sassの変数になるようなものを格納しています。

そしてStyle Dictionary。これはさっき作ったトークンのjsonを、CSSのプロパティやSassのVariables、コンポーネントのjson、Tailwindのconfigに変換してくれるパッケージです。このTransformsというAPIが便利で、単位や型をそれぞれのフォーマットに合わせて変換できるようになっているので、一度にすべての環境に配れるというふうになっています。

それらのフローをGitHub Actionsで自動化しています。ということで、Figmaを更新すると各ドメインに対応したデザイントークンを自動でリリースできるようになりました。

構造2 共通アセット

次は共通のアセットですね。これらでは直接FigmaのAPIを利用して、Figma上でコンポーネント化した画像をGitHub Actionsのworkflow_dispatchを使って抽出しています。これがS3にアップロードしてくれるのですが、S3のバケットはFastlyにつながっていてオフロードしてくれます。

Fastlyはご存知のとおり、Image Optimizerがなんでもやってくれるので、エンジニアがあとからいくらでもURLパラメーターで変換やクロップ、最適化が自由自在にできます。ということで、こちらもFigmaを更新すると最適化されてリサイズ可能な画像が配信できるようになりました。今回は画像のみを説明しましたが、アイコンはパッケージとして配信をしているようなかたちになります。

構造3 UIライブラリ

次にUIライブラリを構成しているのはこちらです。まさにガンガン作っているのでWIPということで発表するんですが、React LayerとStorybookとTailwind、この3つがポイントになっています。Tailwindはデザイントークンのところで生成したものを利用しているので、React LayerとStorybookについて見ていきます。

ReactのUIライブラリもレイヤー構造にしています。Stateはローカルのstoreで、Behaviorはeventやaccessibilityの振る舞いを定義しています。ComponentsがstateとBehaviorとTailwindのstyleをまとめてくれるように構成しています。

こうすることによって「類似コンポーネントが作りやすくなる」と書いているのですが、UIライブラリでいくつも類似コンポーネントを内部で作るというより、利用される各ドメインでコンポーネントを直接利用できないけれど、StateとBehaviorでドメインに依存した類似コンポーネントを簡単に利用できるようにしています。

Storybookは定番ですが、テストやガイドの充実を重視しています。Figmaのデザインと実装を相互にパッと確認できるようにしていたり、トピックとしてはもともと採用しているatomic designを止めて、機能別のファンクショナルなカテゴリーでグルーピングするように移行しました。

理由は、入れ子構造にする必要性を感じなくなったのと、用途によって見通しを良くしたかったからです。ということで、抽象的にも利用できる拡張しやすい自由度の高いUIライブラリになっているはずです。

「UXエンジニアは楽しい」

テストやFigma連携でデザインとの整合性を担保しやすいUIライブラリを目指していて、デザインとコードが同期しているコンポーネントライブラリを目指しています。デザイナーがFigmaを更新すると、エンジニアが利用するリソースのバリューが更新されていたり、デザイナーとエンジニアがお互いの実装が期待どおりか、いつでも簡単に確認できる世界観がいいなと思っています。

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

これからもどんどんがんばっていきますので、「興味があって一緒にやりたいぞ」という方がいればお待ちしております。というわけで僕のパートは終わりなので、沢登さんに戻します。

「全社お役立ちキット」のデザインシステム作りを目指している

沢登：ありがとうございます。そうしたら僕のパートである「デザインをみんなでつかう」についてお話しします。

自己紹介ですが、沢登達也と申します。入社5年目ぐらいで、アクセシビリティや仕組み化が大好きなデザイナーです。先ほどみんなで使うという話があったんですけど、noteだといろいろな職種の方がいるので、そういった方々もデザインシステムを使えることを想定しています。

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

事例1　「トーンオブボイス」

ここからはいくつかの事例に関して説明していきます。全部で3つあります。まずは「トーンオブボイス」というものです。あまり聞きなれない言葉だと思いますが、サービスの人格や、発する言葉をルール化して決めるものとして認識してもらえばいいかなと思います。

例えばSNSなどで、公式のTwitterアカウントがどういう言葉遣いをするかとか、そういうお話です。もともとnoteは「noteさん」という人格を2年ぐらい前に作っていて、デザインシステムを作る前からそういう話は動いていました。これを具体的に使えるようにしていくのが、トーンオブボイスの取り組みの1つです。

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

まとめですが、トーンオブボイスとはサービスの人格を決める。ということで、発する言葉やバランスがルールとしてわかる状態で、noteらしい言葉遣いとはどんなものかというのが統一されることを目指しています。こちらも絶賛開発中です。

事例2　「イラストシステム」

次に「イラストシステム」です。これはふだん耳にしている方も多いかもしれませんが、noteは社員としてイラストレーターが在籍していて、いろいろなトーンなどをプロダクトでリリースしながら検証している状況です。

今映しているイラストはけっこう種類があるのですが、それぞれちょっとトーンが違っていて、だいたいこの1年間で5種類以上のトンマナ（トーン&マナー）をプロダクトに反映しています。

イラストシステムと呼んでいるぐらいなので、システム化も進めています。例えば左側はFigmaのレイヤー構造でイラストを生成できて、右側はデザイナーであればAdobe Illustratorでパーツを組み合わせてバナーぐらいであれば作れる状況を作っています。

このイラストに関しても、例えばPRが外部発信のためにイラストを使いたいというケースもあるので、社員向けにはイラストカタログを作って共有しています。なのでイラストシステムに関しても、誰でもイラストを使える状態を目指しています。

トーンオブボイスと同様に、noteらしいイラストを提供するというミッションがあります。また、すごく時間をかけて議論をするよりかは良さそうなテイストをどんどんプロダクトにリリースしながら検証を進めています。ここはこれ1本でLTができるぐらいのボリューム感があって、イラストレーターが記事を書くと話を聞いているので、そちらをお待ちいただけるとありがたいです。

すべてのデザインシステムのベースになる考え方「デザイン原則」

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

原則を作る前にまずステートメントというものを作っていて、これが大目標。ここからブレるとデザインシステムは失敗。というか「方向性としてブレているよね」というのをわかるようにするために作ったものです。地図みたいなものだと思ってもらっていいと思います。

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

デザイン原則のまとめとしては、まず70点を目指してリリースして使い始める。というところと、バージョン1を時間をかけずに作っている。そして、使って評価という部分を意識して運用しています。

3つの取り組みの中で共通して意識していること

ここまで3点の取り組みについてお話ししましたが、それぞれ共通して意識していることは未完成で使い始めるというところですね。イラストであればプロダクトに反映したり、デザイン原則であれば使って運用してみたり、ということに気をつけています。あとはデザイナーだけでなにかを決めて提供するより、そもそも作るところからみんなを巻き込んでいます。

作ったものを提供したにも関わらず、運用されないということを1番のバッドケースとして考えているので、作る段階から巻き込んで、それが結果的に認知につながっているのかなと思います。あとは簡単に使えること。これはプロダクトと同様だと思いますが、小難しいとか予備知識がいるとか、特定の場所までいかないと使えないという状況が生まれると、なかなか使われなくなってしまうので、そのあたりは意識しています。

クリエイターに良い体験を提供するデザインシステムを作り続ける

まとめです。noteのデザインシステムは、みんなが参加して簡単に「noteらしい」を作れ、クリエイターに良い体験を提供するためのものとして作っています。ここまで発表しましたが、noteのデザインシステムは未完成な状態です。実際、完成という状態はなかなか難しいと思っていて、どちらかというと作って継続するところに意味があると思っています。