デザイナーの伊藤です。
「INVOY」というクラウド請求書発行・管理プラットフォームと向き合って2年弱たちました。当初は請求書発行ツールとしての機能の拡充から始まったのですが、銀行口座との連携や受取請求書の管理、カード払いできる機能など、この2年間の請求書発行にとどまらない機能の追加により、「INVOY」は大きな飛躍を遂げました。
今回は「INVOY」の新機能追加やグロース施策を進める裏側で、デザイナーが悩みながら改善してきたことにフォーカスしてお話したいと思います。
かんたん自己紹介
OLTAでの役割
プロダクトに比重を置きつつ、OLTAで必要なクリエイティブの相談から作成まで行っています。コーポレートや事業開発部で必要な制作物の作成から採用まで横断的に関わっています。
経歴
公務員からwebデザイナー(アウトソース)に転身、転職を期にUI/UXデザイナー(インハウス)の経験を積み、新卒教育やディレクション、アプリ開発、OPもどきなど色々やってきました。
ご興味いただけましたら、こちらもぜひご覧ください!
👉 YOU TRUST: youtrust.jp
INVOYのデザイン思想を読み解く
入社当初、「INVOY」についてのドキュメントはあまりなく、口伝えとFigma、とにかくリリースされているプロダクトを見るということをしていました。
人数的なところもありますし、スピード感のある開発にはこのぐらいがちょうどよいと思いつつ、とにかく「なぜこのデザインや実装になったか」の背景を知るために関係者にしつこく質問していました。
当時の「INVOY」の印象を振り返ると以下なのですが、現在もその印象は変わってません。
- 緑色
- キャラクターがいる
- 操作がかんたん
Figmaでデザインシステムが作成されているので、大まかなルールは把握できました。
画面によって使用されているコンポーネントが異なる、新規コンポーネントの検討の際の拠所がない、ボイス&トーンなどがないために表記ゆれや「〇〇しましょう!」と言ったり「〇〇できません」と言ったり、テンションの上がり下がりが顕著だったりしました。
当時はプロダクトマネージャー(PdM)やデザイナーも「なんとなくINVOYっぽい」という暗黙知でプロダクトやデザインを作成してました。
プロダクトを前進させる裏側でできること
とはいえ拡充期の最中、要度や緊急度の高い機能追加や、数値にはねる改善以外に工数を割くことは難しいのが現状でした。そこで、「やりたいこと」と「今できること」を切り分けました。
やりたいこと
- UXライティングのルール策定
- ブランドの方向性の整理
- デザインシステム設計の整理
- デザインシステムの改善
- プロダクトへの反映
今できること
- エンジニアの手を借りない改善
1.FAQのライティング改善
ユーザーがプロダクトをスムーズに利用できるように、UXライティングは早めに着手したい部分でした。
とはいえ、エンジニアの手を借りずに短期間でまずやれることととなると、プロダクトから独立しており、且つデザイナーとPdMが主体となって対応できる必要があったため、「FAQの改善」から開始しました。
「INVOY」を担当しているPdM2名とデザイナー2名の計4名で進めることとしました。短期間で改善を目指すのため、あえて改まった認識合わせやデザイン原則の作成はしませんでした。また、プロダクト理解が豊富なメンバーが集まっていること、概念ではなく具体的なルールを作ることになるので、メンバーの考えを知る意味で、ド直球に改善に取り組みました。
150を超えるFAQを抽出して文法やワードの確認をし、どういう言い回しにするのかをメンバーですり合わせることにしました。
開くのか閉じる※のか、単調な言い回し(することができる、など)になっていないか、「」と『』の使い分けはどうするか、「ページ」と呼ぶのか「画面」と呼ぶのかなど、多くの課題が出てきました。
※「開く」とは漢字で表記できる文字をひらがなにすること、「閉じる」とはひらがな表記を漢字にすることです。文章が読みづらくならないよう、漢字とひらがなのバランスを整えるために活用します。
▼ワーディングマスタ
いったんFAQの改善案とシソーラス(当時ワーディングマスタと呼んでいた)のたたきを作り、各メンバーで見直し作業をしてもらい発散・収束してFAQに反映しました。
やってよかったこと
- 作成者によって異なっていた言い回しや記号の使い方が統一された
- FAQだけでなくプロダクトを作成する際にもライティングを意識するようになり、プロダクトにも徐々に取込むことができた
気づいたこと
- 慣れるまでは若干の工数があがった(繰り返し使うことで覚えてくる)
- 暗黙知を言語化しないと、統一はできないことに改めて気づいた
- Submitボタン(送信ボタン)を動詞「送信する」にするか名詞「送信」にするかなど、プロダクトで必要な表現は検討できていない
- 上記を決めるためのルールメイクもできていない
2.デザインシステム設計の整理
次にドキュメントの整理に着手しました。INVOYはGoogle Material Design(2)をベースに考えられていますが、それを読んで原則やDesign(設計)、Component(コンポーネント)のどの部分が「INVOY」に取り入れられているのか否かを紐解くのは至難の技でした。デザインシステムを改善するにあたり、まずどういう設計になっているかを整理したかったのです。
そこで大きくDesign、Componentで分け、Material Designではどういう仕様で、INVOYにはどう取り込まれているかを比較できる表を作成しました。
やってよかったこと
- 例えばどのLevelのShadowsを当てたらいいかなど、理由を参照でき、「INVOY」ではどう実装しているのかを比較できる
気づいたこと
- ドキュメントの表機能でまとめたため、エンジニアからは「見づらい」と不評だった
- 表にまとめるより、デザインシステムにすべてを記載するほうがよさそうだというあたりが付いてきた
2022年2月に一人デザイナー体制になる
そんなさなか2名体制だったデザインチームが1名になり、引継いだ業務をこなしながら上記改善に取り組むのが難しくなりました。
そこで、デザイン会社のフォルテ社 Forte Inc. にお手伝いいただくこととなり、もともと請求書発行しかなかった機能が加速的に増えて、ライティングにおいて整合性が取れなくなってくる事象が増えた現状の課題を共有し、UXライティングの改善を一緒に着手していただくこととなりました。
トンマナ整理とボイス&トーン
ライティングを整理するにあたり、プロダクトメンバーが蓄積してきた暗黙知を形式知に転換してブランドライフビジョンを策定しました。ブランドライフビジョンとは、ブランドは市場に位置付けるだけではなく「社会」にも位置付けるため、自社とユーザーそして社会が同じゴールを共有することができるという考えです。
(こちらを参照しました) ブランドアイデンティティとは|強いブランドを創るBI構築法|事例有 - Mission Driven Brand
また、より解像度を高めるために「INVOY」に当てはまるキーワードをOKとNGにわけ、ON/OFFブランドを作成し、これを軸にボイス&トーンに落とし込んでいきました。
ブランドライフビジョンやON/OFFブランドを軸にボイス&トーンや文法などを決めていき、コミュニケーションガイドラインというドキュメントにまとめました。また、UIコンポーネントのルールも同時に定めたので、プロダクトの改善も一定のルールをもってする準備が整いました。
またワーディングマスタをもとにシソーラスも作り、表記ゆれの是正もはじめました。
ここでついにプロダクトのUXライティングの改善に取り組み、改善案まで作成できました。
やってよかったこと
気づいたこと
- 改善を続けるための運用ルールや、プロダクトに反映する方法を考える必要がある
特に「作って終わり」にしないために、slackチャンネルを開設し質問の受付や情報共有、プロダクト改善時のやりとりなどを積極的におこないました。
メンバーが増えてやれることも拡大、デザインシステムの改善に本格的に着手
フォルテ社とのバトンタッチのタイミングで、業務委託のデザイナーや正社員初のフロントエンドエンジニアが加わったことで複数人での対応が本格化し、デザインシステムの改善に本腰を入れて着手しました。
「デザイン基盤」プロジェクトを立ち上げ
先行きが見えない中で部分改善を進めると不整合な状態が継続してしまうため、なかなかプロダクトへの反映に踏み切れなかったのですが、フロントエンドエンジニアとデザイナーでプロジェクトを立ち上げることによってUIやライティングの細かい改善ができる体制を作ることができました。
まずは、デザインシステムやドキュメント、Storybookをもとに方針と進め方を整理しました。
デザインシステムとStorybookに情報を集約し、コミュニケーションガイドラインの抜粋もデザインシステムに掲載することとし実装はStorybookを参照することにしました。現在は階層構造も含め先行して「理想のデザインシステム」を作成し、Storybookをデザインシステムに合わせる作業をしてます。
やってよかったこと
- デザイナーとエンジニアでデザインシステムはなぜ必要かを再定義でき、FigmaとStorybookでどこまで合わせるかなどの認識を合わせられた
- コンポーネントやデザインルールの可視化ができた
- デザイン基盤を立ち上げたことによって、数字に跳ねない改善を進められる方法を作れた
気づいたこと
- デザインシステムに合わせたStorybookの改善が必要(現在進行中)
- 運用改善とプロダクトへの反映方法の整備が必要
とはいえ、プロダクトの改善や新機能開発などと平行して動いているため、これから少しずつ実行する予定です。話し合ったり気づいたりしたissueはタスクとしてバックログに積み上げ、着手可能な時期がきたら棚卸ししたいと思います。
まとめ
PMF(プロダクトマーケットフィット)を図るためスピード感重視でドキュメント等の策定をあえてしないフェーズから、属人化の脱出やプロダクトのスケールなどを考える時期に入り、今回ご紹介したような改善を進めました。
作成すること自体は通過点にすぎず、継続的に改善することや反映する方法を新しく考えて行うことの難しさを改めて痛感しました。
まだまだやりきれていないことはありますが、ユーザによりよいザービスを提供するための仕組み化を引き続き続けていこうと思います。
最後に
OLTAでは、ユーザーに価値を提供し、事業を成長させるサービスを一緒に作る仲間を募集しています。 もし、この投稿にご興味を持っていただけたら、是非カジュアルにお話しさせてください。