驚きではなく、違和感なく使えるUIを──FellowとUIデザイナーが語るフロントエンドの重要性

板倉 大輔（以下「板倉」）：
率直に言うと、「あぁ、そうなんだ」ぐらいですね（笑）。Fellowに就任したからといって、特に意識は変わっていません。ただ就任後、複数のプロジェクトに携わるようになりました。これは以前より私が上長にリクエストしていたことで、Fellowに就任したタイミングでやることになりました。最近ではB2B Saas事業の中でも、セグメント比較という機能と、NewsPicksExpertの開発を主に担当しています。

板倉：
一言で説明するのは難しいですが、「フロントエンド」はユーザーが最初に触れる場所なので、ここでどのような印象付けをするのか、設計が非常に重要だと感じています。

少し前までは「ユーザーに驚きを与えるフロントエンド」が良いと思っていたんですが、その感動って実は長続きしないんですよね。普段使いできるアプリって、やはり違和感なく使えるアプリなんです。そのことに気づいてからは、いかに初回のアクセスで違和感なく使っていただけるか？ が重要だと思うようになりました。慣れ親しむというより、使いやすいUIになっているかどうかですね。それをUIデザイナーの茂木さんたちと一緒につくり上げていきます。

茂木 孝純（以下「茂木」）：
ユーザベースでは、新たなプロジェクトを走らせるとき、板倉さんたちのような開発チームと、私たちのようなデザインチームが常に相談しながら進めていきます。板倉さんとは、新規事業のFORCAS Salesプロダクト開発の際に、初めて一緒に動くことになりました。

茂木：
板倉さんがおっしゃった「最初の印象になるからこそ、違和感のなさが重要」という点は、私も全く同感です。
たとえばフロントエンドにあたるページに、見た目が同じ2つのボタンがあるとします。ボタンAを押すとこういう動きをするけど、ボタンBは全く違う動きをすると、ユーザーは混乱しますよね。何が起きるか分からないのって、不安になるじゃないですか。

デザインチームでは、使い勝手や見た目の一貫性をデザインシステムで表現するんですが、デザインのパーツや挙動を何のルールもなしにつくると、もう本当にフリーダムというか、無茶苦茶なものができるんです。

セオリーがないと、エンジニアも「何でこのときはこのボタンで、別のときはこのボタンなの？」と混乱するし、開発の工数もかかるし、ユーザーにとっても使いにくいサービスになってしまいます。そうならないためにも、デザインシステムをしっかりとつくりこむことで、結果的にフロントエンドにも効いてくると実感しています。

平野 友規（以下「平野）：
フロントエンドがいいプロダクトって、たいてい使いやすいですよね。最近非常に感銘を受けたサービスがあるんですよ。多くの情報量を取り扱うサイトなんですが、ユーザーにとって使いやすいし、ボタンの定義もきちんとしているので、ユーザーが不安にならないなと。

情報量が少ないものを整理することは簡単だけど、情報量が多いものを整理するのは難しい。ユーザーインターフェイスやフロントエンドをどう魅せるかが非常に重要なんです。僕が感銘を受けたそのサイトでは、グラフの見せ方も非常に効果的で。

しかもオープンソースソフトウェアを普通に使っているんですよ。自ら開発する部分をどこに置き、どの部分で外部サービスを使うのか、判断が潔いんです。自分たちのコアバリューがどこなのかを見極め、いわいゆる「車輪の再発明」をしないフロントエンドは、もしかしたら非常に重要なのかもしれないと思いました。

茂木：
プロジェクト自体が「絵に描いた餅」にならないように気をつけて発言するようにしています。「絵に描いた餅」、つまり実現できない、スケジュールに全く見合っていない構想に陥らぬよう気をつける一方で、その餅を描く方法を模索することも重要です。

足元を見すぎて、実現可能なことだけを淡々と積み上げていくと、ユーザーの理想からはかけ離れたプロダクトに仕上がってしまうんです。かといって、ハイパーテクノロジーをひたすら駆使する構想も現実味がない。その中間にくる、「ちょうどいい塩梅」を常に模索するんですが、板倉さんはその塩梅を見つける感覚がすごく鋭いんですよ。

