こんにちは、BASEのDesign Groupに所属している北村です。
現在は主にプラットフォームとアプリのデザインを担当しています。
BASEのデザインチームはここ数年で一気に人が増え、社内でも大所帯の部署へと成長しました。今回は、BASEのデザイナーが日々の開発でどんなことを行い、どんなことを考えているのかについてご紹介したいと思います。
1. BASEのデザイナーの役割
プロジェクトの共通認識を作る仕事
BASEでは仕様検討の段階からデザイナーが入り、プロジェクトの担当者と一緒に開発要件を詰めていきます。ときには箇条書きの要件書からワイヤーを起こし、UIをアウトプットしていきます。画面デザインが先にあると、メンバー同士のコミュニケーションがスムーズになり、かつ他部署との認識合わせも円滑になるため、BASEの開発フローでは まずデザインありき という文化が浸透しています。また単純に、先にデザインがあると実際の画面をどう作っていけば良いのかチームの皆で把握しやすい、という利点があります。
プロジェクト内で共通認識となるアウトプットを担うのが、BASEのデザイナーの仕事のひとつです。
BASEにおけるデザイナーの責任
BASEでは基本的に、プロジェクトにアサインされたデザイナー本人がデザインクオリティのチェックを行います。
さらに、担当デザイナーが自分で画面のUIを実装することも多いです。最近はフロントエンドエンジニアも増えたので分業が進んではいますが、例えば細かなインタラクションの実装やUIの改修などはデザイナー自身が積極的に行っています。 画面のUIを設計するだけでなく、最終的なUXの担保まで担うのが、BASEのデザイナーの責任範囲になります。
2. BASEのデザイン思想と、大切にしていること
「お母さんも使える」という共通言語
BASEには社内全体の共通言語として「お母さんも使える」という思想が存在しています。
これは、BASE創業当時から変わらない哲学で、代表取締役CEOである鶴岡さんの強いポリシーであり、BASEの重要なコンセプトです。
お母さんのために、良くも悪くも「機能をつけない」
便利だけれど使い方が難しい機能よりも、いかにクリック数を少なくして、簡単にショップを開設・運営してもらうかが最優先事項になります。
4、5クリックしなければならない機能より、2、3クリックで完了する機能を開発・提供する。たとえば、ユーザが一番使用する管理ページには、あえて機能をつけないなど、設計については、当初から「ユーザの手間を減らすための開発」を意識していました。
現在、BASEチームには13人ほどのエンジニアがいますが、新しい機能ができてもチーム内で「この機能は、お母さんたちには使えないのでは」となったら、たとえ便利そうな機能でもリリースしていません。
出典：お母さん目線で作ってみたら、「BASE」はシンプルなサービスになった
BASEではプロダクトの開発中、あらゆる場面・文脈で「お母さん」という単語が出てきます。「これって複雑すぎてお母さんは使えないよね」や「この説明、お母さんに伝わるのかな？」など、議論の主語となることがとても多いです。
複雑な仕組みだったとしても、お母さんも使えるくらい簡単なサービスとして提供するのが、プロダクトを作るときに最も大切にしている思想です。
誠実さを大切にしている、BASEのデザイン思想
「お母さんも使える」を実現するために、デザイナーで作成したデザイン思想があります。
- 誠実
- reliable
- あらゆるユーザに寄り添える、柔軟な拡張性
- flexibility
- 価値を最大化させる新しいショップ体験
- leading
- 「お母さんも使える」親しみやすいサービス
- friendly
- 簡単じゃないものを簡単に
- simplified
BASEのデザイナーはなによりも「誠実」さに重きをおいています。
例えばユーザが何かものを売りたいと思ったときに、今までだとハードルが高くて気軽にできなかったものを、誰でもできるようにするのがインターネットの力で、BASEはそのインターネットのポジティブな力を信じてサービスを作っています。
一方で、インターネットがインフラとして広まっていく一方での負の側面もあり、伝え方次第では誤った情報が多くの人に広まってしまったり、誰かを傷つけてしまうことがあったりします。
そういった意味で、デザインの役割は非常に重要です。多くの人に影響を与えるインターネットというインフラ上でサービスをデザインする以上、誠実さを忘れてはいけない、という思想を持っています。
3. デザイン思想を実現するワークフロー
では実際に、2 のデザイン思想を実現するために行っているワークフローをご紹介したいと思います。
BASEにおけるデザインのフロー
- PMやディレクターから機能要件がくる
- 要件・仕様を元にデザイナーがワイヤー、またはプロトタイプを起こす
- 起こしたデザインを「UI/UXミーティング」でレビューする
- 実装に入る
週2回おこなわれるUI/UXミーティング
BASEでは週に2回、UI/UXミーティングという場が設けられています。 このミーティングでは、各デザイナーそれぞれが担当しているプロジェクトのUIをレビューしてもらいます。
（プロジェクトの粒度によってまちまちですが）鶴岡さん、PM、ディレクター、プラットフォームデザイナー、アプリデザイナー、フロントエンドエンジニア、CSが一堂に会し、デザイナーの作成したUIを見ながらみんなで議論し合います。
他のデザイナー目線でのUIに対するダメ出しも含め、ビジネス視点からの要望や、実装に対するツッコミ、全体のUXへの指摘など、多角的な意見が入ります。もちろん「そもそもその機能って必要なの？」という意見が出ることも多々あります。そこをまとめて取捨選択するのもデザイナーの役目です。
たとえ途中で仕様が変わろうとも
プロジェクトのメンバーだけでは把握できなかったより大きなユーザ体験が、UI/UXミーティングでの議論で見えてくる部分もあります。先日公開されたエンジニアの日比野さん 、柳川さん の記事でも書かれていましたが、BASEではプロジェクトを進行してゆくなかで「ちゃぶ台返し」が起こるポイントがしばしば発生します。
デザイン目線でいうと、例えば
- 「簡単じゃないものを簡単に」が満たされてない
- 「親しみやすさ」が満たされてない
- 「価値を最大化させるショップ体験」が満たされていない
- 「お母さんも使える」が満たされてない
この部分の踏み込みが甘く、議論が充分でないままプロジェクトが進んでしまった時に、UI/UXミーティングで指摘を受けることも多いです。 これはBASE全体にデザイン思想が浸透しているからこそ起こる議論で、たとえもう一度仕様を練り直すことになったとしても、より良いものを作る努力は惜しまない、納得するまで議論する、というBASEの「SPEAK OPENLY」のあらわれだと思っています。
まとめ
BASEのデザイナーは裁量が多く、担う範囲も広いですが、開発の上位レイヤーから関われる環境というのはやはりやり甲斐があります。誠実にサービスを作るというBASEで働くデザイナーが大切にしている思想です。
そんなBASEの思想に共感してくださった方、一緒サービスを作りましょう！
デザイナーを随時募集しています！