過去のデザインを否定せず、リスペクトしながら改善する　「SPEEDA」におけるデザインシステム構築の第一歩

デザイナーだからこそ感じた「SPEEDA」の課題

平野友規氏：何回か登壇しているのですが、今日は久しぶりでメチャクチャ緊張しています。「SaaSデザインの現場　ユーザー体験を追求し続けるプロダクト開発の内側」というテーマでお話ししたいと思います。平野です。よろしくお願いします。

まず、本日はご参加いただきありがとうございます。それから、僕はあくまでも代表して話しますが、決して僕1人で作ったのではありません。UIデザイナーのみなさん、そして家族に、本当にいつもありがとうございますと言いたいです。

猪爪さん（猪爪雄氏）にも御礼を言いたいです。どういう縁だったかわからないのですが、僕が猪爪さんに「Meety」で「CDO（Chief Digital Officer）が、既存プロダクトのボタンの種類を数えています」というような話をして、「これでいいんですかね？」と言ったら「僕もやっています」と言われて、すごく勇気をもらいました。

それから時が流れて、縁あって猪爪さんと一緒に登壇できてうれしいです。また、この場にニジボックスの河合さんと一緒に登壇できたことも、感謝申し上げます。

今日はまず、SaaSデザインの現場で、僕はどう解釈したかを話します。僕が担当しているプロダクトは「SPEEDA」で、経済情報プラットフォームです。

ユーザー体験を追求し続けるところ、僕からはUXの話は正直出てきません。ひたすらデザイナーから見た、いわゆる見た目の話ばかり出てくるかと思います。そこから見た、10年選手のプロダクトの抱える課題をお話できたらと思います。

デザインシステムは、この場で本邦初公開できたらと思います。それではやってまいりましょう。

僕は入社時、SPEEDAのデザインを「なんで10個もボタンがあるんだよ」「これ、またぁ、デザイナー入れていなかったからでしょう」というような、ひねくれた見方をしていました。

それから3年ほどかかっていますが、そのうちに「もしかしてボタンが10個あるのではなくて、10人のデザインにかかわった人たちがいたんじゃないか。そして、僕が11人目になるんだ」という思いになって、それからはいろいろなことがすごく好転し始めました。

デザイナーだからこそ感じる課題感のようなものもあると思っています。SPEEDAの機能は、ユーザーに対してJob-To-Be-Doneをたくさんしていくので、非常にすばらしいです。ただ、造形表現に美しさを加味すれば、もっとよいプロダクトになると僕は信じていました。

例えば、アイスランドの夕日に感動するように、満月の夜の雪原に心を奪われるように、美しさには人の心をつかむ力がある。僕はデザイナーなので、その美しさをより強く課題として感じたのかなと思います。

自己紹介

というわけで自己紹介です。僕には人生観が2つあります。「悲観主義は気分によるものであり、楽観主義は意思によるものである」「学ぶ心さえあれば、万物すべてこれ我が師である」です。これを大切にして生きています。

僕はユーザベースで働いていて、その中で、DESIGN BASEというデザイン組織を立ち上げています。DESIGN FORWARDというデザイン組織のビジョンも掲げています。

ユーザベースのサービスはたくさんありますが、その中でも経済情報プラットフォーム「SPEEDA」、B2B事業向け顧客戦略プラットフォーム「FORCAS」、スタートアップ情報プラットフォーム「INITIAL」のB2B SaaSを専門にやっています。

展示会のブースのデザインや、マーケティングのグラフィック、プロダクトなど、幅広くやっていますが、今日は経済情報プラットフォームのSPEEDAを中心にお話しします。

「SPEEDA」の機能

ランディングページにいろいろ書いてあるのですが、SPEEDAはユーザーにならないと見られません。そのため、今日はお見せできるスクショをいっぱい持ってきました。

まず、業界を探せます。どの業界が儲かっていて、どの業界が儲かっていないのかを、グローバル・ローカルで見られます。

（スライドを指して）あとは、こんな機能もあります。

これは、競合財務比較です。ぼかしているのは、契約関係で見せられないところがあるからです。

ライバル企業の財務状況や、M&Aの状況、市場規模などが見られます。

例えば、バイオテクノロジー業界の企業を、上から10個挙げてくださいと言われても難しいと思いますが、SPEEDAを使うと一発でわかります。ほかにも、ターゲットリストを作るなど、いろいろできるサービスです。

厳密に言うと、もう12年ぐらい経っているプロダクトなので、大量の情報が格納されているという特徴があると思います。

あと、厳密にどこからが機能かを数えるのは難しいのですが、ローカルナビは75以上の機能があります。このすべてのデザイン1個1個を見ていくのも、3年以上かかるのではないかと僕は思っています。

今、デザインリニューアルを少しずつ進めています。今回のためではないですが、既存のSPEEDAの10年選手のプロダクトは何色あるのか、エンジニアの協力のもとでざっとCSSのカラーコードだけ抜き出してみたら、140色以上ありました。

すごいですね。もう「熱ぃでございます」って感じです。ちなみに、グレイスケールだけで70色以上あって、これまた「熱ぃでございます」というところですね。この色の問題1つとっても非常にチャレンジングで、挑戦しかないという受け取りをしています。

そして、冒頭で出てきた、僕たちのチームが数えていたボタンは、僕もわからないぐらいたくさんあります。

SPEEDAが抱えている4つの大きな問題点

デザイナーから見た、SPEEDAが抱えている大きな問題は4つあります。1つ目は、造形表現がオールドスタイルで、統一感が弱いこと。2つ目が、UIデザイナーがそもそも少ないことです。エンジニアさんとデザイナーさんがだいたい14対1ぐらいで、そこまで多くないと思います。