茂木：
FORCAS Salesのプロダクト開発で板倉さんと一緒だったとき、使用シーンのイメージを開発とデザインで進めていたんですね。その際、インサイドセールス担当の方がFORCAS Salesで企業情報を調べ、それを営業担当に共有するシーンの話になりました。どのように共有するのが最も効率的だろうか？ とチームでディスカッションしていたときに、板倉さんが「シェア用のURLを1クリックで発行して、そこにアクセスさえすれば、営業担当も同じ情報が見えるようにしたらどうだろうか」と提案してくれたんですよ。開発も複雑にならないし、共有するインサイドセールス担当の方の時間も手間も一気に省ける。さすがだなと思いました。

板倉：
私はデザイナーさんと一緒に仕事をする際、さっき話にでた「絵に描いた餅」を実際につくっちゃうようにしています。デザイナーさんが魂込めて設計してきたものを、開発側から「つくれません」とは言いたくないんですよ。

チームとしてより良いものを目指していくために、デザイナーさんにあまりブレーキを踏んでほしくない。デザイナーさんがいつでもアクセルを踏めるように、0→1のタイミングで実際にユーザーに使われるものを意識し、スピード感をもって開発するようにしています。

茂木：
はい。基本的には以前の記事でお話したことを引き続きやっているんですが、最近Design Division内で「Vision（ビジョン）」なるものをつくりました。私たちのチームは「DESIGN FORWARD」で事業を前進させることを掲げています。

茂木：
これはデザインの力を使って事業やプロジェクト、人を引っ張っていくことや、デザインチームとしてこうありたい、やっていくぞという想いを言語化したものです。私個人としても、ユーザベースに入ってからずっと「DESIGN FORWARD」をやりたいと考え、チャレンジしているところでした。

また、社内向けに「UI Design Book」というドキュメントもつくりました。ユーザベースでは、デザイナーだけでなく、技術関連やカスタマーサクセスなどさまざまな部署や担当が集まり、みんなでUIをつくったり議論したりする機会が多くあります。

業務や管轄が異なるメンバーが集まり、UIやデザインについて話をするんですが、全部署に共通する言語が存在しなかったんですね。それを解消すべく、UIをつくるうえで大事なポイントを明文化したのが、この「UI Design Book」です。

茂木：
これは私を含めUIチームのデザイナー3名で制作しました。共通言語をつくったのは、単に話し合いをスムーズに進めることだけが目的ではありません。エンジニアやビジネスサイドに展開することで、みんなで目線を合わせ、同じ目標に向かって議論していくことが一番の目的です。

その後メンバーへの個別説明を経て、現在はプロダクトを跨いでUIや仕様について議論する時間が週2回あるんですが、そこでもしばしば言及され立ち返る契機になったり、エンジニアやCSの方が「8割のユースケースってなんだろうね？」と言葉を引用してくれたりするシーンが徐々に増えてきたように思います。

板倉：
互いに共通言語をもって話をしようという意思はあるんですが、これまで会社として明確な「共通言語」はなかったんですよね。「UIデザインブック」の登場を受けてUIチームが徐々に変わってきているのを感じ、開発サイドとしても非常にわくわくしています。

茂木：
新規事業でデザインシステムをつくるのって結構大変なんですよ。これからどんな機能が追加されていくのかわからない中でデザインのベースになる部分をつくるので、どんな風にデザインが育っていくのかを想像しながら手探りで組み立てていくんです。

後々の手戻りなどを考えると、全体像がある程度見えたタイミングで一機能のつくり込みを始めるほうがいい。つくったものが無駄にならない方がエンジニアにとっても嬉しいはずですから。一方リリースまでのスケジュールを考慮すると、ゆっくり全体像を詰めている時間もないので、目の前の一機能をどんどん形にしていく必要性にも迫られて……。

でも板倉さんの開発スピード、めちゃくちゃ速いんですよ。さっき「絵に描いた餅をつくっちゃう」という話がありましたが、まさにそう。「素早くTRY & ERRORのサイクルを回していこう」という姿勢で接してくれるので、非常に進めやすかったです。

板倉さんは、「スコープを小さく切っていく」ことを常に意識されていて、「どう区切れるか」みたいな部分をよくアドバイスしてくださいました。