3つ目は、デザインシステムを作る前、オールドスタイルである現状のコンポーネントで新しい機能開発が進んでいたので、無限増殖して、大いに負のスパイラルに入っていたことです。

4つ目が、弊社の特殊性なのかわからないのですが、理想案と現実案を同時に作るのが開発の特徴で、デザイナーはその時点であるべき姿、現実の姿、MVPをほぼ同時に進行しています。その時にUIデザインがかなりボトルネックになっていて、スピードが出なかったのです。

これをどうにかしなければいけないというのは、開発を含めた問題でした。

だから、解決のためにデザインシステムを構築するしかない。これをやったらなんとかしてくれるんじゃないかという、藁にもすがる思いでスタートしたのを憶えています。

エコシステムさえ構築できれば、新しいコンポーネントで、新しい造形表現でスタイルを統一でき、デザイナー同士のコラボレーションで助け合いも超過労働も解決できて、さらに負のスパイラルである無限増殖を食い止められると期待しました。

コンポーネントでさらに型化して、足元では「Figma」で爆速化を目指しました。Figmaを導入する前は、いわゆる「XD」「Sketch」「Photoshop」が混在する状況でデザインをしていたので、とにかくFigmaにするのをトップダウンで決めました。

ちなみに僕は、SketchユーザーではなくXD派でしたが、XDで進めていた時にいろいろな問題が起きたので、もうFigmaにしようと、デザインファイルを全部捨てた記憶があります。

問題解決のための取り組み：分析フェーズ

では、どういうふうに作っていったのかを詳しくお話しします。「分けて、比べて、わかる」のようなことかと思っています。

まずは、機能が何個あるのかを、とにかく画面キャプチャをひたすら撮りまくりました。そして、スクショをコンポーネントで分けていきました。これは僕1人ではなく、一緒に働いているデザインチームのメンバーがやってくれました。

（スライドを示しながら）ひたすら分けた後にまとめて、なにか不具合がないのかをコメントを残しながら、どんどん分けていきます。

そうすると、だんだんわからなくなりました。例えば、矢印も140色もあるようなかなり熱ぃ問題があったり、ごみ箱も熱かったり、アバターもたくさんあって、とにかくアイコン1つ取ってもかなり熱かったです。

先ほど見せたボタンも熱ぃとしか言えないのですが、かなり熱かったです。（スライドを示して）こういうふうにどんどん分けていったら、分け過ぎてわからなくなったのですが、メンバーの1人から「Figmaのプロトタイプ機能を使ったらいいんじゃないか」と言われました。

プロトタイプはだいたい動くもので使うのですが、Figmaで画面単位から、どの画面にどのコンポーネントが使われているのかがわかるし、逆にコンポーネント単位から、どの画面にそのコンポーネントがあたっているのかがわかるようになりました。

最終的に、毎回ソースコードはエンジニアさんと相談しながら進めていくのですが、まずFigma上でコンポーネントがどの画面に影響するのかがわかるようになったのは、非常に大きかったです。

問題解決のための取り組み：分析以降の進め方

（スライドを示しながら）ここで下ごしらえが終わって、どのコンポーネントを使っているのかわかるようになりました。分析フェーズが終わって、ここからどう進めていくのかです。理想論では、よくデザインシステムを構築して、新機能の開発と既存開発の改修にあてていきます。これは最高にかっこいいですが、絶対に無理なやり方でした。

（なぜかというと、）まず人数が少ないのと、そもそも新規開発と既存機能の改修が走っているところに、並行してデザインシステムを走らせなければいけないのです。ユーザーに機能を届けることのほうが価値として圧倒的に高いので、この順番ではできないと思いました。

これを同時に走らせていくこと、機能開発で作ったものをデザインシステムで取り込んで、そのあと既存開発の改修をすることを当時は思い描いていたのですが、こんなにきれいには絶対に進みません。

（スライドを示しながら）実際はこのように出戻りする感じです。出戻りしながら、時にはデザイナーと「平野さん、先ほどと言っていることが違います」「いや、でもなんか、実際に既存の画面にあてはめたらこっちのほうがよかったんだ」などと言い合っていました。「新規画面にあてはめたらこっちのほうがよかった」「マージンはこっちのほうがいい」と、ほぼ毎日デザイナー同士で話し合いながら進めました。

それから、既存画面にどうあてていくかという問題では、例えば表組みやアイコンなど、操作に問題がないところと、印象が変わりやすいところから着手しました。

（スライドを示して）例えばこれはツール画面一覧ですが、ここは機能自体は変える必要がなく、イラストと新しいデザインのスタイルをあてました。これぐらい手数は少なくて効果は絶大になるところを見極めて、ユーザーにまず操作性でインパクトが出ないところを中心に、どんどん実際の画面にあてています。

既存システムのリニューアルで意識したこと

新規ゼロ立ち上げであれば、デザインシステムを先に作ってから作るようなことも可能かもしれませんが、リニューアルなので、あくまでも新しいコンポーネントと並行して走らせなければいけないところがあります。

（スライドを示して）例えば、これはセグメント比較という1つの機能ですが、この中で、いかに既存のデザインと整合性を合わせていくか。そこに新しいものをはめても違和感がないかをかなり意識しながら、造形の調整などを少しずつしていきました。

大きく分けると、既存機能改修はレイアウトは変えないと意思決定はしていて、基本的にはコンポーネントの置き換えで済ませました。そうすると、ロイヤルユーザーの使い勝手の説明が不要になるので、そこはかなり意識しています。スーパーの戸棚が移動するとどこに何があるかわからなくなるように、場所を変えると混乱するので、コンポーネントの置き換えでうまくやりました。

新機能開発に関してはゼロベースで考えるのですが、新しい機能が主流になっていければ既存をリプレイスしていく考え方です。