茂木：
プロダクトをつくる過程で「これって本当に正しいんだっけ？」って、開発もデザインも何度も自問するんですが、最後はやはり実際にユーザーに使ってもらわないとわからない部分も当然あります。でも何ヶ月もかけてつくった機能が使われなかったら悲しいですよね。なので、まず一番重要な部分を切り取ってつくったり、提供したりする判断が必要なんですが、この切り取り方が板倉さんは絶妙なんです。

板倉さんから「じゃあまずこの形でやってみませんか」という提案をたくさん受けたなと思っていて。それが結果的に、サービスリリースまでのスピード感を早めたんだと考えています。

板倉：
フロントエンドのベースをつくったのは3ヶ月ぐらいですかね。その後は粛々と、少しずつ洗練させていくみたいな感じになっていたと思います。スコープの話でいうと、小さく切って、つくって、リリースして、フィードバックをもらったら修正して──これを最後まで繰り返しました。

茂木：
外部提供する前に、まず社内のユーザーにテスト利用してもらうんですよ。そうすることで、いろいろなフィードバックが来ます。ポジティブなものもあれば、当然ネガティブなものもたくさんあって。想定どおり「良い」と言ってくれる意見もあったし、悲しくなったのもあったし（笑）。

茂木：
基本的にはサービスのペルソナを理解し、使ってくれるユーザーの声を一番大切にしています。でもそれだけを頼りにしていると、あれもこれもと機能やデザインを追加し、結果的に本質的ではないものが出来上がってしまうことが多いんです。

なので、「何が本当にいいのか」をプロジェクトメンバーでよく話し合っていました。そのうえで最後は自分たちで考え抜いたところを拠り所にする──信じたものを出してみて、ダメなら改善していくことを繰り返していました。

板倉：
難しいですね。プロダクトの特性にもよるんですけれど、「自然とさわっちゃう」とかですかね。やはり違和感なく日々使えることが大事かなと思います。

茂木さんと一緒だったFORCAS Salesのプロジェクトでは、「これって本当にユーザーに刺さるものができているのか？ つくれているのか？」と、自問を繰り返しながらつくっていきました。

平野：
今後はノーコードでフロントエンドがつくれる時代に突入すると思います。今でもデザインデータをアップすると、いきなりコードが吐き出されて、AIが一瞬でフロントエンドをつくるようなサービスがあります。そうなってくるとフロントエンドにおいて人がやる部分には、かなりの職人気質やカリスマ性が求められる可能性があります。

別の観点でいうと、茂木さんが先ほど「デザインシステム」と話していましたが、私も今SPEEDAのデザインシステムをつくることに注力しています。行き着く先は、そのデザインシステムの中にフロントエンドのコード──CSSスタイルなどを埋め込んで、コピペすればできるような世界をつくりたいと思っているんです。

たとえばSPEEDAでいうと、SPEEDAのカスタマーサクセスが何か新たにちょっとした改善をしたいという場面があったとします。そのときに、わざわざデザイナーに頼まなくても、そのデザインシステムを使ってCSSコードをぱっと貼り付けると、プロトタイプレベルで簡単に試せる。そんな状態を目指しています。

板倉：
少し技術的な話になってしまうんですが、昨今HTMLでもカプセル化できるようになっています。具体的にはWebComponentsという技術です。今後はこの技術を取り入れて、より柔軟かつ高速にプロダクトをつくれるようにしていきたいです。レガシーブラウザのサポート次第となる技術ですが、一部プロダクトでは適用可能なので、小さく始めていきたいと考えています。

茂木：
フロントエンドでいうと、今後インタラクション周りがリッチになっていくと思っています。「リッチなインタラクション」とは、無駄に派手なアニメーションなどではなく、ユーザーにとって本当に必要な情報をリアルタイムで出していくというか、ユーザーの行動にしっかり吸い付いていくイメージです。

細かいインタラクションがあると、それだけで使いこなせている意識になり、ユーザーの気持ちが上っていくと思うんですよ。その理由が通信速度なのか、フロント側のパフォーマンスのチューニングなのか、まだ分析しきれていないですが、ローディングの時間ひとつをとっても、それが短いだけで途端に使いやすいサービスであるように感じる。インタラクションがすごく気持ちいいフロントができたら面白いなと考えています。

板倉：
細かなインタラクションはB2Bのプロダクトでもやっていった方がいいと思うので、一緒にやれたらいいですね。